El CRA europeo exige notificar en 24 horas las vulnerabilidades explotadas

El Reglamento de Ciberresiliencia (CRA) de la Unión Europea comienza a aplicarse en fases. A partir del 11 de septiembre de 2026, cualquier fabricante que venda productos con elementos digitales en el mercado europeo debe notificar a ENISA, la agencia de ciberseguridad de la UE, en un máximo de 24 horas desde que tenga conocimiento de que una vulnerabilidad en su producto está siendo explotada activamente. El informe completo debe presentarse en 72 horas. Así lo recuerda Shane Warden, arquitecto principal de ActiveState, en un artículo de opinión que analiza los desafíos prácticos de esta obligación.

Warden, que participa en el mantenimiento de proyectos de código abierto, relata una experiencia personal: recibió un informe de seguridad que afirmaba contener 95 vulnerabilidades, de las que solo dos o tres eran reales. Aun así, el equipo tuvo que trabajar con todas para identificar las válidas. Después llegó un intento de extorsión: pagar 100.000 dólares o hacer público el informe con una campaña de prensa. El incidente ilustra, según él, la presión que ya soportan los mantenedores y que ahora se trasladará a un marco legal para muchas empresas.

El CRA establece dos calendarios. Las obligaciones de notificación arrancan en septiembre de 2026, mientras que los requisitos de ingeniería, que dictan cómo construir y mantener el producto, se aplicarán a partir del 11 de diciembre de 2027. Es decir, quince meses en los que la ley se centra sobre todo en la visibilidad: 'qué se envió y cuándo supimos que había un problema', en palabras de Warden. La consejera delegada de ActiveState, Abby Kearns, ya señaló esta brecha en un análisis previo.

El reto de saber qué se ha enviado

Uno de los puntos centrales es el artículo 13, que exige mantener una lista de materiales de software (SBOM) actualizada. Warden compara esta exigencia con la orden ejecutiva 14028 de Estados Unidos, que llevó a muchas organizaciones a generar SBOMs una sola vez, bajo presión, que quedaban obsoletos al día siguiente. El CRA, en cambio, exige que estén al día.

El problema es de escala. Según el informe de Black Duck sobre seguridad de código abierto de 2026, el 98% de las aplicaciones contienen componentes de código abierto. Y el tiempo medio de remediación de vulnerabilidades altas o críticas ronda los 55 días, según Edgescan. Esa brecha entre el plazo de 24 horas y los 55 días de media es donde va a operar la aplicación de la ley.

Warden plantea dos estrategias para cerrar esa brecha. Una es construir la capacidad internamente: instrumentar las canalizaciones para regenerar SBOMs automáticamente y establecer procesos documentados de gestión de vulnerabilidades con un responsable designado. La otra es recurrir a terceros que ofrezcan componentes ya verificados y atestiguados, de modo que la procedencia quede resuelta antes de entrar en la compilación. Ambas son válidas, pero advierte: es arriesgado descubrir en el mes catorce que 'seremos conformes' no incluía la capacidad real de responder a la pregunta.

El artículo no profundiza en cómo aplicará ENISA la normativa en su primer año, y Warden se declara escéptico ante quien afirme saberlo con certeza. Lo que sí tiene claro es que la pregunta 'qué se envió y cuándo lo supimos' dejará de ser un problema solo de voluntarios para convertirse en una realidad operativa para todo el sector del software.