Plantilla de Gestion de Vulnerabilidades

Resumen

Las vulnerabilidades sin parchear son una de las causas mas comunes de brechas de seguridad. Un proceso estructurado de gestion de vulnerabilidades asegura que cada CVE sea rastreado, priorizado, asignado y resuelto dentro de un plazo definido. Esta plantilla proporciona un flujo de trabajo repetible para equipos de seguridad, ingenieros DevOps y gerentes de ingenieria.

Cuando Usar

• For alternatives, see CI/CD Security: Harden Your Pipelines and Prevent Supply.

Usa este recurso cuando:

• Se divulgue un nuevo CVE que afecte tu stack tecnologico
• Ejecutes escaneos automaticos de vulnerabilidades (contenedores, dependencias, infraestructura)
• Te prepares para una auditoria de seguridad o revision de cumplimiento
• Reportes el estado de seguridad a liderazgo o clientes
• Definas SLAs para parches basados en severidad

Solucion

# Rastreador de Gestion de Vulnerabilidades

## 1. Inventario de Vulnerabilidades

| CVE ID | Componente | Version | Severidad | CVSS | Descubierto | Fuente |
|--------|------------|---------|-----------|------|-------------|--------|
| CVE-2024-XXXX | log4j-core | 2.14.1 | Critica | 9.8 | 2024-01-15 | Dependabot |
| CVE-2024-YYYY | openssl | 1.1.1n | Alta | 7.5 | 2024-02-03 | Trivy |
| CVE-2024-ZZZZ | nginx | 1.18.0 | Media | 5.3 | 2024-02-10 | Nessus |

## 2. Evaluacion de Riesgos

| CVE ID | Explotabilidad | Sistemas Afectados | Datos en Riesgo | Impacto de Negocio | Puntaje de Riesgo |
|--------|----------------|--------------------|-----------------|--------------------|--------------------|
| CVE-2024-XXXX | Exploit publico disponible | Cluster API, workers | PII, tokens de auth | Caida de servicio, filtracion | Critico |
| CVE-2024-YYYY | Prueba de concepto | Proxies de edge | Secretos de config | Movimiento lateral | Alto |

## 3. Plan de Remediacion

| CVE ID | Responsable | Estrategia de Correccion | Fecha Objetivo | Estado | Verificacion |
|--------|-------------|--------------------------|----------------|--------|--------------|
| CVE-2024-XXXX | @security-team | Actualizar a 2.17.1 | 2024-01-17 | Completo | Reescaneo limpio |
| CVE-2024-YYYY | @devops-team | Parchear y redeployar | 2024-02-10 | En progreso | Esperando ventana de deploy |

### Estrategias de Correccion
- **Actualizar:** Subir a version parcheada (preferida)
- **Parche:** Aplicar hotfix del vendor
- **Regla WAF:** Bloquear vector de explotacion en el edge
- **Cambio de config:** Deshabilitar funcionalidad vulnerable
- **Control compensatorio:** Monitoreo + alertas si el parche no es factible

## 4. SLA de Parches

| Severidad | Rango CVSS | SLA (dias) | Escalamiento |
|-----------|------------|------------|--------------|
| Critica | 9.0 - 10.0 | 24 - 48 horas | CISO + VP de Ingenieria |
| Alta | 7.0 - 8.9 | 7 dias | Lider de Seguridad + Manager de Equipo |
| Media | 4.0 - 6.9 | 30 dias | Gerente de Ingenieria |
| Baja | 0.1 - 3.9 | 90 dias | Tech Lead |

## 5. Proceso de Excepciones

Cuando un parche no puede aplicarse dentro del SLA:

| CVE ID | Razon de Excepcion | Control Compensatorio | Aprobado Por | Fecha de Revision |
|--------|--------------------|------------------------|--------------|-------------------|
| CVE-2024-ZZZZ | Dependencia legacy, cambio breaking | Regla WAF + monitoreo de anomalias | CISO | 2024-04-01 |

## 6. Reporte Semanal de Seguridad

### Resumen Ejecutivo
- **Nuevas vulnerabilidades esta semana:** 3
- **Resueltas esta semana:** 2
- **Fuera de SLA:** 1 (CVE-2024-YYYY — esperando ventana de deploy)
- **Tendencia de riesgo:** Mejorando

### Acciones Pendientes
1. [ ] Completar actualizacion de OpenSSL en proxies de edge para el 10 de febrero
2. [ ] Revisar plan de reemplazo de dependencia legacy con el equipo de arquitectura
3. [ ] Habilitar escaneo automatico de Trivy en todos los pipelines de CI

Explicacion

