Semgrep 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.