Construir un entorno DevSecOps utilizando únicamente herramientas de código abierto es totalmente posible si se diseña una cadena de trabajo ordenada, automatizada y medible. La clave no está en instalar muchas herramientas, sino en integrar seguridad desde el repositorio hasta producción.
DevSecOps significa incorporar seguridad en todo el ciclo de vida del software: planificación, codificación, revisión, construcción, pruebas, despliegue, operación, monitoreo y respuesta. En lugar de revisar la seguridad al final, se busca detectar problemas temprano, reducir riesgos en la cadena de suministro y mantener evidencia continua.
Un entorno DevSecOps maduro debe ayudar a responder preguntas como: ¿el código tiene vulnerabilidades?, ¿hay secretos expuestos?, ¿las dependencias tienen CVE conocidas?, ¿la imagen del contenedor es segura?, ¿el manifiesto Kubernetes cumple políticas?, ¿el artefacto fue firmado?, ¿existe SBOM?, ¿la aplicación tiene pruebas dinámicas?, ¿hay alertas en producción?
Idea clave: DevSecOps no es “poner un escáner en el pipeline”. Es convertir la seguridad en una práctica continua, automatizada, trazable y compartida entre desarrollo, operaciones y seguridad.
Arquitectura de referencia DevSecOps open source
Un entorno DevSecOps completo puede construirse con herramientas libres para cada etapa. La siguiente arquitectura es una referencia práctica para equipos que trabajan con Linux, contenedores, Kubernetes, APIs, aplicaciones web y CI/CD.
| Capa | Herramientas open source | Objetivo |
|---|---|---|
| Repositorio | Git, Gitea, Forgejo, GitLab CE | Control de versiones, revisiones, ramas, historial y trazabilidad. |
| CI/CD | Jenkins, GitLab CI, Woodpecker CI, Tekton | Automatizar pruebas, análisis, construcción, empaquetado y despliegue. |
| SAST | Semgrep, SonarQube Community | Detectar errores de seguridad y calidad en el código fuente. |
| Secretos | Gitleaks, detect-secrets | Evitar credenciales, tokens o llaves expuestas en repositorios. |
| SCA | Trivy, Grype, OWASP Dependency-Check, OSV-Scanner | Analizar dependencias y vulnerabilidades conocidas. |
| Contenedores | Trivy, Grype, Syft, Docker, Podman, Buildah | Escanear imágenes, generar SBOM y construir artefactos seguros. |
| DAST | OWASP ZAP | Probar aplicaciones web o APIs en ejecución de forma autorizada. |
| IaC y políticas | Checkov, Trivy, Open Policy Agent, Conftest, Kyverno, Gatekeeper | Validar infraestructura, Kubernetes y políticas antes del despliegue. |
| Cadena de suministro | Syft, Cosign, Sigstore, SLSA, OpenSSF Scorecard | Generar SBOM, firmar artefactos y evaluar seguridad del proyecto. |
| Runtime y monitoreo | Falco, Wazuh, Prometheus, Grafana, Loki | Detectar eventos en ejecución, observar sistemas y responder. |
Paso 1: definir el modelo de madurez
Antes de instalar herramientas, define el nivel de madurez que necesita tu organización. Un equipo pequeño no requiere el mismo flujo que una empresa con múltiples aplicaciones, Kubernetes, auditorías y despliegues diarios.
Preguntas iniciales
- ¿Qué lenguajes usa el equipo?
- ¿Dónde se aloja el código?
- ¿Hay contenedores o Kubernetes?
- ¿Existen APIs públicas o aplicaciones web?
- ¿Qué dependencias externas se usan?
- ¿Se generan imágenes de contenedor?
- ¿Quién aprueba despliegues a producción?
- ¿Qué hallazgos deben bloquear el pipeline?
Una buena regla es avanzar por etapas: primero secretos y SAST básico; luego SCA, contenedores e IaC; después DAST, SBOM, firma, políticas y monitoreo runtime.
Paso 2: proteger el repositorio desde el inicio
El repositorio es el punto de partida. Si el código fuente, las ramas, las credenciales y los permisos están mal administrados, todo el pipeline queda expuesto.
Controles mínimos en Git
- Ramas protegidas para producción.
- Revisión obligatoria antes de fusionar cambios.
- Firmas de commits cuando sea posible.
- Prohibir secretos en el repositorio.
- Control de permisos por equipo.
- Historial y trazabilidad de cambios.
- Política clara para dependencias y licencias.
Para detección temprana de secretos, puedes usar Gitleaks:
También conviene integrarlo como pre-commit o en CI para impedir que credenciales lleguen a ramas principales.
Paso 3: análisis SAST con Semgrep
El análisis SAST revisa el código fuente sin ejecutar la aplicación. Sirve para detectar patrones inseguros, errores comunes, malas prácticas y vulnerabilidades potenciales.
Semgrep es una herramienta open source muy útil porque soporta muchos lenguajes, puede ejecutarse localmente, integrarse al pipeline y trabajar con reglas comunitarias o personalizadas.
Buenas prácticas SAST
- Ejecutar SAST en cada merge request.
- Configurar reglas por lenguaje y framework.
- No bloquear todo desde el primer día.
- Priorizar hallazgos críticos y explotables.
- Crear reglas internas para errores repetidos.
- Medir reducción de deuda de seguridad.
Paso 4: análisis de dependencias con Trivy, Grype u OWASP Dependency-Check
La mayoría de aplicaciones modernas dependen de bibliotecas externas. DevSecOps debe analizar esas dependencias para detectar vulnerabilidades conocidas, versiones obsoletas, licencias problemáticas o componentes sin mantenimiento.
Con Trivy puedes escanear el repositorio:
Con Grype puedes analizar una imagen o SBOM:
Consejo: no conviertas SCA en una lista infinita de CVE. Prioriza vulnerabilidades críticas, explotables, presentes en rutas reales de ejecución y asociadas a componentes expuestos.
Paso 5: escaneo de contenedores y SBOM
Si usas Docker, Podman o Kubernetes, cada imagen debe analizarse antes de llegar a producción. También conviene generar un SBOM, que es un inventario de componentes del software.
Generar SBOM con Syft:
Escanear imagen con Trivy:
Buenas prácticas en imágenes
- Usar imágenes base mínimas y mantenidas.
- No ejecutar como root dentro del contenedor.
- Eliminar herramientas innecesarias en producción.
- Fijar versiones de dependencias.
- Escanear antes de publicar al registry.
- Generar SBOM por cada release.
- Firmar imágenes antes de desplegar.
Paso 6: firma de artefactos con Cosign y Sigstore
DevSecOps también debe proteger la cadena de suministro. No basta con construir una imagen: necesitas saber de dónde viene, quién la generó y si fue alterada.
Cosign permite firmar imágenes de contenedor y verificar su procedencia:
En una organización madura, el despliegue debería aceptar solo imágenes firmadas, escaneadas y generadas por pipelines autorizados.
Paso 7: análisis DAST con OWASP ZAP
El análisis DAST prueba una aplicación en ejecución. A diferencia de SAST, aquí la herramienta interactúa con la aplicación desplegada en un entorno controlado. Es útil para detectar problemas como cabeceras inseguras, configuraciones débiles, errores visibles o comportamientos web riesgosos.
Ejemplo de baseline scan con OWASP ZAP:
Importante: ejecuta DAST solo contra aplicaciones propias, entornos autorizados o laboratorios. No escanees sistemas de terceros sin permiso explícito.
Paso 8: seguridad de infraestructura como código
Los errores de infraestructura como código pueden crear recursos inseguros: buckets públicos, puertos abiertos, contenedores privilegiados, secretos expuestos o políticas demasiado permisivas.
Escaneo de IaC con Checkov:
Escaneo de IaC con Trivy:
El objetivo es bloquear configuraciones peligrosas antes de que lleguen a producción.
Paso 9: políticas como código en Kubernetes
Si usas Kubernetes, DevSecOps debe validar manifiestos antes y durante el despliegue. Herramientas como Kyverno, OPA Gatekeeper o Conftest ayudan a convertir reglas de seguridad en políticas ejecutables.
Políticas útiles en Kubernetes
- Prohibir contenedores privilegiados.
- Exigir límites de CPU y memoria.
- Bloquear ejecución como root.
- Exigir imágenes firmadas.
- Permitir solo registries autorizados.
- Requerir etiquetas obligatorias.
- Validar namespaces y service accounts.
- Evitar hostPath salvo casos aprobados.
Este enfoque permite que seguridad no sea una recomendación manual, sino una regla aplicada automáticamente en el clúster.
Paso 10: monitoreo runtime con Falco, Wazuh, Prometheus y Grafana
DevSecOps no termina cuando la aplicación llega a producción. También necesitas monitoreo, alertas y respuesta. Aquí aparecen herramientas de observabilidad y seguridad runtime.
| Herramienta | Uso en DevSecOps |
|---|---|
| Falco | Detección runtime de comportamientos sospechosos en hosts, contenedores y Kubernetes. |
| Wazuh | Monitoreo de seguridad, integridad de archivos, vulnerabilidades, eventos y cumplimiento. |
| Prometheus | Métricas de aplicaciones, servidores, contenedores y servicios. |
| Grafana | Dashboards, alertas, correlación visual y análisis operativo. |
| Loki | Centralización de logs con etiquetas y consulta desde Grafana. |
El objetivo es detectar comportamientos anómalos después del despliegue: procesos inesperados, errores 5xx, reinicios, tráfico anormal, cambios en archivos críticos o alertas de contenedores.
Ejemplo de pipeline DevSecOps open source
Este ejemplo conceptual muestra cómo ordenar etapas de seguridad en un pipeline. Puede adaptarse a GitLab CI, Jenkins, Woodpecker, Tekton u otra plataforma.
La idea no es bloquear todo de inmediato, sino construir gates progresivos. Por ejemplo: bloquear secretos siempre, bloquear vulnerabilidades críticas explotables, advertir hallazgos medios y generar tickets para deuda técnica.
Qué hallazgos deben bloquear el despliegue
Uno de los errores más comunes es configurar herramientas sin definir umbrales. Si todo bloquea, el equipo buscará saltarse el pipeline. Si nada bloquea, la seguridad será decorativa.
| Hallazgo | Acción recomendada |
|---|---|
| Secreto expuesto | Bloquear siempre, rotar credencial y limpiar historial si corresponde. |
| CVE crítica explotable en componente expuesto | Bloquear despliegue hasta corregir, mitigar o aprobar excepción formal. |
| Contenedor ejecuta como root | Bloquear en producción o exigir justificación técnica. |
| IaC abre puertos sensibles a Internet | Bloquear salvo aprobación y control compensatorio. |
| Hallazgos medios no explotables | Registrar, priorizar y corregir según SLA. |
Métricas para medir DevSecOps
DevSecOps debe medirse con indicadores útiles. No basta con contar vulnerabilidades. También importa el tiempo de corrección, la cobertura de escaneos, la cantidad de secretos bloqueados y la calidad del pipeline.
Indicadores recomendados
- Porcentaje de repositorios con SAST activo.
- Porcentaje de proyectos con escaneo de dependencias.
- Tiempo medio de corrección de vulnerabilidades críticas.
- Número de secretos bloqueados antes de llegar al repositorio.
- Porcentaje de imágenes con SBOM.
- Porcentaje de imágenes firmadas.
- Vulnerabilidades críticas abiertas por más de 30 días.
- Porcentaje de despliegues con DAST en staging.
- Políticas Kubernetes cumplidas.
- Eventos runtime detectados y atendidos.
Ruta de madurez DevSecOps open source
| Nivel | Estado | Descripción |
|---|---|---|
| 0 | Reactivo | La seguridad se revisa al final o después de incidentes. |
| 1 | Inicial | Escaneo manual, revisión de secretos y controles básicos en Git. |
| 2 | Automatizado | SAST, SCA, secretos y escaneo de contenedores en CI/CD. |
| 3 | Gobernado | Políticas como código, SBOM, firma, DAST, gates y excepciones controladas. |
| 4 | Continuo | Monitoreo runtime, respuesta automatizada, métricas, mejora continua y seguridad integrada al producto. |
Errores comunes al implementar DevSecOps
Evita estos errores
- Instalar herramientas sin política de uso.
- Bloquear el pipeline por hallazgos sin priorizar.
- No definir responsables de remediación.
- Ignorar secretos expuestos en historial Git.
- Escanear imágenes pero no firmarlas.
- Generar SBOM y nunca usarlo.
- Permitir excepciones sin fecha de vencimiento.
- No revisar permisos del CI/CD.
- No monitorear producción.
- Creer que DevSecOps reemplaza la revisión humana.
Checklist de implementación
Acciones recomendadas
- Proteger ramas principales.
- Activar revisión obligatoria de código.
- Ejecutar Gitleaks en cada pipeline.
- Integrar Semgrep para SAST.
- Escanear dependencias con Trivy, Grype u OWASP Dependency-Check.
- Construir imágenes con usuarios no root.
- Escanear imágenes antes de publicar.
- Generar SBOM con Syft.
- Firmar imágenes con Cosign.
- Ejecutar OWASP ZAP en staging.
- Validar IaC con Checkov o Trivy.
- Aplicar políticas Kubernetes con Kyverno o Gatekeeper.
- Monitorear runtime con Falco, Wazuh, Prometheus y Grafana.
- Definir umbrales de bloqueo y proceso de excepción.
- Medir tiempos de remediación y cobertura de seguridad.
Preguntas clave
¿Se puede hacer DevSecOps solo con herramientas open source?
Sí. Es posible construir un flujo completo con Git, Jenkins, Gitea, Semgrep, Trivy, Grype, OWASP ZAP, Gitleaks, Syft, Cosign, Kyverno, OPA, Falco, Wazuh, Prometheus y Grafana. El reto principal no es la herramienta, sino la integración y el gobierno.
¿Qué herramienta debo instalar primero?
Empieza por control de repositorio, revisión de código y escaneo de secretos. Luego agrega SAST, SCA y escaneo de contenedores. Después suma DAST, SBOM, firma y políticas.
¿SAST reemplaza una revisión de código?
No. SAST ayuda a detectar patrones inseguros, pero la revisión humana sigue siendo necesaria para lógica de negocio, arquitectura, permisos, abuso de funciones y decisiones de diseño.
¿DAST debe ejecutarse en producción?
Lo recomendable es ejecutarlo primero en staging o entornos autorizados. En producción debe hacerse con mucho control, alcance limitado y autorización formal.
¿Qué es SBOM y por qué importa?
SBOM es un inventario de componentes de software. Ayuda a conocer qué librerías, paquetes y dependencias forman parte de una aplicación o imagen, facilitando gestión de vulnerabilidades y trazabilidad.
¿DevSecOps debe bloquear despliegues?
Sí, pero con criterios claros. Debe bloquear secretos, vulnerabilidades críticas explotables, configuraciones peligrosas y artefactos no autorizados. Hallazgos menores pueden gestionarse con tickets y SLA.
¿Cómo evitar falsos positivos?
Define reglas, revisa hallazgos, documenta excepciones, ajusta severidades, crea listas de aceptación temporales y mide la calidad del escaneo. Una excepción nunca debe ser permanente sin revisión.
Recomendamos
En resumen
Construir un entorno DevSecOps únicamente con herramientas de código abierto es viable, potente y flexible. El ecosistema actual permite cubrir repositorio, CI/CD, SAST, SCA, secretos, contenedores, DAST, IaC, SBOM, firma, políticas Kubernetes, monitoreo y runtime security.
El mayor valor aparece cuando las herramientas trabajan juntas: Gitleaks evita secretos, Semgrep revisa código, Trivy y Grype analizan dependencias e imágenes, Syft genera SBOM, Cosign firma artefactos, OWASP ZAP prueba aplicaciones, Kyverno u OPA aplican políticas, y Falco, Wazuh, Prometheus y Grafana observan producción.
DevSecOps no debe verse como una barrera para los desarrolladores, sino como una forma de entregar software más confiable, auditable y seguro sin perder velocidad.
Conclusión editorial
El futuro del desarrollo seguro no depende necesariamente de plataformas cerradas. Con Linux, software libre y una arquitectura bien integrada, cualquier equipo puede construir una fábrica de software DevSecOps moderna, trazable y preparada para los riesgos actuales.
