Vulnerabilidades: de la CVE a la aplicación de negocio
Cada semana trae sus vulnerabilidades críticas. La verdadera pregunta es: ¿cuáles afectan a sus aplicaciones de negocio, y quién debe actuar? KANAP puede ayudarle, desde la CVE publicada hasta la decisión registrada, pasando por la identificación de los servidores y las aplicaciones afectados.
Jueves por la mañana, el feed anuncia treinta nuevas vulnerabilidades críticas. El CISO pregunta cuáles nos afectan. El equipo de infraestructura abre una hoja de cálculo, busca los productos, las versiones, los servidores, y se conecta aquí y allá para comprobarlo. Al día siguiente, nadie está todavía seguro de tener la información completa.
El problema es el camino que separa una vulnerabilidad publicada de la aplicación de negocio a la que amenaza. Este es el método para seguir ese rastro, y así es como KANAP lo reúne en una sola pantalla.
Cuatro eslabones para responder
Una vulnerabilidad afecta a un producto y a unas versiones. Para saber si le afecta, hay que unir cuatro eslabones:
- La tecnología: SQL Server, Tomcat, vCenter, lo que sus aplicaciones necesitan para funcionar.
- Su versión: SQL Server 2019 no tiene las mismas vulnerabilidades que SQL Server 2022.
- El servidor que la aloja.
- La aplicación de negocio que depende de ella, con su criticidad y su responsable.
En KANAP existen todos estos eslabones: las aplicaciones y sus servidores en el panorama IT, y las tecnologías y sus versiones entre ambos.
Dos fuentes oficiales combinadas
Cada 6 horas, KANAP lee la NVD, la base de datos estadounidense de vulnerabilidades, y compara cada vulnerabilidad con sus tecnologías, versión por versión. La NVD es la referencia, pero tiene un defecto: asocia las vulnerabilidades a los productos con retraso, y a veces nunca.
Un ejemplo con una tecnología que todo el mundo usa. En 2026, la fundación Apache publicó 60 vulnerabilidades de Apache Tomcat. El 23 de octubre, la NVD había asociado 40 al producto. Las otras 20, publicadas el 23 de septiembre y el 20 de octubre, de las cuales 6 críticas y 7 altas, aún no tenían ningún producto en la NVD.
Por eso KANAP lee una segunda fuente: las fichas que los propios fabricantes publican en CVE.org, con sus productos y sus versiones. Una fila existe en cuanto una de las dos fuentes relaciona la vulnerabilidad con su tecnología. Cuando la NVD aún no ha puntuado una vulnerabilidad, KANAP muestra la puntuación del fabricante.
Cada fila indica qué fuente la encontró: la NVD, el fabricante o ambos. «Por qué esta fila» da el criterio en lenguaje claro, por ejemplo «Apache Tomcat: versiones 9.0.0 a 9.0.98 afectadas». Y la página indica cuándo se leyó cada fuente por última vez, con un aviso si una lectura ha fallado.
Prioridad a las vulnerabilidades explotadas
La puntuación CVSS indica la gravedad teórica de una vulnerabilidad, no el riesgo real que supone. Una vulnerabilidad con un 9,8 que nadie explota pesa menos que una con un 7,5 que se utiliza activamente. Por eso KANAP cruza tres señales de explotación:
- Los catálogos de vulnerabilidades explotadas de la CISA, la agencia estadounidense, y de la Unión Europea. Una vulnerabilidad que figura en ellos lleva un icono de alerta, cuya información emergente nombra los catálogos y, cuando la CISA lo ha constatado, su uso por ransomware.
- El EPSS, la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días, calculada cada día por el FIRST.
- La base europea de vulnerabilidades de la ENISA, aquella a la que se refiere NIS2: cada vulnerabilidad remite a ella cuando figura allí.
La lista se abre con las vulnerabilidades explotadas y luego las más graves. El filtro «Solo explotadas» conserva únicamente esas: es la vista más importante.
El análisis de impacto
La misma vulnerabilidad no pesa lo mismo en el portal de clientes que en un servidor de pruebas. Ahí es donde KANAP se distingue de una simple lista de CVE: cada fila indica a cuántos servidores y aplicaciones alcanza, y los filtros permiten partir de un servidor o de una aplicación para ver sus vulnerabilidades.
En la ficha de una aplicación, la sección Vulnerabilidades resume sus vulnerabilidades tecnología por tecnología, con el número de críticas, altas y medias. Una insignia en la cabecera señala las vulnerabilidades graves. El responsable de la aplicación ve su exposición sin abrir la página de vulnerabilidades.
En el panel de control, el mosaico «Vulnerabilidades del parque» plantea las preguntas en el orden de un CIO: cuántas aplicaciones de la criticidad más alta tienen una vulnerabilidad crítica o alta, cuántas vulnerabilidades críticas se han publicado en los últimos 7 y 30 días, cuántas están explotadas, cuántos servidores tienen una vulnerabilidad grave. Cada línea abre la lista correspondiente. La criticidad procede de la clasificación de sus aplicaciones, presentada en el artículo Clasificar las aplicaciones.
Usted elige qué genera una alerta
No todas las tecnologías merecen la misma vigilancia. En cada tecnología, un interruptor la incluye en las alertas o la excluye, y cada versión puede tener el suyo.
Dos familias empiezan sin alertas por defecto; es libre de activarlas. Primero, los sistemas operativos: KANAP no conoce el nivel de parches de un servidor, y un sistema completo haría aparecer cientos de vulnerabilidades ya corregidas. Después, los servicios en línea: el proveedor corrige él mismo un servicio que opera. Si quiere seguir una versión concreta, por ejemplo la de sus servidores más expuestos, basta con activar su interruptor.
Sin embargo, no se oculta nada. Una versión fuera de las alertas sigue relacionándose con las vulnerabilidades y es visible con el filtro «Alertas»: solo se deja de lado en los recuentos, los mosaicos y los correos.
Registrar el tratamiento de las alertas
Una vulnerabilidad nunca está simplemente «vista»: está tratada, descartada con un motivo, o todavía por revisar. Cada fila lleva uno de estos tres estados (por revisar, tratada, no afectada) y una nota: «parcheado el 12 de marzo, cambio CHG-123». El registro de auditoría guarda quién cambió qué estado, y cuándo.
El tratamiento masivo evita el trabajo fila a fila. Por ejemplo, para descartar las vulnerabilidades de PostgreSQL en instalaciones cuya versión no está informada: un filtro por tecnología y versión, una casilla, el estado «no afectada» y el motivo en la nota. Antes de confirmar, KANAP indica cuántas filas y vulnerabilidades afecta el cambio.
Lo demás viene solo. La exportación CSV recoge los filtros mostrados, para el comité de seguridad o el auditor. Los responsables de TI de una tecnología reciben un correo por sus nuevas vulnerabilidades críticas, altas o explotadas, una sola vez por vulnerabilidad. Y Plaid, el asistente integrado en KANAP, responde a las preguntas sobre vulnerabilidades, dentro de los permisos de cada usuario.
Eso es lo que espera una auditoría NIS2: no una lista de vulnerabilidades, sino el registro de lo que el equipo hizo con ellas.
KANAP no es un escáner, lo complementa
Un escáner de vulnerabilidades ve los hosts, los paquetes instalados, los parches aplicados. KANAP ve otra cosa: las aplicaciones de negocio, su criticidad, sus responsables y las tecnologías de las que dependen. No le dice si un parche está aplicado en tal servidor; le dice a qué aplicaciones puede afectar una vulnerabilidad, y quién debe revisarla.
Por dónde empezar
- Cree sus tecnologías desde el catálogo: 192 productos, con sus versiones, sus fechas de soporte y sus identificadores de vulnerabilidad ya informados, listos para usar.
- Introduzca las versiones en sus servidores y sus aplicaciones, o importe los vínculos con un archivo CSV.
- Nombre a los responsables de TI de cada tecnología: son ellos quienes recibirán las alertas.
- Abra la página Vulnerabilidades en «Solo explotadas».
Si aloja KANAP usted mismo, active primero las vulnerabilidades e introduzca una clave de la NVD, como explica la guía de configuración.
Para verlo todo en acción, una prueba gratuita de 14 días de nuestra versión alojada da acceso a los datos de ejemplo del grupo ficticio Fromage & Co, cargados en un minuto. KANAP es totalmente de código abierto: también puede instalarse gratis en sus propios servidores.