La plantilla separa inventario, evaluacion de riesgos, remediacion y reporte en secciones distintas. Esto evita que los equipos salten directo al parcheo sin entender que sistemas se ven afectados y que datos estan en riesgo. La tabla de SLA crea responsabilidad definiendo exactamente cuanto tiempo puede permanecer abierta cada severidad antes del escalamiento.

El proceso de excepciones es critico para sistemas legacy donde los parches no son inmediatamente factibles. Una excepcion documentada con controles compensatorios siempre es preferible a una vulnerabilidad sin parchear no documentada.

Pipeline de Gestion de Vulnerabilidades

=== Flujo de Vida de CVE ===

1. DESCUBRIMIENTO
   - Escaner automatico detecta CVE en dependencia o contenedor
   - Escaneo manual o reporte de researcher detecta vulnerabilidad
   - CVE importado al tracker de vulnerabilidades automaticamente

2. EVALUACION
   - Security team valida el CVE (reproduce si es posible)
   - Severidad asignada: Critico / Alto / Medio / Bajo
   - Exploitabilidad evaluada: hay exploit publico? hay PoC?
   - Impacto de negocio evaluado: que datos? que servicios?
   - Owner asignado: equipo o ingeniero responsable

3. PLANIFICACION
   - SLA asignado segun severidad (ver tabla de SLA)
   - Excepcion documentada si no hay parche disponible
   - Controles compensatorios identificados si parcheo no es inmediato
   - Prioridad ajustada segun contexto de negocio

4. REMEDIACION
   - Parche aplicado en rama de feature
   - Tests ejecutados para verificar que el parche no rompe funcionalidad
   - Parche desplegado a staging para validacion
   - Parche desplegado a produccion

5. VERIFICACION
   - Reescaneo confirma que el CVE esta resuelto
   - Evidencia capturada: output del escaner, logs de deploy
   - CVE cerrado solo despues de verificacion exitosa
   - Si verificacion falla, CVE reabre con nuevo SLA

Variantes

Contexto	Enfoque	Notas
Startup	Hoja de calculo + escaneos manuales	Enfocarse solo en CVE criticos y altos
Mediana	Jira + integracion con escaner automatico	Rastrear cumplimiento de SLA semanalmente
Empresa	Plataforma de gestion de vulns (Rapid7, Tenable)	Ciclo de vida completo con RBAC y auditoria

Lo que funciona

1. Escanear temprano y frecuentemente. Integrar escaneo de dependencias y contenedores en CI/CD para detectar vulnerabilidades antes del despliegue.
2. Priorizar por explotabilidad, no solo por CVSS. Un CVE medio con exploit publico es mas urgente que un alto que requiera acceso local.
3. Asignar un unico responsable por CVE. La responsabilidad compartida se convierte en responsabilidad ausente.
4. Automatizar donde sea posible. Usar herramientas como Dependabot, Snyk o Trivy para crear tickets y PRs automaticamente.
5. Reportar semanalmente al liderazgo. La visibilidad impulsa la priorizacion y asignacion de recursos.

Errores Comunes

1. Confiar solo en CVSS para priorizar. Un CVSS 7.5 en una herramienta interna de admin es menos urgente que un 6.5 en una API publica.
2. No rastrear excepciones. “Lo parchearemos despues” sin fecha se convierte en “lo olvidamos.”
3. Parchear sin probar. Los parches de emergencia desplegados directo a produccion pueden causar caidas peores que la vulnerabilidad.
4. Ignorar dependencias transitivas. La libreria vulnerable puede estar tres niveles de profundidad en tu arbol de dependencias.
5. No verificar despues del parche. Siempre reescanear para confirmar que el arreglo resolvio el CVE.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica plantilla de gestion de vulnerabilidades cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Troubleshooting

• Authentication bypass in tests: ensure test users cannot reach production endpoints.
• False positives in scanning tools: tune rules against the risk profile. Distinguish between reachable vulnerabilities and theoretical issues.
• Secrets appear in logs: Audit log sinks for sensitive patterns.
• CSP breaks legitimate functionality: Iterate on allowed sources based on real violations.
• Incident response stalls: run tabletop exercises.

Errores Comunes en Producción

• Dejar campos requeridos vacíos o usar respuestas vagas de una palabra.
• Llenar el documento una vez y nunca actualizarlo cuando cambia el alcance o las decisiones.
• Guardar el documento donde el equipo no lo busque durante incidentes o revisiones.
• No asignar un responsable, fecha límite o cadencia de revisión.
• Copiar texto base sin eliminar secciones que no aplican.
• Saltar el control de versiones, lo que impide rollback y responsabilidad.
• No vincular el documento con decisiones relacionadas o acciones de seguimiento.
• Evitar revisiones trimestrales que retirarían secciones obsoletas o sin uso.