Plantilla de Gestión de Vulnerabilidades

Resumen

Las vulnerabilidades sin parchear siguen siendo una de las causas más comunes de las brechas — no porque los equipos no escaneen, sino porque los hallazgos se acumulan sin responsables, plazos ni seguimiento. Esta plantilla te da un flujo de trabajo repetible: cada CVE queda rastreado, puntuado, asignado a un único responsable y cerrado dentro de un SLA antes de que caiga en el terreno del “ya lo parchearemos”.

Úsala junto a la plantilla de triaje de vulnerabilidades de dependencias para el análisis de cada CVE y la plantilla de gestión de parches para programar el despliegue en sí. Para los hallazgos que salen de una prueba de penetración, la plantilla de pentest mantiene la trazabilidad de la evaluación a la resolución.

Cuándo Usarla

• Se divulga un nuevo CVE que afecta a tu stack tecnológico
• Ejecutas escaneos automáticos de vulnerabilidades (contenedores, dependencias, infraestructura)
• Te preparas para una auditoría de seguridad o revisión de cumplimiento
• Necesitas reportar el estado de seguridad a liderazgo o clientes
• Quieres definir SLAs de parcheo por severidad

Solución

# Rastreador de Gestión de Vulnerabilidades

## 1. Inventario de Vulnerabilidades

| CVE ID | Componente | Versión | Severidad | CVSS | Descubierto | Fuente |
|--------|------------|---------|-----------|------|-------------|--------|
| CVE-2026-XXXX | log4j-core | 2.14.1 | Crítica | 9.8 | 2026-01-15 | Dependabot |
| CVE-2026-YYYY | openssl | 1.1.1n | Alta | 7.5 | 2026-02-03 | Trivy |
| CVE-2026-ZZZZ | nginx | 1.18.0 | Media | 5.3 | 2026-02-10 | Nessus |

## 2. Evaluación de Riesgos

| CVE ID | Explotabilidad | KEV/EPSS | Sistemas Afectados | Datos en Riesgo | Impacto de Negocio | Puntaje de Riesgo |
|--------|----------------|----------|--------------------|-----------------|--------------------|--------------------|
| CVE-2026-XXXX | Exploit público disponible | En CISA KEV | Cluster API, workers | PII, tokens de auth | Caída de servicio, filtración | Crítico |
| CVE-2026-YYYY | Prueba de concepto | EPSS 34% | Proxies de edge | Secretos de config | Movimiento lateral | Alto |

## 3. Plan de Remediación

| CVE ID | Responsable | Estrategia de Corrección | Fecha Objetivo | Estado | Verificación |
|--------|-------------|--------------------------|----------------|--------|--------------|
| CVE-2026-XXXX | @security-team | Actualizar a 2.17.1 | 2026-01-17 | Completo | Reescaneo limpio |
| CVE-2026-YYYY | @devops-team | Parchear y redesplegar | 2026-02-10 | En progreso | Esperando ventana de deploy |

### Estrategias de Corrección

- **Actualizar:** Subir a versión parcheada (preferida)
- **Parche:** Aplicar hotfix del vendor
- **Regla WAF:** Bloquear vector de explotación en el edge
- **Cambio de config:** Deshabilitar funcionalidad vulnerable
- **Control compensatorio:** Monitorización + alertas si el parche no es factible

## 4. SLA de Parches

| Severidad | Rango CVSS | SLA (días) | Escalamiento |
|-----------|------------|------------|--------------|
| Crítica | 9.0 - 10.0 | 24 - 48 horas | CISO + VP de Ingeniería |
| Alta | 7.0 - 8.9 | 7 días | Líder de Seguridad + Manager de Equipo |
| Media | 4.0 - 6.9 | 30 días | Gerente de Ingeniería |
| Baja | 0.1 - 3.9 | 90 días | Tech Lead |

## 5. Proceso de Excepciones

Cuando un parche no puede aplicarse dentro del SLA:

