Monitorización
Monitorización continua de vulnerabilidades en productos ya comercializados
La monitorización continua de vulnerabilidades consiste en volver a contrastar los componentes de cada producto al que todavía das soporte con los datos de vulnerabilidades a medida que esos datos cambian, no solo cuando cambia tu código. Un análisis que estaba limpio en el lanzamiento se queda desfasado a medida que aparecen nuevos avisos, así que la monitorización es lo que convierte un análisis puntual en la gestión continua de las vulnerabilidades que espera el Reglamento de Ciberresiliencia (Cyber Resilience Act).
Plan gratuito, sin tarjeta.
¿Por qué se queda desfasado un análisis limpio?
Un análisis de vulnerabilidades responde a una pregunta en un momento concreto: qué vulnerabilidades conocidas afectan a estas versiones de componentes, según los datos de avisos de hoy. Cada día se publican nuevos registros CVE, y los existentes se revisan a medida que se conocen las versiones afectadas, las correcciones y las pruebas de explotación. Tu producto no tiene que cambiar para que cambie su riesgo: una imagen de firmware sin problemas conocidos en marzo puede contener en junio una vulnerabilidad aprovechada activamente, con los mismos bytes en todos los dispositivos sobre el terreno.
Por eso el CRA plantea la gestión de las vulnerabilidades como un proceso y no como un hecho puntual. El anexo I, parte II, pide a los fabricantes identificar y documentar las vulnerabilidades y los componentes, subsanarlas sin demora y llevar a cabo exámenes y pruebas eficaces y periódicos. Esas obligaciones duran todo el período de soporte, que el artículo 13(8) fija en un mínimo de cinco años, salvo que se prevea que el producto vaya a utilizarse durante menos tiempo.
Reanalizar las versiones publicadas frente a la rama principal
Analizar la rama principal en cada cambio es útil, pero te habla del código que publicarás a continuación, no del código que ejecutan tus clientes. Los dispositivos sobre el terreno ejecutan versiones publicadas: la 2.3 en unos, la 2.4 en otros y una larga cola de unidades que nunca se actualizaron. Cada versión con soporte necesita su propia lista de componentes, contrastada de nuevo con los datos de avisos actuales, porque la pregunta «¿están expuestos nuestros clientes?» la responde la versión publicada, no la rama.
Guarda una nomenclatura de materiales de los programas informáticos (SBOM) por cada versión publicada, vinculada al número de versión que ven los usuarios. Así, cuando coincida un nuevo aviso, podrás decir qué versiones están afectadas y a qué versión corregida remitir a los clientes. En el caso del software, el artículo 13(10) del CRA permite subsanar solo en la última versión modificada sustancialmente, siempre que los usuarios de versiones anteriores puedan pasar a ella de forma gratuita y sin costes adicionales para adaptar su entorno.
Contraste periódico del SBOM: monitorizar sin recompilar
En lugar de recompilar y volver a analizar el producto, conservas el SBOM generado en el lanzamiento y comparas periódicamente los nombres y versiones de sus componentes con bases de datos de avisos como OSV.dev, la NVD y la base de datos europea de vulnerabilidades (EUVD) de ENISA. Como el SBOM describe lo que se publicó, una coincidencia es una coincidencia con versiones reales. El resultado es tan bueno como el SBOM: los componentes sin versión ni identificador de paquete no pueden emparejarse de forma fiable, y el código incorporado al repositorio (vendored) o enlazado estáticamente que el SBOM no enumera sigue siendo invisible.
Este contraste periódico complementa un reanálisis completo, también periódico, no lo sustituye. Un análisis completo aprovecha una mejor detección de componentes, nuevas reglas de análisis y problemas que no son vulnerabilidades de componentes, como secretos subidos al repositorio o configuraciones incorrectas, así que ejecuta uno en cada versión y siempre que cambie la compilación.
¿Cómo ayudan KEV y EPSS a priorizar las nuevas vulnerabilidades?
La monitorización produce un flujo de coincidencias; la priorización decide cuáles se atienden primero. Ayudan dos señales públicas. El catálogo Known Exploited Vulnerabilities (KEV) de CISA enumera vulnerabilidades que tienen un identificador CVE, pruebas fiables de explotación en entornos reales y orientaciones claras para corregirlas. El Exploit Prediction Scoring System (EPSS) de FIRST publica cada día, para cada CVE, una probabilidad estimada de que se explote en entornos reales en los próximos 30 días. CVSS describe lo grave que podría ser una explotación; KEV y EPSS indican si ya ha ocurrido o lo probable que es.
Combínalas con tu propio contexto. Una vulnerabilidad incluida en KEV en un componente que distribuyes debería clasificarse el mismo día: ¿está presente y es alcanzable el código vulnerable en tu build, y qué versiones lo llevan? Deja constancia del razonamiento en cualquier caso; una decisión documentada de «no afectado» es tan útil para un auditor como una corrección.
¿Cómo alimenta la monitorización la notificación del artículo 14 del CRA?
Desde el 11 de septiembre de 2026, el artículo 14 del CRA obliga a los fabricantes a notificar las vulnerabilidades aprovechadas activamente presentes en sus productos al CSIRT designado como coordinador y a ENISA, a través de la plataforma única de notificación de ENISA. La alerta temprana debe enviarse en un plazo de 24 horas desde que el fabricante tiene conocimiento de la vulnerabilidad, la notificación de la vulnerabilidad en 72 horas y el informe final a más tardar 14 días después de que esté disponible una medida correctora o paliativa. Según el artículo 69(3), el artículo 14 también se aplica a los productos incluidos en el ámbito de aplicación que se hayan introducido en el mercado antes del 11 de diciembre de 2027.
El reloj empieza a correr cuando se tiene conocimiento, lo que convierte la monitorización en la primera etapa de tu proceso de notificación. Una nueva entrada de KEV que coincide con un componente de un producto publicado es una señal que una persona debe evaluar rápidamente: ¿es una vulnerabilidad aprovechada activamente presente en tu producto, es decir, existen pruebas fiables de que un agente malintencionado la ha aprovechado en un sistema sin autorización del propietario? Sea cual sea la respuesta, el artículo 13(7) espera que documentes las vulnerabilidades de las que tengas conocimiento y que actualices la evaluación de riesgos cuando corresponda.
Cómo fijar la cadencia de la monitorización y sus responsables
La monitorización falla en silencio cuando nadie se ocupa de sus resultados. Pon por escrito la cadencia y los responsables, como parte de la política de gestión de vulnerabilidades que necesitas de todos modos para el CRA, y prueba el circuito una vez antes de confiar en él. Una base que puedes adaptar a tus productos:
- Un responsable por producto, con un suplente, que revisa las coincidencias nuevas cada día laborable y las de KEV el mismo día.
- Un registro de las versiones con soporte, cada una con su SBOM y su fecha de fin de soporte.
- Nuevo contraste de cada versión con soporte al menos una vez al día y reanálisis completo en cada versión o cambio de compilación.
- Un orden de clasificación: primero las explotadas conocidas, después las de EPSS alto y después la gravedad CVSS, ajustado según la exposición.
- Una persona que pueda aprobar una notificación del artículo 14 en 24 horas, fines de semana incluidos.
- Un registro de decisión para cada coincidencia (afectado, no afectado, corregido en una versión concreta) con su evidencia.
Disponible hoy en KROMSE
En los planes de pago, KROMSE vuelve a contrastar el último SBOM de cada producto con los datos de avisos actuales y muestra las coincidencias nuevas dentro del producto.
- Cada 6 horas se vuelve a contrastar con OSV.dev el último SBOM de cada producto, hasta 5 productos por espacio de trabajo en cada ciclo, de forma rotatoria.
- Las coincidencias nuevas aparecen como mensajes dentro de la aplicación, y un botón «Run monitoring now» lanza una comprobación cuando la necesitas.
- Los hallazgos con identificador CVE se enriquecen con CISA KEV, FIRST EPSS, la NVD y la base de datos europea de vulnerabilidades (EUVD) de ENISA.
- Cada análisis genera SBOM en CycloneDX y SPDX, y puedes subir los SBOM que ya tengas.
- En los planes de pago, borradores internos de informes del artículo 14 del CRA para las fases de 24 horas, 72 horas y final, en PDF, para que una persona los apruebe; KROMSE nunca los presenta.
- Límites actuales: no puedes fijar tu propia periodicidad, la monitorización no envía correos electrónicos y no lanza reanálisis automáticamente.
Próximamente
En la hoja de ruta, todavía no disponible. Las fechas son objetivos, no promesas; esta página cambia el mismo día en que una funcionalidad está operativa.
- Próximamente · T4 2026 (diciembre)Monitorización según tu calendario, con agentes de IA. Los reanálisis se ejecutarán con la periodicidad que tú fijes, con agentes de IA que vigilarán los nuevos avisos, clasificarán lo que te afecta, propondrán correcciones y redactarán el informe para tu revisión.
- Próximamente · T4 2026 (noviembre)Propuestas de corrección con IA, aprobadas por una persona. KROMSE propondrá correcciones para los hallazgos, redactadas con IA y aplicadas solo después de que una persona de tu equipo las apruebe.
- Próximamente · T1 2027Envío a la plataforma única de notificación de ENISA. Cuando una persona apruebe una notificación del artículo 14, KROMSE la enviará a la plataforma única de notificación de ENISA.
Preguntas frecuentes
¿Qué diferencia hay entre el análisis de vulnerabilidades y la monitorización continua de vulnerabilidades?
Un análisis inspecciona un producto una vez y enumera las vulnerabilidades conocidas de sus componentes en ese momento. La monitorización continua repite la comparación a medida que cambian los datos de avisos, normalmente volviendo a contrastar el SBOM de cada versión, de modo que te enteras de las nuevas vulnerabilidades de los productos ya comercializados sin esperar al siguiente cambio de código.
¿Cada cuánto hay que volver a comprobar los productos comercializados en busca de nuevas vulnerabilidades?
Ninguna ley de la UE fija un intervalo concreto. El CRA exige exámenes y pruebas periódicos y la subsanación sin demora, y su plazo de notificación corre desde que se tiene conocimiento de una vulnerabilidad aprovechada activamente, así que el intervalo debería permitirte detectarla en horas, no en semanas. Volver a contrastar el SBOM a diario o con más frecuencia, más un reanálisis completo en cada versión, es un punto de partida razonable.
¿Que una vulnerabilidad figure en KEV significa que debo notificarla según el artículo 14 del CRA?
No automáticamente. El artículo 14 se refiere a las vulnerabilidades aprovechadas activamente presentes en tu producto: tiene que haber pruebas fiables de que un agente malintencionado ha aprovechado la vulnerabilidad en un sistema sin autorización del propietario. Una entrada en KEV es una prueba sólida de explotación, pero una persona todavía tiene que establecer si el código vulnerable está en tu producto. En cuanto tengas conocimiento de que lo está, empieza a correr el plazo de 24 horas.
¿Importa la monitorización para los productos introducidos en el mercado antes de que se aplique el CRA?
Sí, para la notificación. El artículo 69(3) hace que el artículo 14 se aplique a los productos incluidos en el ámbito de aplicación introducidos en el mercado antes del 11 de diciembre de 2027, y el artículo 14 se aplica desde el 11 de septiembre de 2026. Las preguntas frecuentes de la Comisión sobre el CRA explican que, para estos productos, los fabricantes deben notificar, pero no están obligados a cumplir otras obligaciones, como la gestión de las vulnerabilidades. Para detectar en ellos una vulnerabilidad explotada, sigues necesitando saber qué contienen.
¿KROMSE me envía un correo cuando una nueva vulnerabilidad coincide con mi producto?
Hoy no. En los planes de pago, KROMSE vuelve a contrastar con OSV.dev el último SBOM de cada producto cada 6 horas, hasta 5 productos por espacio de trabajo en cada ciclo de forma rotatoria, y muestra las coincidencias nuevas como mensajes dentro de la aplicación. La monitorización con la periodicidad que tú fijes, con agentes de IA, está en la hoja de ruta.
Guías relacionadas
Fuentes
- Reglamento (UE) 2024/2847 (Reglamento de Ciberresiliencia), EUR-Lex
- Comisión Europea: preguntas frecuentes sobre la aplicación del Reglamento de Ciberresiliencia
- ENISA: plataforma única de notificación (Single Reporting Platform)
- ENISA: base de datos europea de vulnerabilidades (EUVD)
- CISA: catálogo Known Exploited Vulnerabilities
- FIRST: Exploit Prediction Scoring System (EPSS)
- OSV: base de datos de vulnerabilidades de código abierto