Ci-Cd on Adur

Seguridad shift-left: integrando Trivy y Semgrep en GitLab CI

Mon, 16 Mar 2026 00:00:00 +0000

Por qué estas dos herramientas y no otras

La oferta de herramientas de seguridad para pipelines es enorme, y es fácil acabar con un pipeline que tarda veinte minutos solo en escaneos. Después de probar varias combinaciones, me quedo con Trivy y Semgrep por una razón sencilla: cubren dos superficies de ataque distintas con mínima fricción.

Semgrep analiza tu código fuente buscando patrones peligrosos — inyecciones SQL, deserialización insegura, secretos hardcodeados. Lo hace rápido y sin necesitar compilar nada. Trivy, por su parte, se encarga de todo lo que no es tu código: dependencias con CVEs conocidos, imágenes base desactualizadas, configuraciones de IaC problemáticas. Entre los dos cubres código propio y código ajeno.

Ambas son open-source, se ejecutan sin servidor externo y producen salida JSON que puedes parsear fácilmente en CI. No necesitas licencias ni dashboards de terceros para empezar.

Estructura del pipeline

La idea es que la seguridad no sea una etapa aislada al final, sino algo que se ejecuta en paralelo con el resto de checks. Este es el esquema general:

1
2
3
4
5
6
7
8
9


stages:
 - test
 - security
 - build
 - deploy

variables:
 TRIVY_SEVERITY: "HIGH,CRITICAL"
 SEMGREP_RULES: "p/owasp-top-ten p/security-audit"

La etapa security corre al mismo nivel que test. Si algún escaneo falla, el pipeline se detiene antes de construir la imagen o desplegar nada.

Configurando Semgrep

Job básico

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


semgrep:
 stage: security
 image: semgrep/semgrep:latest
 script:
 - semgrep ci --config "$SEMGREP_RULES" --json --output semgrep-results.json
 artifacts:
 paths:
 - semgrep-results.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Esto ejecuta Semgrep en cada merge request y en cada push a la rama principal. Los resultados se guardan siempre como artefacto, incluso si el pipeline falla — querrás poder revisarlos después.

Reglas personalizadas

Los rulesets genéricos están bien para empezar, pero en cuanto tengas patrones propios que quieras detectar, necesitarás reglas custom. Crea un directorio .semgrep/ en la raíz del proyecto:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# .semgrep/no-env-secrets.yml
rules:
 - id: no-os-environ-secrets
 patterns:
 - pattern: os.environ[$KEY]
 - metavariable-regex:
 metavariable: $KEY
 regex: ".*(SECRET|PASSWORD|TOKEN|KEY).*"
 message: "Acceso directo a secretos desde variables de entorno. Usa el gestor de secretos."
 languages: [python]
 severity: WARNING

Y referéncialo en el pipeline:

1
2


variables:
 SEMGREP_RULES: "p/owasp-top-ten p/security-audit .semgrep/"

Gestionando falsos positivos

Va a haber falsos positivos. Es inevitable. Lo que importa es cómo los gestionas. La peor reacción es desactivar la regla entera o poner allow_failure: true. En su lugar, usa anotaciones inline:

1
2


# nosemgrep: python.lang.security.audit.hardcoded-password
TEST_PASSWORD = "dummy" # fixture de tests, no se usa en producción

Cada supresión debería tener un comentario que explique por qué es seguro ignorarla. Sin excepción. Si no puedes justificarlo, no lo suprimas.

Para supresiones más amplias, usa .semgrepignore:

1
2
3
4


# Excluir fixtures de test
tests/fixtures/
# Excluir código generado automáticamente
*_generated.py

Configurando Trivy

Escaneo de dependencias

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


trivy-fs:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 script:
 - trivy fs --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-fs.json .
 artifacts:
 paths:
 - trivy-fs.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Trivy examina los lockfiles del proyecto (package-lock.json, requirements.txt, go.sum, etc.) y cruza las versiones con bases de datos de vulnerabilidades. El flag --exit-code 1 hace que el job falle si encuentra algo HIGH o CRITICAL.

