Qué es DevSecOps: Definición, Prácticas y un Pipeline Real

DevSecOps significa que la seguridad es parte del pipeline, no un control al final. El mismo sistema de CI/CD que construye, testea y despliega tu código también lo escanea buscando vulnerabilidades, secretos filtrados, dependencias vulnerables y configuraciones de infraestructura riesgosas, en cada cambio. Y quienes escriben el código se hacen cargo de corregir lo que el pipeline encuentra.

Esa es la respuesta corta a DevSecOps qué es. En el resto de la guía vemos en qué se diferencia de DevOps, qué significa de verdad "shift-left", las cinco prácticas que forman un pipeline DevSecOps, un ejemplo de GitHub Actions que podés adaptar y una forma realista de arrancar en un equipo chico.

DevOps vs DevSecOps

DevOps rompió la pared entre desarrollo y operaciones: cambios chicos, tests automáticos, entrega continua, responsabilidad compartida sobre producción. Hizo que los equipos entreguen mucho más rápido. El problema es que la seguridad muchas veces quedó en el modelo viejo: un equipo aparte, una revisión o un pentest antes de un release grande, un PDF con hallazgos semanas después de que se escribió el código.

Cuando desplegás varias veces por día, ese modelo no aguanta. O la seguridad se vuelve el cuello de botella, o (lo más común) se saltea. DevSecOps lo resuelve aplicando el mismo manual de DevOps a la seguridad.

Shift-left: por qué antes es más barato

"Shift-left" es mover los controles de seguridad hacia la izquierda de la línea de tiempo: al editor, al pull request y al build de CI, en lugar de auditorías pre-release o incidentes en producción. La razón es práctica. Cuando un escáner comenta en un pull request que abriste hace diez minutos, todavía tenés el contexto y el fix suele ser una línea. Cuando el mismo bug aparece seis meses después en un informe de pentest, alguien tiene que redescubrir el código, el fix puede tocar otras features y estuvo explotable todo ese tiempo.

Shift-left no significa "solo a la izquierda". Seguís necesitando controles contra la app corriendo y pruebas humanas cada tanto. Significa que los controles baratos y automatizables pasan lo antes posible.

Las prácticas clave de DevSecOps

1. SAST (Static Application Security Testing)

Analiza el código fuente sin ejecutarlo, buscando patrones como SQL injection, deserialización insegura, chequeos de autorización faltantes o criptografía débil. Es rápido y señala archivo y línea exactos, así que es ideal para pull requests. El SAST tradicional basado en reglas es conocido por los falsos positivos; enfoques más nuevos de SAST con IA intentan razonar si un hallazgo es realmente alcanzable y explotable.

2. SCA (Software Composition Analysis)

La mayor parte del código que desplegás es open source que no escribiste. El SCA lee tus lockfiles (package-lock.json, poetry.lock, Gemfile.lock, go.sum) y compara cada versión contra bases de CVEs conocidos. Ataca directo a Software Supply Chain Failures, que ahora es el #3 del OWASP Top 10 2025.

3. Secret scanning

API keys, contraseñas de base de datos y credenciales de cloud commiteadas en git son de los caminos más rápidos a una brecha. Un secret scanner tiene que revisar todo el historial de git, no solo los archivos actuales: borrar una clave en un commit posterior no la saca del repositorio. Si se filtró un secreto, rotalo; el escaneo solo te avisa que pasó.

4. Escaneo de IaC

La Infrastructure as Code (Terraform, manifiestos de Kubernetes, Dockerfiles, workflows de CI) es código y se puede configurar mal: buckets públicos, contenedores corriendo como root, security groups abiertos a 0.0.0.0/0, workflows con permisos de escritura que no necesitan. Los escáneres de IaC lo detectan antes de que se aplique.

5. DAST (Dynamic Application Security Testing)

Prueba la aplicación corriendo desde afuera, como lo haría un atacante: headers de seguridad faltantes, páginas de error expuestas, puntos de inyección, debilidades de autenticación. Complementa al SAST, no lo reemplaza; en SAST vs DAST explicamos las diferencias. Para fallas de lógica de negocio que ningún escáner encuentra seguís necesitando pentesting, manual o asistido por IA.

Un pipeline DevSecOps práctico con GitHub Actions

Este es un pipeline mínimo con herramientas open source conocidas. Corre controles de secretos, SAST, dependencias e IaC en cada pull request y en cada push a main. Adaptá las herramientas a tu stack; lo que importa es la estructura.

