Seguridad de Pipelines DevOps en 2026: SAST, DAST, Supply Chain y Preguntas de Entrevista

La seguridad de pipelines DevOps requiere integrar controles de seguridad en cada etapa del flujo de trabajo CI/CD, desde hooks pre-commit hasta el monitoreo en producción. El informe Datadog State of DevSecOps 2026 revela que el 87% de las organizaciones ejecutan servicios con al menos una vulnerabilidad explotable conocida, mientras que los ataques a la cadena de suministro de software ahora cuestan más de 80 mil millones de dólares anuales a la economía global.

SAST: Análisis Estático que Detecta Vulnerabilidades Antes del Merge

Static Application Security Testing (SAST) analiza el código fuente sin ejecutarlo. La herramienta parsea la base de código, construye un árbol de sintaxis abstracta y compara patrones contra firmas de vulnerabilidades conocidas. Ejecutar SAST en cada pull request detecta inyecciones SQL, XSS y credenciales hardcodeadas antes de que el código llegue a la rama principal.

Semgrep se ha convertido en la herramienta SAST open-source de referencia en 2026. A diferencia de los escáneres basados en regex, Semgrep entiende la estructura del código y soporta reglas personalizadas en YAML.

# .github/workflows/sast.yml
name: SAST Scan

on:
  pull_request:
    branches: [main, develop]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep:latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Semgrep
        run: semgrep scan --config=auto --sarif --output=semgrep.sarif
        
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

El flag --config=auto carga las reglas de la comunidad que coinciden con los lenguajes detectados. La salida SARIF se integra con la pestaña Security de GitHub para rastrear hallazgos a lo largo del tiempo.

DAST: Pruebas en Runtime que Encuentran lo que el Análisis Estático No Detecta

Dynamic Application Security Testing (DAST) ataca una aplicación en ejecución para encontrar vulnerabilidades que solo se manifiestan en runtime. Las fallas de autenticación, defectos de autorización y bugs de lógica de negocio requieren solicitudes HTTP reales para detectarse. SAST no puede detectar que un endpoint de admin carece de control de acceso apropiado, pero DAST intentará acceder sin credenciales y marcará la exposición.

OWASP ZAP sigue siendo la herramienta DAST open-source más desplegada. ZAP 3.0, lanzado a principios de 2026, agregó soporte nativo para escaneo de GraphQL y gRPC.

# .github/workflows/dast.yml
name: DAST Scan

on:
  deployment:
    types: [created]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Full Scan
        uses: zaproxy/action-full-scan@v0.12.0
        with:
          target: ${{ secrets.STAGING_URL }}
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a -j -l WARN -z "-config api.disablekey=true"'
          
      - name: Upload Report
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html

DAST se ejecuta post-despliegue porque necesita un objetivo activo. El ambiente de staging sirve como superficie de prueba, manteniendo producción aislada del tráfico de escaneo.

SCA: Escaneo de Dependencias para Vulnerabilidades Conocidas

Software Composition Analysis (SCA) escanea dependencias contra bases de datos de vulnerabilidades como la National Vulnerability Database y GitHub Advisory Database. Una sola dependencia transitiva vulnerable puede exponer toda la aplicación. El informe Datadog 2026 encontró que el 42% de los servicios dependen de bibliotecas que ya no se mantienen activamente.

Trivy escanea contenedores, sistemas de archivos y repositorios git para vulnerabilidades en un solo binario. Genera SBOMs en formatos CycloneDX y SPDX.

# .github/workflows/sca.yml
name: Dependency Scan

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * *'  # Diario a las 6 AM

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.28.0
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          
      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

El escaneo diario programado detecta CVEs recién divulgadas incluso sin cambios de código. Filtrar por severidades CRITICAL y HIGH previene la fatiga de alertas por hallazgos de bajo riesgo.

Seguridad de la Supply Chain: SBOM y Procedencia SLSA

El EU Cyber Resilience Act, con obligaciones de reporte que entran en vigor en septiembre 2026, exige la generación de Software Bill of Materials (SBOM) para productos vendidos en la UE. Un SBOM lista cada componente del software, incluyendo dependencias directas, transitivas y sus versiones.