| CVE ID | Razón de Excepción | Control Compensatorio | Aprobado Por | Fecha de Revisión |
|--------|--------------------|-----------------------|--------------|-------------------|
| CVE-2026-ZZZZ | Dependencia legacy, cambio breaking | Regla WAF + monitorización de anomalías | CISO | 2026-04-01 |

## 6. Métricas del Programa (Mensual)

| Métrica | Valor | Objetivo | Tendencia |
|---------|-------|----------|-----------|
| CVEs abiertos por severidad | 12 C / 34 A / 89 M / 45 B | — | ↑ M |
| % de CVEs resueltos dentro del SLA | 82% | ≥90% | ↑ |
| Tiempo medio de remediación (Críticos) | 1,8 días | <2 días | → |
| CVEs vencidos | 1 | 0 | ↓ |
| Nuevos vs cerrados este mes | 31 nuevos / 35 cerrados | cerrados ≥ nuevos | ↑ |

## 7. Reporte Semanal de Seguridad

### Resumen Ejecutivo

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

### Acciones Pendientes

1. [ ] Completar actualización 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 automático de Trivy en todos los pipelines de CI

Explicación

La plantilla mantiene inventario, evaluación de riesgos, remediación y reporte como secciones separadas a propósito: los equipos que saltan directo al parcheo tienden a arreglar primero las cosas equivocadas. La tabla de SLA es la capa de responsabilidad: cada severidad tiene una fecha límite dura y una ruta de escalamiento con nombre, así que “un crítico abierto un mes” deja de ser posible.

Dos campos de puntuación merecen atención más allá del CVSS. Si un CVE está en el catálogo de Vulnerabilidades Conocidamente Explotadas de CISA, trátalo como crítico sin importar su puntuación: alguien ya lo está usando. EPSS te da la probabilidad de explotación en los próximos 30 días, que gana a la severidad cruda para ordenar el trabajo cuando el backlog es grande. En la práctica: un EPSS por encima de ~0,5 significa “probable explotación cercana” y por encima de ~0,1 merece atención en activos expuestos a internet. Membresía en KEV más EPSS alto más servicio público es tu cola de prioridad real; todo lo demás se agenda alrededor.

El proceso de excepciones no es una laguna: es la documentación que mantiene visible un sistema sin parchear. Una excepción documentada con controles compensatorios y fecha de revisión siempre gana a una vulnerabilidad sin parchear no documentada. Además funciona como evidencia de auditoría: los revisores de SOC 2 e ISO 27001 piden exactamente este registro — la aceptación del riesgo, el control compensatorio, el aprobador y la fecha de vencimiento.

Del Triaje a la Remediación

La mayoría de los CVEs no mueren en el escáner: mueren en el traspaso entre el equipo de seguridad que los tria y el equipo de ingeniería que los parchea. El tracker solo funciona si el ticket que cruza esa frontera va completo: componente y versión afectados, si el servicio está expuesto a internet, la estrategia de corrección y una fecha objetivo ligada al SLA. Cualquier cosa que falte se convierte en negociación, y las negociaciones no parchean sistemas.

Las correcciones críticas no deberían esperar al próximo sprint, pero tampoco deberían saltarse staging: así es como una actualización precipitada de OpenSSL tira abajo los proxies de edge que debía proteger. El patrón que funciona: seguridad decide la severidad y el plazo, ingeniería decide la corrección y la ventana de deploy, y el tracker es donde ambos lados ven el mismo reloj.

Métricas Que Impulsan el Programa

La salud de un programa de vulnerabilidades se ve en dos cifras: el porcentaje de CVEs resueltos dentro del SLA y el tiempo medio de remediación de críticos. Si el porcentaje de SLA cae por debajo del ~80%, no tienes un problema de escaneo: tienes un problema de capacidad — o entra demasiado volumen para el equipo, o el trabajo de remediación no se está programando. La solución es proceso, no más escaneos.