Escaneo de imágenes de contenedor

Si construyes imágenes Docker, escanéalas antes de publicarlas en el registry:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


trivy-image:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 needs:
 - job: build-image
 artifacts: true
 script:
 - trivy image --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-image.json "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
 artifacts:
 paths:
 - trivy-image.json
 when: always
 rules:
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Este job depende del build de la imagen (con needs) y solo se ejecuta en la rama principal, no en cada MR. Escanear imágenes es más lento que escanear el filesystem, así que reserva eso para lo que realmente se va a desplegar.

Escaneo de IaC

Una ventaja de Trivy que a menudo se pasa por alto es que también analiza configuraciones de infraestructura:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


trivy-iac:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 script:
 - trivy config --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-iac.json .
 artifacts:
 paths:
 - trivy-iac.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 changes:
 - "**/*.tf"
 - "**/Dockerfile"
 - "**/*.yml"
 - "**/*.yaml"

Detecta Dockerfiles que corren como root, archivos de Terraform con security groups demasiado abiertos, y configuraciones de Kubernetes sin límites de recursos. El bloque changes hace que solo se ejecute cuando se modifican archivos relevantes, evitando escaneos innecesarios.

Políticas de bloqueo

No empieces bloqueando todo desde el primer día. Eso genera frustración, workarounds creativos y al final alguien pone allow_failure: true en todos los jobs de seguridad.

Mejor hacerlo por fases:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Fase 1: Solo informar
semgrep:
 allow_failure: true

# Fase 2: Bloquear solo críticos
semgrep:
 script:
 - semgrep ci --config "$SEMGREP_RULES" --json --output semgrep-results.json
 - |
 CRITICAL=$(jq '[.results[] | select(.extra.severity == "ERROR")] | length' semgrep-results.json)
 if [ "$CRITICAL" -gt 0 ]; then
 echo "Bloqueado: $CRITICAL hallazgos críticos"
 exit 1
 fi
 allow_failure: false

# Fase 3: Bloquear high + critical
# ... ajustar el filtro jq

Lo mismo aplica para Trivy. El flag --severity ya te permite controlar qué niveles bloquean el pipeline. Empieza solo con CRITICAL, y cuando el equipo se haya adaptado, añade HIGH.

El pipeline completo

Poniendo todo junto:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79


stages:
 - test
 - security
 - build
 - deploy

variables:
 TRIVY_SEVERITY: "HIGH,CRITICAL"
 SEMGREP_RULES: "p/owasp-top-ten p/security-audit"

semgrep:
 stage: security
 image: semgrep/semgrep:latest
 script:
 - semgrep ci --config "$SEMGREP_RULES" --json --output semgrep-results.json
 - |
 CRITICAL=$(jq '[.results[] | select(.extra.severity == "ERROR")] | length' semgrep-results.json)
 echo "Hallazgos críticos: $CRITICAL"
 if [ "$CRITICAL" -gt 0 ]; then
 echo "Pipeline bloqueado"
 exit 1
 fi
 artifacts:
 paths:
 - semgrep-results.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

trivy-fs:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 script:
 - trivy fs --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-fs.json .
 artifacts:
 paths:
 - trivy-fs.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

trivy-config:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 script:
 - trivy config --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-iac.json .
 artifacts:
 paths:
 - trivy-iac.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 changes:
 - "**/*.tf"
 - "**/Dockerfile"
 - "**/*.yml"

trivy-image:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 needs:
 - job: build
 artifacts: true
 script:
 - trivy image --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-image.json "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
 artifacts:
 paths:
 - trivy-image.json
 when: always
 rules:
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Semgrep y los escaneos de Trivy corren en paralelo dentro de la etapa security. Si cualquiera falla, el pipeline se detiene antes de construir o desplegar.

Integrando resultados en merge requests

