Parte: 11 — DevSecOps y seguridad del SDLC · Fuente: Securing DevOps (Julien Vehent) y NIST SP 800-40r4 (Guide to Enterprise Patch Management) ⏱️ Duración estimada: 110 min · Nivel: Avanzado
Pasar de "escanear y encontrar vulnerabilidades" a operar un programa de gestión de vulnerabilidades: consolidar hallazgos de muchas herramientas, deduplicarlos, priorizarlos por riesgo real, asignarlos con SLA, seguir su remediación y medir el programa con métricas. Cuando tienes cientos de repos y miles de hallazgos, sin un proceso te ahogas; con proceso, reduces el riesgo de forma medible.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Ciclo de vida de la vulnerabilidad | El proceso, no solo el escaneo |
| 2 | Consolidación y deduplicación | Muchas herramientas, un backlog |
| 3 | Priorización basada en riesgo | No todo lo crítico es urgente |
| 4 | SLAs por severidad | Compromisos medibles de remediación |
| 5 | VEX y excepciones | Documentar lo no explotable |
| 6 | Métricas del programa | MTTR, backlog, tasa de recurrencia |
| 7 | Herramientas de agregación | DefectDojo y similares |
Un escaneo produce observaciones; un programa produce resultados. Para ello necesita inventario, propietario, deduplicación, validación, priorización, tratamiento, verificación y aprendizaje. Sin inventario no se conoce la exposición; sin propietario el ticket envejece; sin verificación, «cerrado» puede significar que alguien cambió un estado.
La deduplicación no debe borrar contexto: un mismo CVE en una estación aislada y en una API pública comparte identificador, pero no exposición ni propietario. Se conserva la instancia por activo y se agrupa para coordinar una solución. La fuente, fecha, evidencia y versión de herramienta permiten explicar por qué un hallazgo apareció o desapareció.
CVSS describe severidad técnica bajo supuestos; KEV aporta evidencia de explotación conocida; EPSS estima probabilidad de explotación; el negocio aporta criticidad, exposición, privilegio y controles. Una fórmula puede ordenar, pero debe ser transparente y revisable. «Crítico = 24 horas» sin capacidad de emergencia ni pruebas puede fomentar cierres falsos. El SLA empieza cuando el hallazgo es accionable y contempla rutas de excepción, escalamiento y verificación.
El tratamiento no siempre es «parchear». Puede actualizar, retirar, reconfigurar, aislar, deshabilitar una función o aceptar temporalmente con aprobación. La aceptación registra el riesgo residual, controles compensatorios y vencimiento. VEX sirve para comunicar estados de afectación de un producto, no para declarar «no afectado» sin análisis.
Contar vulnerabilidades abiertas puede subir cuando mejora la cobertura. Son más útiles la edad por riesgo, tiempo hasta triage y remediación, porcentaje de activos con propietario, reaperturas, excepciones vencidas y recurrencia de causas. Una mediana sola oculta la cola; se observan percentiles y casos fuera del SLA. Las métricas deben provocar decisiones, no rankings de equipos que incentiven ocultar resultados.
Tras integrar escáneres, DefectDojo recibe mil hallazgos críticos duplicados. El equipo normaliza identificadores, conserva instancias por activo y separa imágenes no desplegadas. Cruza exposición y KEV, valida una ruta pública explotable y asigna un dueño. Los hallazgos heredados entran en campañas por componente; los nuevos rompen la línea base según política. El valor no provino de cerrar mil tickets, sino de convertir datos en una cola defendible.
| Término | Definición útil |
|---|---|
| Instancia | Aparición concreta de una vulnerabilidad en un activo o artefacto. |
| SLA | Compromiso temporal condicionado por riesgo y proceso definido. |
| Riesgo residual | Riesgo que permanece después del tratamiento. |
| Control compensatorio | Medida alternativa que reduce riesgo sin eliminar la causa. |
| Reapertura | Evidencia de que la corrección no eliminó o reintrodujo el problema. |
El alumno domina el programa cuando puede convertir hallazgos heterogéneos en instancias trazables, ordenar con contexto, asignar tratamiento y vencimiento, verificar el cierre y elegir métricas que distingan cobertura, velocidad y riesgo residual.
# DefectDojo de práctica con Docker Compose:
git clone https://github.com/DefectDojo/django-DefectDojo
cd django-DefectDojo && docker compose up -d
🧪 Laboratorio ejecutable del programa:
devsecops-pipeline— incluye el bloque de priorización KEV → EPSS → CVSS y el procedimiento de remediación con reversión automática.
Ejercicio de proceso (defensivo, sobre hallazgos propios):
Nota ética: la gestión de vulnerabilidades es puramente defensiva. Los datos de hallazgos son sensibles; trátalos con control de acceso y no los publiques.
Opera un mini-programa de gestión de vulnerabilidades sobre hallazgos reales de tus prácticas.
Criterio de aceptación: (a) los hallazgos de al menos tres herramientas están consolidados y deduplicados; (b) existe un modelo de priorización documentado que va más allá de CVSS (incluye EPSS/KEV/exposición); (c) hay SLAs por severidad y cada hallazgo top tiene dueño y plazo; (d) al menos una excepción está documentada como VEX; y (e) se reporta MTTR y backlog por severidad.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| Backlog de 10.000 hallazgos sin tocar | Priorizas por CVSS crudo. Filtra por explotabilidad y exposición; ataca lo alcanzable primero. |
| El mismo bug aparece 30 veces | No hay deduplicación. Usa una plataforma (DefectDojo) que fusione hallazgos equivalentes. |
| Los equipos ignoran los tickets | Sin SLA ni dueño claro. Asigna responsable y plazo, y escala incumplimientos. |
| Se remedia pero reaparece | No se corrigió la causa raíz (dependencia base). Mide tasa de recurrencia y ataca el origen. |
| Métricas que nadie usa | Reportas número de CVE sin contexto. Mide MTTR, backlog por riesgo y tendencia. |
❓ ¿Por qué no arreglar simplemente todo lo "crítico"? Porque "crítico" en CVSS no significa "explotable en tu contexto". Un crítico sin exploit y sin exposición puede esperar frente a un alto que está en KEV y es internet-facing.
❓ ¿Qué SLAs son razonables? Depende del riesgo y del sector, pero un patrón común: crítico explotable en días, alto en semanas, medio en meses. Lo importante es que sean explícitos y medibles.
❓ ¿Necesito DefectDojo o basta con Jira? Para pocos repos, un tracker con buena disciplina sirve. A escala, una plataforma que importe múltiples formatos, deduplique y calcule métricas ahorra muchísimo esfuerzo.
❓ ¿Qué es y para qué sirve VEX? Es una forma estandarizada de decir "este CVE está presente pero no somos explotables porque...". Reduce el ruido y evita remediar lo que no aplica, con trazabilidad.
Clase 244 — Políticas como código con OPA