# .github/workflows/security.yml
name: security
on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # historial completo, así se escanean los commits viejos
      - name: Secretos en el historial de git (Gitleaks)
        run: |
          docker run --rm --user "$(id -u):$(id -g)" -v "$PWD:/repo" \
            zricethezav/gitleaks:latest detect --source /repo -v

  sast:
    runs-on: ubuntu-latest
    container: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
      - name: SAST (Semgrep, reglas OWASP Top 10)
        run: semgrep scan --config p/owasp-top-ten --error

  dependencies-and-iac:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Dependencias con CVEs conocidos (Trivy)
        run: |
          docker run --rm -v "$PWD:/src" aquasec/trivy \
            fs --scanners vuln --severity HIGH,CRITICAL --exit-code 1 /src
      - name: Malas configuraciones de IaC (Trivy)
        run: |
          docker run --rm -v "$PWD:/src" aquasec/trivy \
            config --severity HIGH,CRITICAL --exit-code 1 /src

Y un job de DAST que corre después de desplegar a staging, porque necesita una URL viva:

  dast:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: DAST baseline (OWASP ZAP)
        run: |
          docker run --rm -t ghcr.io/zaproxy/zaproxy:stable \
            zap-baseline.py -t https://staging.example.com

Algunos detalles que importan más que la herramienta elegida:

• permissions: contents: read arriba de todo. Los workflows reciben un token; dale el mínimo privilegio que necesita.
• Fijá las actions e imágenes de terceros a un commit SHA o digest en pipelines productivos. Tags como @main o :latest pueden cambiar sin aviso, y eso ya es un riesgo de supply chain.
• Al principio, fallá solo con HIGH y CRITICAL. Un pipeline que falla por cada nota de severidad baja termina desactivado en una semana.
• Activá branch protection para que los jobs de seguridad sean checks obligatorios antes de mergear.

Categorías de herramientas DevSecOps

Unir cinco o seis herramientas funciona, pero cada una tiene su configuración, su formato de salida y sus falsos positivos. Por eso muchos equipos prefieren un único escáner de seguridad para GitHub que cubra varias categorías en un solo reporte. Nurbak, por ejemplo, se conecta a GitHub y escanea un repo con su propio modelo de IA self-hosted (tu código no se manda a OpenAI ni a Anthropic para el análisis): vulnerabilidades explotables con archivo y línea, dependencias contra CVEs conocidos, malas configuraciones de GitHub Actions, Docker, Terraform y Kubernetes, y secretos en el historial de git, todo resumido en un puntaje de seguridad de 0 a 100 con explicaciones en lenguaje simple.

Cómo empezar con DevSecOps en un equipo chico

No necesitás un equipo de seguridad para hacer DevSecOps. Necesitás algunos controles automáticos, una regla sobre qué bloquea un merge y el hábito de corregir hallazgos como cualquier otro bug. Un orden realista:

1. Semana 1: secretos. Activá secret scanning con push protection y escaneá todo el historial una vez. Rotá lo que encuentres que sea real. Máximo impacto, casi cero falsos positivos.
2. Semana 1: dependencias. Activá PRs automáticos de actualización y alertas de CVEs. Mergeá primero los críticos.
3. Semana 2: SAST en pull requests, en modo no bloqueante. Leé los resultados durante dos semanas, sacá las reglas ruidosas y después hacé bloqueantes los HIGH/CRITICAL.
4. Semana 3: IaC. Si tenés Terraform, Kubernetes, Dockerfiles o workflows no triviales, sumá escaneo de IaC al mismo pipeline.
5. Semana 4: DAST baseline contra staging después de cada deploy.
6. Siempre: una regla de triage. Por ejemplo: críticos corregidos en 7 días, altos en 30, el resto revisado una vez por mes. Seguí el backlog como cualquier otra deuda técnica.
7. Cada tanto: un pentest humano (o asistido por IA) sobre los flujos que más importan: autenticación, pagos, acceso a datos multi-tenant.

La falla más común no es elegir la herramienta equivocada, es el ruido. Si los devs aprenden que el job de seguridad casi siempre se equivoca, dejan de leerlo. Priorizá menos hallazgos y más confiables, y que cada uno sea accionable: dónde está, por qué importa y cómo se arregla.

Ese último paso, corregir, es donde los equipos se traban. Algunas herramientas ya cierran el ciclo: cuando Nurbak confirma un hallazgo, puede abrir un pull request con el fix y un test de regresión de seguridad (el fix se genera con Claude, solo con tu consentimiento explícito), así la corrección pasa por tu review normal. Si querés una foto rápida antes de armar todo el pipeline, el escaneo gratis de tu repo de GitHub te muestra completos los 3 hallazgos más importantes.

Resumen

• DevSecOps es DevOps con la seguridad automatizada dentro del pipeline y como responsabilidad de todo el equipo.
• Shift-left: detectar problemas en el pull request, cuando corregirlos sale más barato.
• Las cinco prácticas clave son SAST, SCA, secret scanning, escaneo de IaC y DAST, más pentesting periódico para fallas de lógica.
• Empezá de a poco: secretos y dependencias primero, SAST no bloqueante, después ajustá.
• El ruido mata los programas de DevSecOps. Apuntá a hallazgos en los que los devs confíen y que puedan corregir.