Los reportes JSON están bien para auditoría, pero los desarrolladores necesitan feedback visible directamente en el MR. GitLab soporta reportes de seguridad nativos si usas las plantillas oficiales, pero con herramientas externas puedes parsear el JSON y comentar en el MR:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


comment-results:
 stage: .post
 image: alpine:latest
 script:
 - apk add --no-cache curl jq
 - |
 SEMGREP_COUNT=$(jq '.results | length' semgrep-results.json 2>/dev/null || echo "0")
 TRIVY_COUNT=$(jq '.Results[]?.Vulnerabilities // [] | length' trivy-fs.json 2>/dev/null || echo "0")

 BODY="### Resumen de seguridad\n- Semgrep: ${SEMGREP_COUNT} hallazgos\n- Trivy: ${TRIVY_COUNT} vulnerabilidades"

 curl --request POST \
 --header "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \
 --header "Content-Type: application/json" \
 --data "{\"body\": \"$BODY\"}" \
 "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}/notes"
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 allow_failure: true

No es lo más elegante, pero funciona. Si usas GitLab Ultimate tienes los reportes de seguridad integrados. Si no, esto da visibilidad suficiente.

Caché y rendimiento

Los escaneos añaden tiempo al pipeline, y si ese tiempo es excesivo el equipo los acabará desactivando. Algunas cosas que ayudan:

1
2
3
4
5
6
7
8


trivy-fs:
 variables:
 TRIVY_CACHE_DIR: ".trivycache/"
 cache:
 key: trivy-db
 paths:
 - .trivycache/
 # ...resto del job

Cachear la base de datos de vulnerabilidades de Trivy evita descargarla en cada ejecución. Son unos 40MB que se descarga de GitHub, y en runners compartidos esa descarga puede tardar bastante.

Para Semgrep, el propio binario ya es rápido, pero si tu repositorio es grande, limita los paths:

1
2
3


semgrep:
 script:
 - semgrep ci --config "$SEMGREP_RULES" --include="src/" --include="app/" --json --output semgrep-results.json

No pierdas tiempo escaneando node_modules/, vendor/ o directorios de assets.

Lo que aprendí configurando esto

Llevo un tiempo con esta configuración en producción y hay cosas que solo se ven con el uso:

Trivy detecta muchos CVEs en imágenes base que no tienen fix disponible. Si no filtras por --ignore-unfixed, vas a tener ruido constante. Mejor añadir ese flag y centrarte en lo que puedes corregir:

1

trivy image --ignore-unfixed --severity HIGH,CRITICAL mi-imagen:latest

Con Semgrep, los rulesets de comunidad son un buen punto de partida, pero las reglas que más valor aportan son las que escribes tú, adaptadas a los patrones de tu proyecto. Una regla que detecta que alguien usa el ORM sin parametrizar queries vale más que cien reglas genéricas.

Y lo más importante: no intentes tapar todos los agujeros a la vez. Empieza con los escaneos en modo informativo, revisa qué sale, ajusta las reglas, y solo entonces empieza a bloquear. Si el primer día bloqueas todo, el segundo día alguien habrá puesto allow_failure: true en cada job.

Integración de pruebas SAST/DAST en pipelines CI/CD

Sun, 12 May 2024 00:00:00 +0000

SAST vs DAST: Entendiendo la Diferencia

Las pruebas de seguridad se dividen en dos enfoques fundamentales, y saber cuándo usar cada uno importa para tu postura.

SAST (Static Application Security Testing) lee código fuente, bytecode o binarios sin ejecutar la app. Busca patrones que coincidan con vulnerabilidades conocidas (SQL injection, XSS, credenciales hardcodeadas, deserialización insegura). Piensa en ello como un linter de seguridad que marca patrones peligrosos.

DAST (Dynamic Application Security Testing) prueba una aplicación en ejecución enviando peticiones crafteadas y analizando respuestas. Simula lo que haría un atacante: sondeando endpoints, testeando autenticación, buscando misconfiguraciones. DAST ve la app desde afuera, como un atacante real.

Aspecto	SAST	DAST
Cuando se ejecuta	Build time, sobre código fuente	Runtime, contra app desplegada
Qué encuentra	Fallos de código, secretos hardcodeados, patrones inseguros	Vulnerabilidades en runtime, misconfiguraciones, problemas de autenticación
Tasa de falsos positivos	Mayor (sin contexto de ejecución)	Menor (testea comportamiento real)
Dependencia de lenguaje	Sí (necesita reglas específicas)	No (testea capa HTTP/API)
Cobertura	Todas las rutas de código (incluso código muerto)	Solo endpoints alcanzables
Velocidad	Rápido (segundos a minutos)	Más lento (minutos a horas)
Mejor etapa	Cada commit/PR	Staging o pre-producción

Respuesta corta: usa ambos. SAST detecta temprano y barato. DAST detecta lo que solo aparece en runtime. Se complementan.

Comparativa de Herramientas

Herramientas SAST

Herramienta	Lenguajes	Fortalezas	Licencia
Semgrep	30+ lenguajes	Rápido, reglas personalizadas, gran integración CI	OSS + Comercial
SonarQube	25+ lenguajes	Ecosistema amplio, quality gates, dashboard	Community + Comercial
Bandit	Solo Python	Específico para Python, ligero, fácil configuración	OSS (Apache 2.0)
CodeQL	10+ lenguajes	Analisis semantico profundo, nativo en GitHub	Gratis para OSS

Herramientas DAST

Herramienta	Tipo	Fortalezas	Licencia
OWASP ZAP	Escaner basado en proxy	Completo, scriptable, reglas de la comunidad	OSS (Apache 2.0)
Burp Suite	Escaner basado en proxy	Lo mejor para testing manual + automatizado	Comercial
Nuclei	Escaner basado en templates	Rapido, enorme biblioteca de templates, CI-friendly	OSS (MIT)

Para la mayoria de equipos, Semgrep + OWASP ZAP proporciona una excelente base open-source que cubre tanto SAST como DAST sin costes de licencia.

Integracion en Pipeline de GitLab CI

Aqui tienes un ejemplo completo de .gitlab-ci.yml que integra tanto SAST como DAST en un pipeline con gating apropiado:

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102


stages:
 - build
 - test
 - sast
 - deploy-staging
 - dast
 - deploy-production

variables:
 SEMGREP_RULES: "p/owasp-top-ten p/security-audit"
 ZAP_TARGET_URL: "https://staging.example.com"

# --- Etapa SAST ---
semgrep-scan:
 stage: sast
 image: semgrep/semgrep:latest
 script:
 - semgrep ci --config "$SEMGREP_RULES" --json --output semgrep-results.json
 - |
 # Bloquear pipeline si los hallazgos altos/criticos superan el umbral
 HIGH_COUNT=$(cat semgrep-results.json | jq '[.results[] | select(.extra.severity == "ERROR")] | length')
 echo "High severity findings: $HIGH_COUNT"
 if [ "$HIGH_COUNT" -gt 0 ]; then
 echo "Pipeline blocked: $HIGH_COUNT high severity findings"
 exit 1
 fi
 artifacts:
 paths:
 - semgrep-results.json
 when: always
 allow_failure: false

bandit-scan:
 stage: sast
 image: python:3.11-slim
 script:
 - pip install bandit
 - bandit -r src/ -f json -o bandit-results.json --severity-level medium || true
 - |
 HIGH_COUNT=$(cat bandit-results.json | jq '.results | map(select(.issue_severity == "HIGH")) | length')
 echo "Bandit high severity findings: $HIGH_COUNT"
 if [ "$HIGH_COUNT" -gt 3 ]; then
 exit 1
 fi
 artifacts:
 paths:
 - bandit-results.json
 when: always
 only:
 - merge_requests
 - main

# --- Despliegue Staging ---
deploy-staging:
 stage: deploy-staging
 script:
 - echo "Deploying to staging..."
 - ./deploy.sh staging
 environment:
 name: staging
 url: https://staging.example.com

# --- Etapa DAST ---
owasp-zap-scan:
 stage: dast
 image: ghcr.io/zaproxy/zaproxy:stable
 script:
 - mkdir -p /zap/wrk
 - |
 zap-full-scan.py \
 -t "$ZAP_TARGET_URL" \
 -r zap-report.html \
 -J zap-results.json \
 -l WARN \
 -d
 - |
 # Parsear resultados y aplicar politica
 HIGH_ALERTS=$(cat zap-results.json | jq '[.site[].alerts[] | select(.riskcode == "3")] | length')
 echo "High risk alerts: $HIGH_ALERTS"
 if [ "$HIGH_ALERTS" -gt 0 ]; then
 echo "Pipeline blocked: $HIGH_ALERTS high risk vulnerabilities found"
 exit 1
 fi
 artifacts:
 paths:
 - zap-report.html
 - zap-results.json
 when: always
 dependencies:
 - deploy-staging

# --- Despliegue Produccion ---
deploy-production:
 stage: deploy-production
 script:
 - echo "Deploying to production..."
 - ./deploy.sh production
 environment:
 name: production
 when: manual
 only:
 - main

Las decisiones de diseno clave en este pipeline:

SAST se ejecuta en cada merge request, detectando problemas antes de que el codigo se fusione
DAST se ejecuta contra staging, testeando la aplicacion desplegada
Los umbrales son configurables: tolerancia cero para hallazgos SAST altos/criticos, pero cierta flexibilidad para severidades menores
Los informes siempre se guardan como artefactos, incluso cuando el pipeline pasa
El despliegue a produccion es manual, bloqueado detras de las etapas SAST y DAST

Gestion de Falsos Positivos

Los falsos positivos son la razon numero uno por la que los equipos abandonan el escaneo de seguridad. Gestionalos de forma sistematica:

Para Semgrep

Crea un archivo .semgrepignore o usa anotaciones inline:

1
2


# nosemgrep: python.lang.security.audit.hardcoded-password
DEFAULT_TEST_PASSWORD = "test123" # Solo usado en fixtures de test

Para falsos positivos persistentes, crea un semgrep-exclusions.yml:

1
2
3
4
5
6
7


rules:
 - id: ignore-test-passwords
 pattern: $X = "..."
 paths:
 exclude:
 - tests/
 - fixtures/

Para OWASP ZAP

Usa un archivo de contexto para excluir falsos positivos conocidos:

1
2
3
4
5
6
7


<alertFilter>
 <ruleId>10038</ruleId>
 <url>https://staging.example.com/api/health</url>
 <urlIsRegex>false</urlIsRegex>
 <enabled>true</enabled>
 <newRisk>-1</newRisk> <!-- -1 = Falso Positivo -->
</alertFilter>

La regla de oro: cada supresion debe incluir un comentario de justificacion explicando por que es seguro ignorarlo. Revisa las supresiones trimestralmente.

Politicas de Umbrales y Gates

Define politicas claras por entorno y severidad:

Severidad	Gate PR/MR	Gate Rama Principal	Pre-Produccion
Critica	Bloquear	Bloquear	Bloquear
Alta	Bloquear	Bloquear	Avisar
Media	Avisar	Avisar	Info
Baja	Info	Info	Info

Implementa estos como codigos de salida en tus scripts CI. Empieza de forma permisiva y endurece con el tiempo – bloquear todo desde el primer dia creara frustracion y workarounds.

Informes y Dashboards

Agrega resultados de SAST y DAST en una vista centralizada:

DefectDojo: plataforma open-source de gestion de vulnerabilidades que ingesta informes de Semgrep, ZAP, Bandit y docenas de otras herramientas
GitLab Security Dashboard: integracion nativa si estas en GitLab Ultimate
Dashboards personalizados: envia resultados de escaneo a Elasticsearch y visualiza en Grafana

Rastrea estas metricas a lo largo del tiempo:

Tiempo medio de remediacion (MTTR) por severidad
Total de vulnerabilidades abiertas por antiguedad
Tasa de falsos positivos (supresiones vs total de hallazgos)
Cobertura de escaneo (porcentaje de repos con escaneo de seguridad habilitado)

IAST como Complemento

IAST (Interactive Application Security Testing) combina elementos de SAST y DAST instrumentando la aplicacion en tiempo de ejecucion. Un agente se ejecuta dentro de la aplicacion durante el testing, correlacionando peticiones HTTP con rutas de ejecucion de codigo.

Herramientas IAST como Contrast Security y Datadog Application Security proporcionan:

Tasas de falsos positivos mas bajas que SAST
Contexto a nivel de codigo que DAST no tiene
Feedback en tiempo real durante el testing de QA

Considera IAST como una tercera capa una vez que SAST y DAST esten maduros en tu pipeline.

Estrategia Practica de Despliegue

Desplegar escaneo de seguridad en tu organización requiere fases:

Fase 1: Visibilidad (Semanas 1-4)

Habilitar SAST en CI con allow_failure: true (no bloques)
Generar informes, guardar como artefactos
Encontrar principales categorías de vulnerabilidades
Establecer métricas base

Fase 2: Gating Selectivo (Semanas 5-8)

Bloquear solo hallazgos SAST críticos/altos
Añadir escaneos DAST a staging para apps clave
Crear flujos de supresión y triaje
Formar desarrolladores en interpretar y corregir hallazgos

Fase 3: Integración Completa (Semanas 9-12)

Aplicar gates SAST en todos los repos
Aplicar gates DAST en todas las web apps
Integrar con plataforma de vulnerabilidades
Auto-crear tickets para hallazgos

Fase 4: Mejora Continua (Continuo)

Escribir reglas Semgrep personalizadas
Afinar políticas de ZAP para reducir tiempo
Rastrear MTTR, establecer objetivos
Revisiones trimestrales de falsos positivos

Mayor error: saltar a Fase 3. Empieza con visibilidad, construye confianza, endurece gradualmente. El escaneo debe ayudar, no bloquear.

Seguridad en pipelines CI/CD: enfoque shift-left

Mon, 20 Jun 2022 00:00:00 +0000

¿Qué es la seguridad shift-left?

La seguridad shift-left consiste en adelantar las prácticas de seguridad en el ciclo de vida del desarrollo de software. En lugar de tratar la seguridad como una puerta final antes de producción (o peor, como algo que se piensa después), integras comprobaciones de seguridad directamente en tus pipelines CI/CD. Así las vulnerabilidades se detectan cuando son más baratas de corregir: en tiempo de desarrollo.

El modelo tradicional de “constrúyelo primero, audítalo después” no escala. Las aplicaciones modernas se despliegan docenas de veces al día. Si tu revisión de seguridad es un proceso manual que ocurre una vez al trimestre, estás desplegando código vulnerable la mayoría del tiempo.

Vectores de amenaza en pipelines CI/CD

Antes de securizar tu pipeline, entiende contra qué te estás defendiendo. Los sistemas CI/CD son objetivos de alto valor porque tienen acceso a credenciales de producción, código fuente y artefactos de build.

Los vectores de amenaza comunes incluyen:

Dependencias comprometidas: Un paquete malicioso en tu árbol de dependencias (ataque a la cadena de suministro).
Secretos filtrados: Claves API, tokens o contraseñas commiteados en el código fuente o expuestos en logs de build.
Vulnerabilidades en el código: Inyección SQL, XSS, deserialización insegura y otros problemas del OWASP Top 10 introducidos en el código de la aplicación.
Configuración insegura del pipeline: Acceso excesivamente permisivo en runners, reglas de protección de ramas ausentes o puertas de aprobación faltantes.
Vulnerabilidades en imágenes de contenedor: Imágenes base con CVEs conocidos que se propagan a producción.
Manipulación de artefactos de build: Artefactos no firmados o no verificados que pueden ser reemplazados por un atacante.

Integrando SAST en tu pipeline

Static Application Security Testing (SAST) analiza el código fuente sin ejecutarlo. Detecta vulnerabilidades temprano, antes de que el código siquiera se ejecute.

Herramientas recomendadas

Semgrep: Rápido, flexible, soporta reglas personalizadas. Funciona con muchos lenguajes. Mi principal recomendación para la mayoría de equipos.
Bandit: Específico para Python. Excelente para proyectos Python ya que entiende patrones de seguridad propios de Python.
SonarQube: Alcance más amplio (calidad de código + seguridad). Más pesado de configurar pero útil si quieres un panel unificado.

Ejecutando Semgrep localmente

1
2
3
4
5
6
7
8


# Instalar
pip install semgrep

# Ejecutar con rulesets por defecto
semgrep --config auto .

# Ejecutar con reglas OWASP Top 10 específicamente
semgrep --config "p/owasp-top-ten" .

Ejecutando Bandit para proyectos Python

1
2


pip install bandit
bandit -r ./src -f json -o bandit-report.json

La clave es ejecutar estas herramientas en cada pull request, no solo en la rama principal. Los desarrolladores deberían ver los hallazgos antes de que el código se fusione.

Integrando DAST en tu pipeline

Dynamic Application Security Testing (DAST) prueba la aplicación en ejecución desde el exterior, simulando un atacante. Detecta problemas que SAST no puede — errores de configuración, fallos de autenticación y vulnerabilidades en tiempo de ejecución.

OWASP ZAP

OWASP ZAP es la herramienta DAST de código abierto estándar. Puedes ejecutarla en tu pipeline contra un despliegue de staging:

1
2
3
4
5
6
7


# Descargar la imagen Docker de ZAP
docker pull ghcr.io/zaproxy/zaproxy:stable

# Ejecutar un escaneo baseline contra una URL objetivo
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
 -t https://staging.example.com \
 -r zap-report.html

DAST es típicamente más lento que SAST. Ejecútalo después del despliegue en un entorno de staging en lugar de en cada commit. Una cadencia nocturna o por release funciona bien para la mayoría de equipos.

Escaneo de secretos

Los secretos filtrados son uno de los fallos de seguridad más comunes y dañinos. Una vez que un secreto está en el historial de Git, considéralo comprometido — incluso si lo eliminas en un commit posterior.

Herramientas

gitleaks: Escanea repositorios Git en busca de secretos usando regex y detección basada en entropía.
trufflehog: Busca en el historial de Git cadenas de alta entropía y patrones de secretos conocidos.

Ejecutando gitleaks

1
2
3
4
5
6
7
8


# Instalar
brew install gitleaks # o descargar el binario desde GitHub releases

# Escanear el repo actual
gitleaks detect --source . --report-path gitleaks-report.json

# Escanear en CI (detectar solo nuevas fugas en el PR)
gitleaks detect --source . --log-opts="origin/main..HEAD"

Hook de pre-commit

Bloquea secretos antes de que lleguen al remoto:

1
2
3
4
5
6


# .pre-commit-config.yaml
repos:
 - repo: https://github.com/gitleaks/gitleaks
 rev: v8.16.1
 hooks:
 - id: gitleaks

Escaneo de dependencias

Tu aplicación es tan segura como su dependencia más débil. Los ataques a la cadena de suministro están en aumento y debes escanear tu árbol de dependencias regularmente.

Herramientas

Trivy: Escanea imágenes de contenedor, sistemas de archivos y repos Git en busca de vulnerabilidades. Rápido y completo.
Snyk: Opción comercial con un tier gratuito generoso. Buena experiencia de desarrollador.
OWASP Dependency-Check: Maduro, código abierto, soporta múltiples ecosistemas.

1
2
3
4
5


# Escanear una imagen de contenedor con Trivy
trivy image my-app:latest

# Escanear el sistema de archivos en busca de dependencias vulnerables
trivy fs --severity HIGH,CRITICAL .

Workflow de GitHub Actions con etapas de seguridad

Aquí tienes un workflow práctico de GitHub Actions que integra todas las etapas de seguridad discutidas:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87


name: Secure CI/CD Pipeline

on:
 pull_request:
 branches: [main]
 push:
 branches: [main]

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

 sast:
 name: Static Analysis
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Run Semgrep
 uses: returntocorp/semgrep-action@v1
 with:
 config: >-
 p/security-audit
 p/owasp-top-ten
 - name: Run Bandit (Python)
 run: |
 pip install bandit
 bandit -r ./src -f json -o bandit-report.json || true
 - name: Upload SAST reports
 uses: actions/upload-artifact@v4
 with:
 name: sast-reports
 path: "*.json"

 dependency-scan:
 name: Dependency Scanning
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Run Trivy filesystem scan
 uses: aquasecurity/trivy-action@master
 with:
 scan-type: fs
 severity: HIGH,CRITICAL
 exit-code: 1

 build-and-scan-image:
 name: Build & Scan Image
 needs: [secret-scan, sast, dependency-scan]
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Build Docker image
 run: docker build -t my-app:${{ github.sha }} .
 - name: Scan image with Trivy
 uses: aquasecurity/trivy-action@master
 with:
 image-ref: my-app:${{ github.sha }}
 severity: HIGH,CRITICAL
 exit-code: 1

 deploy-staging:
 name: Deploy to Staging
 needs: [build-and-scan-image]
 runs-on: ubuntu-latest
 environment: staging
 steps:
 - name: Deploy to staging
 run: echo "Deploy to staging environment"

 dast:
 name: Dynamic Analysis
 needs: [deploy-staging]
 runs-on: ubuntu-latest
 steps:
 - name: OWASP ZAP Baseline Scan
 uses: zaproxy/action-baseline@v0.9.0
 with:
 target: "https://staging.example.com"

Observa el orden deliberado: el escaneo de secretos, SAST y escaneo de dependencias se ejecutan en paralelo (feedback rápido). El escaneo de imagen se ejecuta después del build. DAST se ejecuta después del despliegue en staging.

Checklist de buenas prácticas

Aquí tienes una checklist para evaluar la madurez de seguridad de tu pipeline CI/CD:

El escaneo de secretos se ejecuta en cada PR y bloquea el merge ante hallazgos.
Los hooks de pre-commit previenen que se commiteen secretos localmente.
SAST se ejecuta en cada PR con reglas que cubren OWASP Top 10.
El escaneo de dependencias se ejecuta en cada PR y marca CVEs HIGH/CRITICAL.
El escaneo de imágenes de contenedor se ejecuta antes de publicar imágenes en un registry.
DAST se ejecuta contra staging en cada release (o como mínimo cada noche).
La protección de ramas requiere que pasen las comprobaciones de seguridad antes del merge.
El principio de mínimo privilegio se aplica en permisos de CI runners y acceso a secretos.
Los commits firmados y artefactos firmados se exigen para releases de producción.
Los logs de build se revisan para asegurar que no se filtran secretos en la salida.
Se usa pinning de dependencias (versiones exactas, no rangos) para prevenir ataques a la cadena de suministro.
Se realiza rotación regular de todos los secretos de CI/CD y claves de cuentas de servicio.

Reflexiones finales

La seguridad shift-left no se trata de comprar una herramienta, sino de cambiar la cultura. Las comprobaciones de seguridad en CI/CD deben ser rápidas, automatizadas e innegociables. Empieza con el escaneo de secretos (tiene el mayor ROI), añade SAST, y luego incorpora el escaneo de dependencias y DAST.

El objetivo no es detectar todo en el pipeline. Lo importante es elevar el listón lo suficiente para que los problemas obvios nunca lleguen a producción, liberando a tu equipo de seguridad para enfocarse en las amenazas sutiles y de alto impacto que requieren juicio humano.