Autor: Gaël Blondelle, Chief Membership Officer, Eclipse Foundation
La Cyber Resilience Act (CRA) de la Unión Europea marca un punto de inflexión para el diseño, la venta y el mantenimiento de productos digitales. Tanto si se trata de software empresarial, aplicaciones para consumidores, dispositivos IoT o sistemas embebidos, la CRA establece unos exigentes requisitos de ciberseguridad que se aplican a lo largo de todo el ciclo de vida de un producto; desde el diseño y el desarrollo hasta el despliegue, el mantenimiento y el desmantelamiento seguro.
En el fondo, la CRA trata sobre la seguridad por diseño. Obliga a aplicar transparencia, una gestión robusta de la vulnerabilidad y actualizaciones seguras respaldadas por mecanismos de control de su cumplimiento como el marcado CE, listas de materiales de software (Software Bills of Materials, SBOM) legibles por máquinas y documentación que acredite el cumplimiento.
Por qué hay que empezar ya
La CRA redefine fundamentalmente cómo se construirá el software y cómo será su mantenimiento, presionando así a las organizaciones a adoptar estrategias de desarrollo más estructuradas, transparentes y centradas en la seguridad. Y si usted es como la mayoría de los desarrolladores de software comercial que incorporan componentes open source, deberá tenerlo en cuenta. Su equipo necesitará tiempo para adaptar los flujos de trabajo de desarrollo y seguridad que se ajusten a estas nuevas expectativas.
Los plazos para el cumplimiento de la CRA ya están en marcha:
- Diciembre 2024 – La CRA entra en vigor. Esto marcó el inicio del período de transición para todas las partes afectadas.
- Septiembre 2026 – Entran en vigor las primeras obligaciones, incluida la emisión de informes de vulnerabilidad a las autoridades de la UE, concretamente a la ENISA (European Union Agency for Cybersecurity).
- 11 de diciembre de 2027 – Inicio del cumplimiento íntegro. A partir de este día, las partes deben disponer de SBOM legibles por máquinas, mecanismos de actualización segura y documentación detallada del cumplimiento para cada producto pertinente.
También es importante subrayar que en caso de incumplimiento no solamente se aplica una multa, sino que puede significar la expulsión de todo el mercado de la UE.
Funciones y responsabilidades definidas por la CRA
Antes de entrar en los efectos reales de estas regulaciones, tomemos un momento para aclarar las diferentes funciones y responsabilidades en el proceso de desarrollo de software. En su última iteración, la CRA aclara las diferentes funciones y a quién corresponde dentro del ecosistema open source:
- Fabricantes: Cualquier entidad que comercializa un producto (incluidos los construidos a partir de OSS) en el mercado de la UE. Asumen toda la responsabilidad legal en lo relativo a la seguridad a lo largo de la vida útil del software.
- Administradores de open source: Actores económicos de nueva definición, como aquellos que ofrecen soporte sistemático a un proyecto open source, como una oferta sostenida y destinada a uso comercial.
- Encargados de mantenimiento/colaboradores: Personas o equipos que se dedican al desarrollo. Generalmente no están obligados directamente por las obligaciones de la CRA a menos que actúen como administradores o fabricantes.
Esta distinción estructurada permite que la CRA exima a los colaboradores ocasionales y se concentre en la responsabilidad legal de los productores en fases posteriores (downstream). No obstante, aunque los encargados de mantenimiento no tengan una obligación directa, las cadenas de dependencia les obligan a adaptarse en la práctica. Por ejemplo, muchos fabricantes insistirán en una potente higiene, transparencia y capacidad de respuesta de la seguridad para proyectos de fases anteriores (upstream). Como resultado de ello, los encargados de mantenimiento llegarán a la conclusión de que necesitan flujos de trabajo más estructurados, claridad para manejar la vulnerabilidad y unas vías de colaboración más sencillas.
Obligaciones específicas para las organizaciones que desarrollan software
Está claro que los fabricantes asumen la mayor carga en este contexto. ¿Pero de qué son responsables? Según la CRA, los fabricantes de cualquier tamaño, incluidos los editores de software, deben:
- Generar un listado de SBOM legibles por máquinas, como mínimo, para las dependencias de alto nivel.
- Mantener las SBOM actualizadas y entregarlas a las autoridades de supervisión si se les solicita.
- Mantener entornos de gestión de la vulnerabilidad, como disponer de un canal público para envío de informes y reparación rápida.
- Aplicar actualizaciones seguras, si es posible inalámbricas, y separarlas de las actualizaciones funcionales.
- Compartir parches con las fases anteriores para los componentes OSS que utilizan, fomentando así una mejor seguridad del ecosistema.
El incumplimiento de la CRA puede conllevar un coste elevado. Las multas pueden alcanzar los 15 millones de euros o el 2,5% de la facturación anual en todo el mundo, la mayor de ambas. Algunas responsabilidades que antes habían sido opcionales, como compartir parches con proyectos en fases anteriores, ahora son de cumplimiento obligatorio. Este cambio significa que las organizaciones se han de replantar cómo gestionan su cumplimiento a lo largo de toda la vida útil del software. Esto incluye la generación y el mantenimiento de SBOM, dotar de seguridad al CI/CD, mejorar el análisis de vulnerabilidad y reforzar los procesos de gestión de parches.
Impacto sobre los equipos de DevOps
¿Qué significa esto exactamente para quienes desarrollan software nuevo? Para los equipos de DevOps, las numerosas y detalladas obligaciones que establece la CRA implican añadir seguridad tanto a los procesos como a las herramientas. Los equipos de DevOps necesitarán:
- Incorporar generación y gestión de SBOM a todos los PDE (Products with Digital Elements) y actualizarlos continuamente.
- Establecer o mejorar los mecanismos de detección de vulnerabilidad y los canales de información de incidentes, incluida la comunicación rápida con las autoridades correspondientes, como la ENISA.
- Garantizar actualizaciones seguras y ágiles del software, preferiblemente separadas de las actualizaciones de funciones, y automáticas donde sea factible.
- Realizar análisis de riesgo del software, comprobar la integridad del código (p.ej. mediante firmas), encriptar los flujos de datos y conservar la documentación durante más tiempo (hasta 10 años o durante todo el período de soporte al producto).
Estos nuevos requisitos están llevando a muchas organizaciones a modernizar su forma de crear y suministrar software. En lugar de tratar la CRA como otro conjunto de requisitos sin más, los equipos con visión de futuro la ven como una oportunidad de aumentar la seguridad a lo largo de todo el proceso de desarrollo. Esto significa mejorar la gestión de las dependencias, automatizar la generación de SBOM, agilizar la respuesta ante vulnerabilidades y separar las actualizaciones de seguridad de las nuevas funciones. Cuando se hacen bien, estos cambios no solo cumplen los requisitos establecidos sino que también reducen la deuda técnica, mejoran la resiliencia a largo plazo y ayudan a generar confianza entre usuarios y proveedores. En muchos casos, prepararse para la CRA puede ser el impulso que necesitan los equipos para desarrollar un software que sea más seguro y fácil de mantener.
Buscar orientación en la comunidad
Pocas regulaciones han creado tanto urgencia en todo el sector por la necesidad de orientación práctica como la CRA. Las empresas pequeñas y medianas son especialmente vulnerables ya que a menudo carecen de recursos para su cumplimiento a diferencia de sus homólogas con un tamaño mucho mayor.
La buena noticia es que el sector está respondiendo. El Grupo de Trabajo Open Regulatory Compliance (ORC), gestionado por Eclipse Foundation, se ha creado para desarrollar recursos prácticos y colaborar con las agencias públicas para ayudar a las organizaciones a cumplir la normativa, incluida la CRA.
El ORC, que cuenta con el respaldo de una gobernanza neutral, unos vínculos sólidos con los organismos de estandarización (CEN, CENELEC, ETSI) y contacto con los expertos en CRA de la UE, está formado por más de 50 miembros y está creciendo rápidamente. Este grupo diverso reúne a compañías tecnológicas globales como Nokia, Mercedes‑Benz, Microsoft, Red Hat, GitHub y Google, más de 20 fundaciones open source y un creciente número de empresas pequeñas y medianas que colaboran para obtener soluciones prácticas.
Esta iniciativa intersectorial y orientada al open source está ayudando a desarrolladores, empresas y comunidades open source a moverse por este cambiante entorno regulatorio con claridad y confianza. El ORC ofrece una plataforma colaborativa para compartir recursos importantes, como especificaciones, mejores prácticas y materiales de referencia, y sirve como foro de confianza para el diálogo entre reguladores, organismos de estandarización y el sector. Gracias a sus profundos conocimientos y a su compromiso con los valores open source, el ORC ocupa una posición única para marcar un camino práctico y equilibrado hacia el cumplimiento de la CRA.
Es el momento de actuar
Dado que el cumplimiento obligatorio de la CRA empieza a entrar en vigor en septiembre de 2026 y será total en diciembre de 2027, la ventana para la preparación se está estrechando con rapidez. Si bien aún se están ultimando algunos detalles regulatorios, la dirección está clara. Ahora es el momento de coordinar sus flujos de trabajo de desarrollo, añadir cumplimiento a sus canales y contribuir a la comunidad explicando cómo aplicar estas reglas en la práctica.
El ORC es un ejemplo de unión de la comunidad open source para abordar estos retos de manera colectiva. Compartiendo recursos, conocimientos y herramientas prácticas, el ORC ayuda a organizaciones de cualquier tamaño a prepararse para cumplir la CRA sin sacrificar agilidad o innovación.
La CRA es algo más que un conjunto de normas. Para los equipos de DevOps y los profesionales de software es una oportunidad de incorporar la seguridad al trabajo diario. Esto no solo consiste en cumplir los requisitos legales, sino de ayudar a formar un ecosistema de software que aporte más confianza, un mantenimiento más sencillo y que sea mejor para todos.
