Plantilla de Gestion de Vulnerabilidades
Plantilla repetible para rastrear vulnerabilidades, asignar responsables de remediacion, definir plazos de parches y reportar riesgos de seguridad a los stakeholders.
Nota para desarrolladores hispanohablantes: Esta guía incluye ejemplos y convenciones de nomenclatura adaptadas a equipos que trabajan en español. Cuando existen diferencias significativas en terminología técnica entre el inglés y el español, se indican explícitamente para facilitar la comunicación en equipos multiculturales.
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
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 CIExplicacion
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.
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 |
Mejores Practicas
- Escanear temprano y frecuentemente. Integrar escaneo de dependencias y contenedores en CI/CD para detectar vulnerabilidades antes del despliegue.
- Priorizar por explotabilidad, no solo por CVSS. Un CVE medio con exploit publico es mas urgente que un alto que requiera acceso local.
- Asignar un unico responsable por CVE. La responsabilidad compartida se convierte en responsabilidad ausente.
- Automatizar donde sea posible. Usar herramientas como Dependabot, Snyk o Trivy para crear tickets y PRs automaticamente.
- Reportar semanalmente al liderazgo. La visibilidad impulsa la priorizacion y asignacion de recursos.
Errores Comunes
- 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.
- No rastrear excepciones. “Lo parchearemos despues” sin fecha se convierte en “lo olvidamos.”
- Parchear sin probar. Los parches de emergencia desplegados directo a produccion pueden causar caidas peores que la vulnerabilidad.
- Ignorar dependencias transitivas. La libreria vulnerable puede estar tres niveles de profundidad en tu arbol de dependencias.
- No verificar despues del parche. Siempre reescanear para confirmar que el arreglo resolvio el CVE.
Preguntas Frecuentes
¿Como manejo un CVE sin parche disponible?
Documentar la excepcion, implementar controles compensatorios (reglas WAF, restricciones de acceso, monitoreo), y suscribirse a avisos de seguridad del vendor para la fecha de lanzamiento del parche. Reevaluar el riesgo semanalmente.
¿Deberia parchear vulnerabilidades de severidad baja?
Si, dentro del SLA definido. Los atacantes a menudo encadenan vulnerabilidades de baja severidad para lograr un exploit de alto impacto. Los items de baja severidad tambien son una senal de higiene de mantenimiento.
¿Que herramientas se integran bien con esta plantilla?
- Escaneres: Trivy, Snyk, Nessus, Qualys, OWASP DC
- Tickets: Jira, GitHub Issues, Linear
- Reportes: Grafana, Tableau, Google Sheets
- SOAR: Splunk SOAR, Palo Alto XSOAR para respuesta automatica
¿Como comunico plazos de parcheo a stakeholders no tecnicos?
Traducir severidad a riesgo de negocio: “Esta vulnerabilidad critica podria permitir acceso no autorizado a datos de clientes en 48 horas si se explota. La estamos parcheando en 24 horas.” Usar la tabla de evaluacion de riesgos para justificar los plazos.