La seguridad en el desarrollo de software ya no puede ser una fase aislada al final del ciclo de vida. Integrar pruebas de seguridad automatizadas directamente en los pipelines de CI/CD es una necesidad para cualquier equipo que aspire a entregar software confiable y seguro. SAST (Static Application Security Testing) y DAST (Dynamic Application Security Testing) son las dos metodologias fundamentales que permiten detectar vulnerabilidades tanto en el código fuente como en la aplicación en ejecución, y su combinación dentro del pipeline proporciona una cobertura de seguridad robusta.

SAST vs DAST: Diferencias Fundamentales

Antes de implementar estas pruebas en un pipeline, es esencial comprender que problema resuelve cada una y en que momento del ciclo se aplican.

SAST - Análisis Estatico de Seguridad

SAST analiza el código fuente, bytecode o binario sin ejecutar la aplicación. Funciona como una revision automatizada del código buscando patrones que representan vulnerabilidades conocidas: inyecciones SQL, cross-site scripting (XSS), buffer overflows, uso inseguro de criptografia, credenciales hardcodeadas y mas.

Caracteristicas clave de SAST:

  • Se ejecuta en etapas tempranas del pipeline (sobre el código fuente directamente)
  • Identifica la linea exacta de código donde existe la vulnerabilidad
  • No necesita un entorno de ejecución desplegado
  • Puede generar un número significativo de falsos positivos
  • Soporta multiples lenguajes de programación segun la herramienta

DAST - Análisis Dinamico de Seguridad

DAST prueba la aplicación en ejecución, simulando ataques reales contra los endpoints expuestos. No tiene acceso al código fuente; trabaja como un atacante externo que envia peticiones maliciosas y analiza las respuestas.

Caracteristicas clave de DAST:

  • Requiere la aplicación desplegada y accesible (staging o entorno de pruebas)
  • Detecta vulnerabilidades de configuración, autenticación, y comportamiento en runtime
  • Menor tasa de falsos positivos comparado con SAST
  • No puede senalar la linea de código exacta del problema
  • Detecta problemas que SAST no puede ver: headers de seguridad faltantes, configuraciones de CORS, cookies inseguras

Complementariedad

La clave esta en entender que SAST y DAST no compiten entre si, sino que se complementan. SAST encuentra problemas en el código antes del despliegue; DAST encuentra problemas de configuración y comportamiento despues del despliegue. Un pipeline maduro utiliza ambos.

Herramientas Principales

El ecosistema de herramientas de seguridad para pipelines es amplio. Estas son las mas adoptadas en entornos DevOps:

SonarQube (SAST)

SonarQube es una de las plataformas mas populares para análisis estatico de código. Soporta mas de 30 lenguajes y se integra nativamente con la mayoria de sistemas de CI/CD. Además de seguridad, evalua calidad de código, cobertura de tests y deuda técnica.

# Ejemplo: Stage de SonarQube en GitLab CI
sonarqube-check:
  stage: test
  image: sonarsource/sonar-scanner-cli:latest
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
    GIT_DEPTH: "0"
  script:
    - sonar-scanner
      -Dsonar.projectKey=${CI_PROJECT_NAME}
      -Dsonar.sources=src/
      -Dsonar.host.url=${SONAR_HOST_URL}
      -Dsonar.token=${SONAR_TOKEN}
      -Dsonar.qualitygate.wait=true
  allow_failure: false

Snyk (SAST + SCA)

Snyk se especializa en análisis de dependencias (Software Composition Analysis) y también ofrece SAST. Es particularmente fuerte detectando vulnerabilidades en paquetes de terceros, que representan una superficie de ataque enorme en proyectos modernos.

# Ejemplo: Snyk en GitHub Actions
- name: Run Snyk Security Scan
  uses: snyk/actions/node@master
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  with:
    args: --severity-threshold=high --fail-on=all

Trivy (Escaneo de Contenedores e IaC)

Trivy, desarrollado por Aqua Security, es una herramienta open-source que escanea imagenes de contenedores, repositorios de código, sistemas de archivos y configuraciones de IaC (Terraform, Kubernetes manifests). Es rápida, fácil de integrar y no requiere servidor.

# Ejemplo: Trivy scan de imagen Docker en GitHub Actions
- name: Scan Docker image with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'myapp:${{ github.sha }}'
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'