El conteo de vencidos es la cifra que el liderazgo debería ver cada mes. Cero es el objetivo, y cualquier cosa por encima necesita un responsable con nombre y una revisión de excepción, no una viñeta en un reporte que nadie lee.

Reporta en tres cadencias. Semanal es operativa: qué abrió, qué cerró, qué está fuera de SLA. Mensual es programática: la tabla de métricas — abiertos por severidad, porcentaje de SLA, MTTR de críticos, vencidos y la tendencia. Trimestral es de gobernanza: revisión de excepciones y recalibración del SLA contra la capacidad real. Mismos datos, tres audiencias, tres formatos: el tracker alimenta las tres.

Pipeline de Gestión de Vulnerabilidades

Cada etapa tiene un criterio de salida definido: el descubrimiento termina con el CVE en el tracker, la evaluación termina con un responsable asignado, la planificación termina con una fecha y un SLA, la remediación termina con un deploy, y la verificación termina con un reescaneo limpio. Todo lo que falla la verificación vuelve a planificación con un SLA nuevo: no se queda flotando en silencio.

Variantes

Contexto	Enfoque	Notas
Startup	Hoja de cálculo + escaneos manuales	Enfocarse solo en CVE críticos y altos
Mediana	Jira + integración con escáner automático	Rastrear cumplimiento de SLA semanalmente
Empresa	Plataforma de gestión de vulns (Rapid7, Tenable)	Ciclo de vida completo con RBAC y auditoría
Entorno de contenedores/K8s	Escaneo de imágenes en build + runtime (Trivy, Falco)	Mapear imagen-a-CVE por despliegue

Lo Que Funciona

1. Escanea temprano y frecuentemente. Integra el escaneo de dependencias y contenedores en CI/CD para detectar vulnerabilidades antes del despliegue.
2. Prioriza por explotabilidad, no solo por CVSS. Revisa primero el CISA KEV: un CVE medio con exploit público gana a uno alto que requiere acceso local.
3. Asigna un único responsable por CVE. La responsabilidad compartida se convierte en responsabilidad ausente.
4. Automatiza donde sea posible. Dependabot, Snyk y Trivy pueden crear tickets y PRs automáticamente para los problemas parcheables.
5. Descarta los falsos positivos deliberadamente. Distingue vulnerabilidades alcanzables de las teóricas: un escáner que grita lobo acaba ignorado.
6. Reporta semanalmente al liderazgo. La visibilidad impulsa la priorización y la asignación de recursos.

Errores Comunes

1. Confiar solo en CVSS para priorizar. Un CVSS 7,5 en una herramienta interna de administración es menos urgente que un 6,5 en una API pública.
2. No rastrear excepciones. “Lo parchearemos después” sin fecha se convierte en “lo olvidamos”.
3. Parchear sin probar. Los parches de emergencia desplegados directo a producción causan caídas peores que la vulnerabilidad.
4. Ignorar dependencias transitivas. La librería vulnerable puede estar tres niveles de profundidad en tu árbol de dependencias.
5. No verificar después del parche. Reescanea siempre para confirmar que el arreglo realmente resolvió el CVE.

Ver También

• Repositorio companion: el rastreador rellenable y el ejemplo completado como archivos markdown independientes.
• CISA Known Exploited Vulnerabilities Catalog: la lista autorizada de CVEs bajo explotación activa — revísala antes de priorizar.
• NIST National Vulnerability Database: datos canónicos de CVEs con puntuaciones CVSS y referencias.
• FIRST EPSS: sistema de puntuación de predicción de explotación para estimar la probabilidad de exploit en los próximos 30 días.
• NIST SP 800-40r4: guía de referencia para procesos empresariales de gestión de parches y vulnerabilidades.
• Plantilla de Checklist de Auditoría de Seguridad: el complemento de revisión periódica de este rastreador diario.
• Guía Completa de Seguridad de la Cadena de Suministro: SBOMs y escaneo de dependencias — de donde salen la mayoría de los CVEs que priorizarás aquí.