SLSA (Supply-chain Levels for Software Artifacts) complementa SBOM verificando cómo se construyó el software. SBOM responde "¿qué componentes hay en este software?" mientras SLSA responde "¿se puede confiar en el proceso de build?"

# .github/workflows/supply-chain.yml
name: Supply Chain Security

on:
  push:
    tags:
      - 'v*'

jobs:
  build-with-provenance:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      attestations: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Build container image
        run: docker build -t myapp:${{ github.ref_name }} .
        
      - name: Generate SBOM
        uses: anchore/sbom-action@v0.17.0
        with:
          image: myapp:${{ github.ref_name }}
          format: cyclonedx-json
          output-file: sbom.json
          
      - name: Sign with Cosign
        uses: sigstore/cosign-installer@v3.7.0
        
      - name: Sign image and attach SBOM
        run: |
          cosign sign --yes myapp:${{ github.ref_name }}
          cosign attach sbom --sbom sbom.json myapp:${{ github.ref_name }}
          cosign sign --yes --attachment sbom myapp:${{ github.ref_name }}

Cosign de Sigstore firma artefactos usando firma sin claves respaldada por la autoridad de certificación Fulcio. La firma vincula el artefacto al workflow de CI que lo produjo, permitiendo verificar que la imagen proviene de un pipeline confiable.

Detección de Secretos: La Primera Línea de Defensa

Los secretos hardcodeados siguen siendo el hallazgo de seguridad más común en bases de código. Las claves de acceso AWS, contraseñas de base de datos y tokens API commiteados al control de versiones han causado brechas a toda escala. La detección de secretos se ejecuta en pre-commit para bloquear credenciales antes de que entren al repositorio.

Gitleaks detecta secretos usando patrones regex y análisis de entropía. Un hook pre-commit previene que los secretos sean commiteados.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
        args: ['--verbose']

# .github/workflows/secrets.yml
name: Secrets Detection

on:
  pull_request:

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          
      - name: Gitleaks scan
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

La opción fetch-depth: 0 clona el historial completo, permitiendo a Gitleaks escanear todos los commits del PR, no solo el más reciente.

Preguntas de Entrevista DevSecOps: Lo que Preguntan los Reclutadores

Las entrevistas DevSecOps evalúan tanto conocimiento de seguridad como experiencia práctica en CI/CD. Las preguntas siguientes aparecen frecuentemente en entrevistas 2026 para roles senior de DevOps e ingeniería de plataforma. Ver más preguntas sobre seguridad de pipelines en el módulo de entrevista CI/CD Pipeline Security.

"¿Cómo implementarías seguridad shift-left en un pipeline existente?"

La seguridad shift-left mueve las pruebas más temprano en el ciclo de desarrollo. La implementación práctica implica agregar hooks pre-commit para detección de secretos, escaneos SAST en pull requests y verificaciones SCA en la fase de build. La clave es la adopción incremental: comenzar con detección de secretos porque tiene la menor tasa de falsos positivos y la señal más alta, luego agregar SCA para CVEs conocidas, después ajustar las reglas SAST para reducir ruido antes de habilitarlo como control bloqueante.

"Explica la diferencia entre SAST y DAST. ¿Cuándo usarías cada uno?"

SAST analiza código fuente sin ejecución. Encuentra inyección SQL, XSS y criptografía insegura por coincidencia de patrones contra la estructura del código. SAST se ejecuta temprano, en cada PR, porque solo necesita el código.

DAST ataca una aplicación en ejecución. Encuentra bypasses de autenticación, control de acceso roto y vulnerabilidades de inyección que solo se manifiestan en runtime. DAST se ejecuta post-despliegue contra un ambiente de staging.

Los dos se complementan. SAST detecta errores de codificación antes del merge; DAST verifica que la aplicación desplegada se comporta de manera segura. Un pipeline maduro ejecuta ambos.

"¿Qué es un SBOM y por qué es requerido?"

Un Software Bill of Materials lista cada componente del software, incluyendo dependencias directas y transitivas con versiones exactas. Requisitos regulatorios como el EU Cyber Resilience Act exigen generación de SBOM para productos que entran al mercado europeo a partir de septiembre 2026.

