Imagen: Unión Europea, publicada en la presentación oficial del Cyber Resilience Act, bajo licencia CC BY 4.0.
El pasado 11 de septiembre empezó a aplicarse una de las primeras partes del Cyber Resilience Act, el Reglamento de Ciberresiliencia de la Unión Europea. Desde ese día, los fabricantes de productos digitales tienen que notificar las vulnerabilidades que estén siendo explotadas y los incidentes graves de seguridad dentro de unos plazos bastante ajustados.
El primer aviso debe llegar en un máximo de 24 horas. La notificación con una evaluación inicial, en 72.
Puede parecer otro reglamento europeo lleno de definiciones, plazos y siglas. En parte lo es. Pero detrás hay una idea bastante fácil de entender: si una empresa gana dinero vendiendo un programa o un aparato conectado, también debería responsabilizarse de su seguridad después de ponerlo en manos de sus clientes.
Una especie de marcado CE para el software
El Cyber Resilience Act se aplica a los llamados productos con elementos digitales que se comercializan en la Unión Europea. La definición es amplia e incluye tanto hardware como software: desde routers, cámaras y relojes inteligentes hasta aplicaciones, sistemas operativos o componentes vendidos por separado.
Cuando el reglamento sea plenamente aplicable, en diciembre de 2027, los fabricantes tendrán que evaluar los riesgos de sus productos, diseñarlos con medidas de seguridad adecuadas, gestionar sus vulnerabilidades, publicar actualizaciones y mantener documentación sobre todo ese proceso.
Los productos deberán superar el procedimiento de evaluación que les corresponda y utilizar el marcado CE para indicar que cumplen los requisitos. La mayoría podrá evaluarse mediante procedimientos internos, mientras que algunas categorías consideradas importantes o críticas estarán sometidas a controles adicionales.
Podemos verlo como una especie de marcado CE para el software y los dispositivos conectados. No garantiza que un producto sea invulnerable, porque eso no existe. Obliga a que haya alguien identificable haciéndose responsable de reducir los riesgos y reaccionar cuando aparezcan problemas.
Lo que ya ha empezado a contar
La mayor parte del reglamento todavía no se aplica, pero las obligaciones de notificación ya están en marcha.
Un fabricante debe informar cuando tenga constancia de una vulnerabilidad activamente explotada, es decir, cuando existan pruebas fiables de que alguien la ha aprovechado de forma maliciosa. También debe comunicar los incidentes que tengan un impacto grave sobre la disponibilidad, autenticidad, integridad o confidencialidad de un producto.
Esto no significa que haya que enviar a Europa cada bug, cada CVE o cada informe generado automáticamente por una herramienta. La obligación se refiere a vulnerabilidades explotadas e incidentes graves, no a cualquier fallo posible.
El proceso comienza con un aviso temprano en menos de 24 horas. Antes de que pasen 72 horas hay que aportar información general y una primera evaluación. Después llegará el informe final: para una vulnerabilidad explotada, como máximo 14 días después de disponer de una corrección o medida de mitigación; para un incidente grave, dentro del mes siguiente a la notificación de las 72 horas.
Todo se presenta a través de una plataforma única gestionada por ENISA, la Agencia de la Unión Europea para la Ciberseguridad. La empresa hace una sola notificación, que se distribuye al CSIRT correspondiente y a las autoridades que deban conocerla.
Para los usuarios, alguien responde
La parte positiva para quienes compramos estos productos es evidente. Durante años hemos convivido con dispositivos que llegan al mercado, reciben dos actualizaciones y quedan abandonados aunque sigan funcionando perfectamente.
El CRA intenta cambiar esa relación. La seguridad deja de ser una característica opcional que cada fabricante puede cuidar más o menos y pasa a formar parte de sus obligaciones durante el periodo de soporte del producto.
Eso debería traducirse en productos con configuraciones más seguras, actualizaciones disponibles durante un tiempo definido e información más clara. También debería ser más difícil lanzar algo al mercado y desentenderse de sus vulnerabilidades en cuanto termina la campaña de venta.
No hará desaparecer los fallos ni impedirá todos los ataques. Lo que sí puede hacer es evitar que, cuando aparezca un problema, nadie sepa quién debía estar mirando.
Para las empresas, conocer lo que venden
La parte complicada no será rellenar el formulario de ENISA. Será conseguir la información necesaria antes de que termine el plazo.
El software actual se construye sobre una cantidad enorme de componentes. Una aplicación puede depender de bibliotecas abiertas, paquetes mantenidos por otras empresas, servicios externos y piezas que a su vez arrastran sus propias dependencias.
Cuando se descubre una vulnerabilidad explotada en una de ellas, el fabricante necesita responder rápidamente a preguntas bastante básicas: ¿utilizamos ese componente?, ¿en qué productos y versiones?, ¿está afectada la función que usamos?, ¿quién se encarga de comprobarlo?, ¿cómo distribuimos una corrección?
Si la empresa no tenía ese mapa preparado, tendrá que construirlo mientras el reloj de las 24 horas sigue corriendo.
Por eso el reglamento está dando importancia a los inventarios de componentes y a las SBOM, listas de materiales de software que detallan las piezas incluidas en un producto. Una SBOM no arregla vulnerabilidades por sí sola. Al menos permite saber dónde buscar cuando aparece una.
La responsabilidad tampoco desaparece porque el fallo esté en una dependencia ajena. Si una empresa incorpora una biblioteca abierta a un producto comercial, sigue siendo responsable del producto que ha decidido vender con ella dentro.
El software libre no es el fabricante gratuito de nadie
Este fue uno de los puntos más polémicos durante la preparación del reglamento. Buena parte de la infraestructura digital funciona gracias a proyectos abiertos mantenidos por comunidades pequeñas o incluso por una sola persona. Aplicarles las mismas obligaciones que a una multinacional habría sido absurdo.
Viñeta: «Dependency», xkcd 2347, por Randall Munroe, publicada bajo licencia CC BY-NC 2.5.
El texto definitivo establece varias diferencias importantes. Contribuir código a un proyecto ajeno no te convierte en fabricante. Publicar un programa abierto sin intención de monetizarlo tampoco se considera, en general, una actividad comercial sometida al CRA.
Si una empresa toma ese código y lo incluye en algo que vende, es la empresa quien debe evaluar el riesgo y responder por su uso. La licencia abierta no convierte al autor original en el departamento de seguridad gratuito de todos sus usuarios comerciales.
El reglamento también crea la figura del administrador de software de código abierto para determinadas organizaciones que apoyan de manera continuada proyectos destinados a usos comerciales sin ser ellas mismas fabricantes. Tendrán un régimen más ligero, sus obligaciones de notificación no empezarán hasta diciembre de 2027 y no estarán sujetas a las multas administrativas del CRA.
Sobre el papel, la separación tiene sentido. El riesgo aparecerá en la práctica si las empresas intentan cumplir trasladando el trabajo hacia arriba: enviando cuestionarios, exigiendo documentación urgente o pidiendo respuestas inmediatas a los mantenedores de cada dependencia que utilizan.
Una empresa responsable debería conocer sus componentes, investigar primero el impacto sobre su producto y colaborar con los proyectos originales cuando pueda aportar información o una corrección. No limitarse a descargar una biblioteca gratis y devolverle al mantenedor toda la presión cuando aparece un problema.
La seguridad también necesita tiempo y personas
Hace unos días escribía sobre cómo las herramientas de IA están ayudando a encontrar más fallos en Linux, pero también están aumentando la cantidad de informes y parches que alguien tiene que revisar.
El Cyber Resilience Act añade otra pieza a esa conversación. Podemos detectar problemas más rápido y obligar a las empresas a comunicar antes los incidentes. Ambas cosas pueden mejorar la seguridad. Ninguna crea automáticamente más personas capaces de analizar un informe, comprobar una dependencia y preparar una corrección.
El reglamento acierta al colocar la responsabilidad sobre quien comercializa el producto. Ahora falta que las empresas asuman esa responsabilidad de verdad: con inventarios actualizados, equipos preparados, procesos ensayados y apoyo a los proyectos abiertos de los que dependen.
Si el resultado es que los productos reciben mejores actualizaciones y las empresas dejan de tratar la seguridad como un problema para más adelante, el CRA habrá servido para algo. Si acaba generando montañas de formularios y trabajo urgente para los mismos mantenedores de siempre, habremos puesto en marcha el cronómetro sin reforzar a quienes tienen que llegar a tiempo.
Fuentes y referencias
- Resumen del Reglamento de Ciberresiliencia de la Comisión Europea
- Texto completo del Reglamento (UE) 2024/2847
- Obligaciones de notificación del Cyber Resilience Act
- Preguntas frecuentes sobre la plataforma de notificación de ENISA
- La Comisión Europea sobre el CRA y el software de código abierto
- Guía de OpenSSF para desarrolladores de software libre
- Cómo se están preparando las organizaciones, según Linux Foundation