- name: Upload Trivy scan results
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: 'trivy-results.sarif'

OWASP ZAP (DAST)

OWASP ZAP (Zed Attack Proxy) es la herramienta DAST open-source de referencia. Puede ejecutarse en modo headless dentro de pipelines, realizando escaneos activos y pasivos contra aplicaciones desplegadas.

# Ejemplo: OWASP ZAP en GitHub Actions
- name: OWASP ZAP Full Scan
  uses: zaproxy/[email protected]
  with:
    target: 'https://staging.myapp.com'
    rules_file_name: '.zap/rules.tsv'
    fail_action: true
    cmd_options: '-a -j -l WARN'

Integración en el Pipeline CI/CD

Arquitectura del Pipeline con Seguridad

Un pipeline con seguridad integrada sigue una estructura donde las pruebas de seguridad se ejecutan en diferentes etapas:

[Commit] -> [Build] -> [SAST + SCA] -> [Unit Tests] -> [Build Image]
    -> [Trivy Scan] -> [Deploy Staging] -> [DAST] -> [Deploy Prod]

Ejemplo Completo en GitHub Actions

name: CI/CD with Security
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  sast:
    name: Static Analysis
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@v5
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

      - name: Snyk Code Test
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          command: code test

  container-scan:
    name: Container Security
    needs: sast
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker Image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Trivy Vulnerability Scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:${{ github.sha }}'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

  dast:
    name: Dynamic Analysis
    needs: container-scan
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Staging
        run: |
          # Deploy application to staging environment
          kubectl apply -f k8s/staging/

      - name: Wait for deployment
        run: kubectl rollout status deployment/myapp -n staging

      - name: OWASP ZAP Scan
        uses: zaproxy/[email protected]
        with:
          target: 'https://staging.example.com'
          fail_action: true

Ejemplo en GitLab CI

stages:
  - build
  - sast
  - container_scan
  - deploy_staging
  - dast
  - deploy_prod

sast:
  stage: sast
  image: sonarsource/sonar-scanner-cli:latest
  script:
    - sonar-scanner -Dsonar.qualitygate.wait=true
  allow_failure: false

dependency_scan:
  stage: sast
  image: snyk/snyk:node
  script:
    - snyk test --severity-threshold=high
    - snyk monitor

container_scan:
  stage: container_scan
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

dast:
  stage: dast
  image: ghcr.io/zaproxy/zaproxy:stable
  script:
    - zap-full-scan.py -t $STAGING_URL -r zap_report.html -w zap_report.md
  artifacts:
    reports:
      dast: zap_report.json

Shift-Left Security: Mover la Seguridad al Inicio

El concepto de shift-left se refiere a mover las pruebas de seguridad lo mas temprano posible en el ciclo de desarrollo. En la práctica, esto significa:

  • Pre-commit hooks: Ejecutar linters de seguridad antes de que el código llegue al repositorio. Herramientas como gitleaks o detect-secrets previenen que credenciales se suban al repo.
  • IDE plugins: SonarLint, Snyk IDE extensions y similares dan feedback de seguridad mientras el desarrollador escribe código.
  • Pull Request checks: Escaneos SAST obligatorios como parte de los checks del PR, bloqueando el merge si se detectan vulnerabilidades criticas.
# Ejemplo: pre-commit hook con gitleaks
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

La ventaja economica del shift-left es clara: corregir una vulnerabilidad en desarrollo cuesta una fracción de lo que cuesta corregirla en producción, tanto en tiempo como en impacto al negocio.

Gestión de Hallazgos y Falsos Positivos

Uno de los mayores desafios al implementar SAST y DAST en pipelines es gestionar el volumen de hallazgos. Sin una estrategia clara, los equipos terminan ignorando las alertas o desactivando las herramientas.

Estrategias para Gestionar Hallazgos

Clasificación por severidad: Configura las herramientas para que solo bloqueen el pipeline ante vulnerabilidades de severidad CRITICA y ALTA. Las de severidad media y baja se registran como issues para revision posterior.

Baseline de supresion: Establece un baseline inicial de hallazgos conocidos que seran abordados gradualmente. Los nuevos hallazgos si bloquean el pipeline. Esto es esencial para equipos que adoptan estas herramientas en proyectos existentes con deuda de seguridad.