Prácticamente, SBOM permite respuesta rápida a incidentes. Cuando se publica una nueva CVE, el equipo de seguridad puede consultar la base de datos SBOM para identificar cada servicio ejecutando el componente vulnerable en lugar de escanear todos los repositorios manualmente.

"¿Cómo prevenir la fatiga de alertas en herramientas de seguridad?"

La fatiga de alertas ocurre cuando los desarrolladores ignoran hallazgos de seguridad porque la relación señal-ruido es muy baja. La prevención requiere ajustar cada herramienta antes de habilitar controles bloqueantes. Para SAST, deshabilitar reglas que producen falsos positivos en la base de código y habilitarlas gradualmente después de la limpieza. Para SCA, enfocarse en hallazgos de severidad CRITICAL y HIGH con exploits conocidos. Para DAST, configurar escaneos de referencia para excluir falsos positivos de ejecuciones futuras.

La métrica a rastrear es el tiempo de corrección para vulnerabilidades reales. Si ese número aumenta, los desarrolladores están ignorando las alertas.

Seguridad de Contenedores y Runtime

El escaneo de imágenes de contenedores detecta vulnerabilidades antes del despliegue. La seguridad de runtime monitorea contenedores en producción por comportamiento anómalo. La combinación aborda tanto vulnerabilidades conocidas (CVEs en imágenes base) como amenazas desconocidas (contenedores comprometidos, criptomineros).

Trivy escanea imágenes como parte del pipeline de build. Falco monitorea comportamiento en runtime usando eBPF.

# .github/workflows/container-security.yml
name: Container Security

on:
  push:
    branches: [main]

jobs:
  scan-image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
        
      - name: Scan image
        uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: myapp:${{ github.sha }}
          format: 'table'
          exit-code: '1'
          severity: 'CRITICAL'
          ignore-unfixed: true

El flag ignore-unfixed: true omite vulnerabilidades sin parches disponibles. Esto previene bloquear despliegues por CVEs que actualmente no pueden remediarse.

Para seguridad de runtime, las reglas Falco detectan actividad sospechosa en contenedores en ejecución. El módulo de seguridad de supply chain de contenedores cubre firma de imágenes y control de admisión en profundidad.

Seguridad IaC: Escaneando Terraform y Manifests de Kubernetes

Infrastructure as Code introduce riesgos de seguridad en la capa de configuración. Políticas IAM demasiado permisivas, buckets S3 accesibles públicamente y bases de datos sin cifrar resultan de valores predeterminados inseguros en templates IaC.

Checkov escanea Terraform, CloudFormation, Kubernetes, Helm y Dockerfiles para malas configuraciones.

# .github/workflows/iac-scan.yml
name: IaC Security Scan

on:
  pull_request:
    paths:
      - 'terraform/**'
      - 'k8s/**'
      - 'helm/**'

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@v12
        with:
          directory: .
          framework: terraform,kubernetes,helm
          output_format: sarif
          output_file_path: checkov.sarif
          soft_fail: false
          
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov.sarif

El filtro de ruta asegura que los escaneos IaC solo se ejecuten cuando los archivos de infraestructura cambian, reduciendo el tiempo de CI para cambios solo de aplicación.

El Pipeline DevSecOps Completo para 2026

Un pipeline DevSecOps listo para producción en 2026 integra estas herramientas en cada etapa:

• Pre-commit: Gitleaks (secretos), SAST local opcional
• Pull request: Semgrep (SAST), Trivy (SCA), Checkov (IaC)
• Build: Escaneo de imágenes de contenedores, generación SBOM
• Pre-deploy: Firma de imágenes con Cosign, control de admisión con Kyverno
• Post-deploy: DAST con ZAP contra staging
• Runtime: Falco para monitoreo de contenedores, gestión de postura de seguridad cloud

El stack gratuito (Semgrep, Trivy, ZAP, Gitleaks, Checkov, Falco) cubre cada categoría. Las herramientas comerciales agregan dashboards centralizados, gestión de políticas y esfuerzo de ajuste reducido, pero la cobertura de seguridad es alcanzable sin costos de licencia.

Las organizaciones que se preparan para roles DevSecOps deberían practicar construyendo estos pipelines en proyectos personales. El módulo de gestión de identidades cloud y secretos cubre el lado de gestión de secretos de la ecuación.