• Con integración y despliegue continuos, el tiempo entre un commit y producción se reduce de meses a horas.
• Una auditoría manual de dos semanas por versión no puede ejecutarse en cada despliegue.
• DevSecOps implementa los controles de seguridad como etapas automatizadas del pipeline, ejecutadas en cada commit.

• Los requisitos de seguridad se definen junto con los funcionales, y los controles los mantiene el mismo equipo que desarrolla y opera el sistema.
• Se implementa con herramientas de análisis integradas al repositorio, al pipeline de CI/CD y al entorno de ejecución.

Cifras del informe Cost of a Data Breach 2025 de IBM y el Ponemon Institute.

La revisión de seguridad es una etapa posterior al desarrollo, ejecutada por un equipo separado antes de la liberación.

• Los hallazgos se reportan semanas después del commit que los introdujo.
• Corregir un defecto de diseño al final obliga a rehacer trabajo que se había dado por terminado.
• La capacidad del equipo de seguridad limita el número de liberaciones posibles.
• Los hallazgos no críticos se difieren y se acumulan como deuda de seguridad.

• La guía DevSecOps de OWASP plantea como objetivo detectar los problemas de seguridad lo más rápido posible.
• Un hallazgo reportado en el pull request lo corrige el autor del cambio antes del merge. En producción requiere un proceso de respuesta a incidentes.

• Después del despliegue se publican CVE nuevos que afectan a código y dependencias que ya pasaron el pipeline.
• Los controles en producción, como monitoreo, WAF y escaneo periódico de dependencias, siguen siendo necesarios.

flowchart LR
    subgraph P[Planificar]
        P1[Modelado de amenazas]
    end
    subgraph C[Codificar]
        C1[Pre-commit y secretos]
    end
    subgraph B[Build]
        B1[SAST y SCA]
    end
    subgraph T[Pruebas]
        T1[DAST]
    end
    subgraph D[Despliegue]
        D1[IaC, imágenes y firma]
    end
    subgraph O[Operación]
        O1[Monitoreo y respuesta]
    end
    P --> C --> B --> T --> D --> O
        

• Es la única práctica del ciclo que encuentra defectos de diseño, porque ninguna herramienta automática sabe lo que el sistema debería hacer.
• El modelo STRIDE de Microsoft clasifica las amenazas en seis categorías.

Las dos técnicas detectan clases distintas de defectos y se ejecutan en etapas distintas del pipeline.

• La organización no tenía un inventario que relacionara cada aplicación con las versiones de sus dependencias.
• Práctica que lo habría evitado. Inventario de dependencias y SCA en cada build.

• El malware no estaba en el repositorio. Se inyectaba durante la compilación, así que la revisión de código no podía detectarlo.
• Práctica que lo habría mitigado. Proteger el pipeline como producción, builds reproducibles y registros de procedencia (SLSA).

• Las variables de entorno del pipeline contenían credenciales de despliegue, tokens de repositorios y claves de servicios en la nube.
• Práctica que lo habría mitigado. Verificar la integridad de lo descargado, fijar versiones y dar al pipeline solo los secretos mínimos.

• Log4j aparecía con frecuencia como dependencia transitiva, sin declararse en el archivo de dependencias del proyecto.
• Práctica que lo habría mitigado. Un SBOM por artefacto y análisis de dependencias transitivas.

• El código malicioso no estaba en el repositorio visible, sino en los archivos de distribución empaquetados.
• Práctica que lo habría mitigado. Builds reproducibles que verifiquen que el paquete distribuido corresponde al código del repositorio.

• Práctica que lo habría evitado. Un hook de pre-commit que detecte secretos y credenciales guardadas en un gestor de secretos, nunca en el código.

// Inseguro, la clave queda en el repositorio
const stripe = new Stripe('sk_live_51Hx9QfK2...');

// Seguro, la clave se lee del entorno
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

Gitleaks revisa cada commit en la máquina del desarrollador y lo rechaza si encuentra un secreto.

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

name: Seguridad
on:
  pull_request:
    branches: [main]
permissions:
  contents: read
jobs:
  analizar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: {{ secrets.GITHUB_TOKEN }}
      - run: npm ci
      - run: npm audit --audit-level=high
      - run: >
          pipx run semgrep scan
          --config p/owasp-top-ten --error