Vulnerabilidad en pocas palabras

¿Qué es una vulnerabilidad?

Una Vulnerabilidad es una brecha concreta y técnicamente explotable: un desbordamiento de memoria intermedia, una deserialización insegura o una dependencia atacable en una biblioteca de software. Esta página se ocupa de la vertiente técnica: cómo se identifica una brecha, cómo se evalúa y cómo se corrige a lo largo de su ciclo de vida. La visión superior y organizativa —proceso, responsabilidad y prueba para la auditoría— la explica la página Gestión de vulnerabilidades. Las brechas conocidas reciben un identificador CVE único (Common Vulnerabilities and Exposures) y se clasifican por gravedad con la puntuación CVSS, de 0 a 10. La puntuación EPSS añade la probabilidad de que la brecha llegue a explotarse, una señal muy útil para fijar prioridades.

Puntuación: CVE, CVSS y EPSS

El valor CVSS describe el daño potencial teórico, pero no dice nada sobre si la brecha está siendo atacada de verdad. Ahí entra EPSS: pronostica la probabilidad de explotación en los 30 días siguientes. Si además la brecha figura en el catálogo KEV (Known Exploited Vulnerabilities), está demostradamente en uso y pasa al primer lugar. Solo la combinación de gravedad (CVSS), probabilidad (EPSS) y exposición del sistema da una priorización técnica sólida.

Brechas conocidas frente a días cero

Para la mayoría de los CVE catalogados ya existe un parche: siguen siendo peligrosos únicamente porque la actualización no se aplica. Con los «días cero» ocurre lo contrario: se explotan antes de que el fabricante publique una corrección. Mientras no haya parche, solo cuentan las medidas compensatorias: parcheo virtual mediante una regla de WAF, filtros de red adicionales, bastionado de la configuración o apagar temporalmente el servicio afectado.

El proceso técnico de tratamiento

Las herramientas automatizan el ciclo de vida: los escáneres de vulnerabilidades y las herramientas de análisis de composición cotejan sistemas, contenedores y dependencias con las bases de datos CVE de forma continua, y un SBOM (inventario de componentes de software) es lo que hace visibles los componentes vulnerables. Del hallazgo se deriva un plazo de parcheo vinculante, ajustado a la criticidad. Las señales de una explotación ya en curso las aportan los indicadores de compromiso.

• Identificación: análisis programado, cotejo con el SBOM e importación de fuentes (NVD, KEV, avisos del fabricante).
• Evaluación: ponderar la gravedad CVSS junto con la probabilidad EPSS y la exposición real.
• Tratamiento: aplicar el parche dentro del plazo y, si no es posible, bastionar o recurrir al parcheo virtual.
• Verificación: repetir el análisis y comprobar que la brecha cerrada ya no aparece.
• Documentación: anotar marca de tiempo, medida adoptada y comprobante del nuevo análisis como prueba.

Plazos de parcheo en la práctica

Han dado buen resultado los plazos internos escalonados: las brechas críticas (CVSS 9,0 a 10,0) en 24 a 72 horas, las altas en siete días y las medias en 30 días. Ejemplo: un escáner de vulnerabilidades informa de CVE-2026-XXXX, con CVSS 9,8 y un EPSS alto, en una biblioteca del portal de clientes accesible desde internet. Como coinciden gravedad, probabilidad y exposición, se activa el plazo de 24 horas: el equipo aplica una actualización de emergencia, revisa los registros en busca de IoC y confirma con un nuevo análisis que la brecha está cerrada. Así no llega a producirse un incidente significativo. Esta disciplina técnica forma parte de la gestión de riesgos y de la ciberhigiene, que NIS2 exige en su artículo 21. España todavía no ha transpuesto la directiva y sigue aplicando el Real Decreto-ley 12/2018 y el Real Decreto 43/2021, pero el trabajo técnico no depende de ese texto: se puede empezar hoy.

Más información: ENISA — Agencia de la UE para la Ciberseguridad