# Ejemplo: Trivy con ignore file para falsos positivos conocidos
- name: Trivy Scan
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'myapp:latest'
    trivyignores: '.trivyignore'
    severity: 'CRITICAL,HIGH'

Revision periodica de supresiones: Cada sprint o cada mes, el equipo revisa las vulnerabilidades suprimidas para determinar si ya pueden ser corregidas o si la supresion sigue siendo válida.

Integración con issue trackers: Configura la exportación automática de hallazgos a Jira, GitHub Issues o la herramienta que use el equipo, asignando responsables y deadlines segun la severidad.

Métricas Clave a Monitorear

  • MTTR de seguridad (Mean Time to Remediate): Tiempo promedio desde la detección hasta la corrección
  • Tasa de falsos positivos: Porcentaje de hallazgos que resultan ser falsos positivos
  • Cobertura de escaneo: Porcentaje del código y dependencias que estan siendo analizados
  • Vulnerabilidades por release: Tendencia de vulnerabilidades detectadas en cada release

Mejores Prácticas de Implementación

  1. Implementación gradual: Comienza con SAST en modo no bloqueante (allow_failure: true), permite que los equipos se familiaricen con los hallazgos, y luego activa el bloqueo.

  2. Cacheo de resultados: Las herramientas SAST pueden ser lentas. Configura cache para evitar re-escanear código que no cambio entre commits.

  3. Escaneo incremental: En pull requests, escanea solo los archivos modificados. El escaneo completo se reserva para la rama principal.

  4. Reportes centralizados: Consolida los resultados de todas las herramientas en un dashboard único (DefectDojo, SonarQube, o plataformas como Snyk).

  5. Políticas como código: Define las políticas de seguridad en archivos versionados junto al código del proyecto (quality gates, reglas de supresion, umbrales de severidad).

Conclusion

Integrar SAST y DAST en los pipelines de CI/CD transforma la seguridad de un cuello de botella en una parte natural del flujo de desarrollo. La clave esta en la implementación gradual, la gestión inteligente de hallazgos y la combinación de ambas metodologias para cubrir tanto el código fuente como el comportamiento en ejecución. Los equipos que adoptan este enfoque no solo entregan software mas seguro, sino que reducen significativamente el costo y el tiempo de remediación de vulnerabilidades.

Preguntas Frecuentes sobre SAST y DAST

¿Qué es SAST?

SAST (Static Application Security Testing) es el análisis de seguridad del código fuente sin ejecutarlo. Detecta vulnerabilidades como inyecciones, secretos hardcodeados o malas prácticas directamente en el código, en etapas tempranas del desarrollo. Herramientas típicas: SonarQube, Semgrep, Snyk Code y Checkmarx.

¿Qué es DAST?

DAST (Dynamic Application Security Testing) es el análisis de seguridad de una aplicación en ejecución, probándola desde fuera como lo haría un atacante. Detecta vulnerabilidades en runtime (XSS, configuraciones inseguras, fallos de autenticación) que no se ven en el código estático. Herramientas típicas: OWASP ZAP y Burp Suite.

¿Cuál es la diferencia entre SAST y DAST?

SAST analiza el código fuente sin ejecutarlo (caja blanca) y se aplica temprano en el desarrollo; DAST analiza la aplicación en ejecución desde fuera (caja negra) y se aplica en etapas más tardías. Son complementarios: SAST encuentra fallos en el código y DAST los valida en runtime. Un pipeline maduro usa ambos.

¿Qué es SCA y cómo se relaciona con SAST y DAST?

SCA (Software Composition Analysis) analiza las dependencias y librerías de terceros en busca de vulnerabilidades conocidas (CVE) y problemas de licencias. Complementa a SAST (código propio) y DAST (runtime): juntos cubren código, dependencias y comportamiento en ejecución. Herramientas: Snyk, Dependabot y OWASP Dependency-Check.

¿Cómo integrar SAST y DAST en un pipeline CI/CD?

Integrá SAST en etapas tempranas del pipeline (en cada commit o pull request) para detectar fallos antes del merge, y DAST en etapas posteriores contra un entorno de staging desplegado. Configurá umbrales que rompan el build ante vulnerabilidades críticas, pero ajustá la sensibilidad para evitar falsos positivos que frenen al equipo.

Recursos