El setenta por ciento de las vulnerabilidades encontradas en producción podrían haberse detectado durante el desarrollo. Esa única estadística — del análisis de Gartner sobre la postura de seguridad de aplicaciones — es todo el argumento de negocio para el pipeline DevSecOps. Sin embargo, la mayoría de los equipos de ingeniería siguen tratando la seguridad como una puerta al final del proceso de entrega en lugar de integrarla como un hilo a lo largo de cada etapa.
Esta publicación presenta un diagrama concreto del pipeline DevSecOps, recorre cada etapa, nombra las herramientas que vale la pena usar y proporciona un ejemplo de GitHub Actions que puede adaptar directamente.
Cómo se ve realmente un pipeline DevSecOps
En su esencia, un pipeline DevSecOps es un pipeline CI/CD donde las verificaciones de seguridad están automatizadas e integradas en cada fase — no añadidas al final. El diagrama canónico tiene seis etapas: Pre-Commit → Build → Test → Artefacto → Deploy → Monitor. Los controles de seguridad aparecen dentro de cada etapa.
[IDE del Desarrollador] → [Hooks Pre-Commit] → [Control de versiones / Revisión PR]
→ [Build & SAST] → [Escaneo dependencias / SCA] → [Escaneo imagen contenedor]
→ [Verificación policy IaC] → [Deploy Staging] → [DAST / Automatización Pen-test]
→ [Deploy Producción] → [Monitoreo Runtime / CSPM]Cada flecha representa una posible puerta de seguridad. Si una puerta falla — un CVE crítico en una dependencia, un secreto hardcodeado, un recurso Terraform mal configurado — el pipeline se detiene. Esta es la seguridad shift-left en su forma más literal.
Desglose etapa por etapa
Etapa 1: Pre-Commit
Antes de que una sola línea de código llegue al repositorio remoto, la máquina local del desarrollador puede ejecutar verificaciones de seguridad ligeras mediante Git hooks. Herramientas como pre-commit combinado con detect-secrets o gitleaks capturan credenciales hardcodeadas, claves API y certificados privados en milisegundos.
Etapa 2: Build y análisis estático (SAST)
Las herramientas SAST analizan el código fuente sin ejecutarlo, buscando fallos de inyección, deserialización insegura, path traversal y otros problemas del OWASP Top 10. Las capacidades SAST de SECRAILS se integran directamente en la etapa de build, proporcionando hallazgos contextuales mapeados a identificadores CWE. La Secret Detection a nivel de build proporciona una segunda capa de protección.
Etapa 3: Escaneo de dependencias y SCA
El análisis de composición de software es innegociable en 2025. La aplicación empresarial promedio importa 528 dependencias open source. Las puntuaciones EPSS son cada vez más importantes aquí — un CVE con CVSS 9.8 pero EPSS 0.003% es muy diferente operacionalmente de un CVE con CVSS 7.2 y EPSS 42%. Herramientas como Grype, OWASP Dependency-Check y Snyk ofrecen contexto EPSS ahora.
Etapa 4: Escaneo de imágenes de contenedor
Las imágenes de contenedor contienen frecuentemente paquetes OS con CVEs conocidos y secretos integrados en capas. Trivy de Aqua Security es el estándar open source de facto. El Container Image Scanning de SECRAILS cubre vulnerabilidades de imagen base, CVEs a nivel de paquete y configuraciones incorrectas en un único pase.
Etapa 5: Verificaciones de policy en IaC
Terraform, Pulumi, CloudFormation, Helm charts — todo es código y puede escanearse antes de tocar un entorno cloud real. Policy-as-Code se vuelve operacionalmente poderoso aquí. Checkov viene con más de 1.000 políticas integradas para AWS, Azure, GCP y Kubernetes.
Etapa 6: Análisis dinámico (DAST) y Staging
DAST se ejecuta contra una instancia en vivo de la aplicación y puede detectar problemas en tiempo de ejecución que SAST físicamente no puede: bypasses de autenticación, SSRF, race conditions y fallos de lógica de negocio. OWASP ZAP sigue siendo la herramienta DAST open source más utilizada.
Etapa 7: Monitoreo de producción y defensa en runtime
Desplegar de forma segura no es la línea de llegada. CSPM evalúa continuamente la configuración cloud contra CIS Benchmarks y controles NIST CSF 2.0. Falco proporciona detección comportamental en runtime para Kubernetes. Vulnerability Management en runtime significa escanear continuamente la infraestructura en vivo.
Lista de herramientas DevSecOps
Secret Detection: Gitleaks, detect-secrets, TruffleHog v3
SAST: Semgrep, SonarQube Community, Checkmarx, Bandit
SCA: Grype, Trivy, Snyk, OWASP Dependency-Check
Escaneo de contenedores: Trivy, Grype, Clair, Docker Scout
IaC / Policy-as-Code: Checkov, tfsec, KICS, OPA/Conftest
DAST: OWASP ZAP, Nuclei, Burp Suite Enterprise
Runtime / CSPM: Falco, Wiz, Prisma Cloud, SECRAILS CSPM
Errores comunes que cometen los equipos
La fatiga de alertas es real. Un pipeline que genera 300 hallazgos por ejecución será ignorado o desactivado. Calibre sus herramientas. Otro fallo común: escanear solo el código de la aplicación, no la infraestructura que la ejecuta. La capa de Cloud Security no es opcional. Las capacidades de Code Security de SECRAILS están diseñadas para encajar en este modelo de pipeline sin reemplazar toda la cadena de herramientas existente.
Reflexiones finales
Un diagrama de pipeline DevSecOps no es un artefacto burocrático — es una especificación de ingeniería. Cada elemento representa un control de seguridad automatizado que se ejecuta en cada cambio de código. Comience con secretos y SAST. Añada SCA. Luego escaneo de contenedores. Luego verificaciones de IaC. No necesita todo el pipeline el primer día — pero necesita empezar ahora.