El Reglamento de Ciberresiliencia (CRA) de la Unión Europea plantea una pregunta que los mantenedores de software libre ya conocen bien: ¿qué se envió y cuándo se supo de un problema? A partir del 11 de septiembre de 2026, esta cuestión deja de ser una preocupación informal para convertirse en una obligación legal para numerosas empresas.
La experiencia de un mantenedor
Shane Warden, arquitecto principal de ActiveState y mantenedor de un proyecto de software libre, relata un incidente ocurrido el año pasado. Recibió un informe de vulnerabilidad con 95 fallos, firmado con GPG y siguiendo el protocolo de divulgación responsable. Aunque solo dos o tres resultaron reales, el equipo tuvo que revisarlos todos. Después llegó una segunda comunicación: pagar 100.000 dólares o el informe se haría público con una campaña mediática similar a la de Heartbleed. El informe estaba inflado, pero la amenaza era real porque el alcance de una divulgación así afecta a todas las implementaciones del software vulnerable que un atacante pueda encontrar.
Warden señala que los problemas que enfrentan los mantenedores de código abierto pronto serán los mismos que enfrenten las empresas. La realidad informal de los voluntarios se convertirá en la realidad operativa de todo el mundo del software.
El CRA y sus plazos
El 11 de septiembre de 2026 entran en vigor las obligaciones de reporte del CRA. Cualquier fabricante con un producto con elementos digitales vendido en la UE deberá notificar a ENISA en un plazo de 24 horas desde que tenga conocimiento de que una vulnerabilidad está siendo explotada activamente, con un informe más completo en 72 horas. Los requisitos de ingeniería, que obligan a cómo construir y mantener el producto, se aplicarán a partir del 11 de diciembre de 2027. Esto deja quince meses de 'informar rápido' antes de que la ley exija demostrar que se ha construido correctamente.
Abby Kearns, CEO de ActiveState, ha escrito sobre esta brecha: durante ese período, el CRA es funcionalmente un requisito de visibilidad, no de seguridad. Warden coincide y añade que la pregunta '¿qué se envió y cuándo supimos que había un problema?' no es nueva para los equipos de cumplimiento; los mantenedores de código abierto ya la responden informalmente, bajo presión y con herramientas propias.
El desafío de saber qué se envió realmente
Cuando la Orden Ejecutiva 14028 de EE. UU. exigió listas de materiales de software (SBOM) a proveedores federales, muchas organizaciones generaron el documento una sola vez, bajo presión, y quedó obsoleto rápidamente. Un SBOM de marzo no dice qué se ejecuta hoy. El CRA es más explícito: el Artículo 13 exige que el SBOM esté actualizado. La brecha es mayor de lo que se cree: el 98% de las aplicaciones contienen componentes de código abierto, según el informe de Black Duck de 2026, por lo que casi todos los fabricantes que venden en la UE deben responder a esto.
Las cifras de la industria sobre tiempos de remediación no son alentadoras: el tiempo medio para corregir una vulnerabilidad alta o crítica es de unos 55 días, según Edgescan. La aplicación del CRA vivirá en la brecha entre las 24 horas de alerta temprana, las 72 horas de notificación completa y ese promedio de remediación.
Las organizaciones cierran esa brecha de dos maneras. Algunas desarrollan la capacidad internamente: instrumentan sus canalizaciones para regenerar SBOM automáticamente, establecen un proceso documentado de gestión de vulnerabilidades con un responsable designado y tratan la procedencia como una propiedad de la cadena de suministro, no como un informe de auditoría. Otras deciden que derivar la procedencia de cada componente de código abierto no es una habilidad técnica central y optan por consumir componentes ya verificados y atestiguados, de modo que la pregunta sobre la procedencia se responda antes de que el componente entre en la compilación.
Preguntas clave y preparación
El reloj del CRA comienza el 11 de septiembre de 2026, y la mayoría de los equipos de seguridad e ingeniería solo pueden responder dos o tres de las cinco preguntas que harán los reguladores. ActiveState ofrece una evaluación de preparación para el CRA que ayuda a identificar brechas antes de que lo haga ENISA.
ActiveState ha creado catálogos curados con componentes de código abierto de 12 ecosistemas de lenguajes, entregados con procedencia inmutable en tiempo de compilación y remediados según acuerdos de nivel de servicio contractuales: 5 días hábiles para severidad crítica una vez que exista un parche aguas arriba, 10 para alta y 30 para el resto. Esto complementa los procesos existentes y elimina la pregunta '¿quién puso esto en nuestra compilación y cuándo?' de la lista de tareas manuales bajo un reloj de 72 horas.
Warden no sabe con certeza qué tan estrictamente aplicará ENISA el Artículo 14 en su primer año, y desconfía de quien afirme lo contrario. Pero recuerda que el informe de 95 puntos no esperó a una regulación: le preguntó directamente, con plazo y precio, si sabía lo que estaba ejecutando y qué tan rápido podía demostrarlo. El CRA hará la misma pregunta a todos los fabricantes que vendan en la UE, a escala y con un reloj legal en marcha.
La recomendación es no esperar al 11 de septiembre. Se sugiere elegir un producto enviado hace seis meses y cronometrar cuánto tarda alguien en decir qué contiene y cuándo se supo de la última CVE crítica. Si eso lleva más de 72 horas, ya se tiene la respuesta.
Sobre el autor
Shane Warden es arquitecto principal en ActiveState, donde trabaja desde hace casi siete años. Ha estado activo en código abierto desde finales de los años 90 y es mantenedor en ejercicio, con responsabilidad directa sobre el proceso de divulgación de seguridad de su propio proyecto.
Este artículo ha sido patrocinado y escrito por ActiveState.
Deja una respuesta