El Cyber Resilience Act de la Unión Europea no convierte automáticamente a cada mantenedor voluntario en fabricante de productos. El reto de ingeniería consiste en identificar la función real de cada organización en la cadena y hacer que la respuesta a vulnerabilidades funcione entre quienes desarrollan y quienes distribuyen software.
Alcance: este es un resumen práctico para ingeniería, no asesoramiento jurídico. La clasificación depende de los hechos: quién comercializa el producto en la UE, si existe actividad comercial, quién responde por el producto y qué apoyo continuo presta una organización. Para analizar una entidad o un producto concretos, consulta a profesionales jurídicos cualificados.
El CRA regula los productos con elementos digitales comercializados en el mercado de la UE y asigna a los fabricantes las principales obligaciones de conformidad del producto. El software de código abierto comercializado como parte de una actividad comercial puede entrar en el ámbito; el desarrollado o suministrado fuera de esa actividad recibe un tratamiento distinto. Aportar código a un proyecto abierto, sin responsabilidad sobre el software, no convierte automáticamente a una persona en fabricante.
La ley define al steward de software de código abierto como una persona jurídica, distinta del fabricante, que presta apoyo sistemático y sostenido a software libre y abierto específico destinado a actividades comerciales, y garantiza su viabilidad. Es una función organizativa concreta, no un sinónimo de cualquier mantenedor individual. Una empresa que integra una biblioteca en un producto que comercializa puede tener obligaciones como fabricante respecto de ese producto, aunque los componentes procedan de una comunidad.
Estas funciones se relacionan. Un steward puede coordinar la respuesta upstream a una vulnerabilidad compartida, mientras el fabricante downstream sigue siendo responsable de evaluar su producto, identificar versiones afectadas, informar a los usuarios y cumplir las notificaciones que correspondan. Incluir una dependencia en la SBOM no transfiere la responsabilidad, y una corrección upstream no demuestra que el producto distribuido esté reparado.
A 28 de septiembre de 2026, los materiales de implementación de la Comisión Europea indican que las obligaciones de notificación del Artículo 14 para fabricantes se aplican desde el 11 de septiembre de 2026. Las obligaciones correspondientes de los stewards comienzan el 11 de diciembre de 2027, cuando el CRA se aplica con carácter general. No copies la fecha del fabricante en una lista para mantenedores como si todos los proyectos tuvieran el mismo deber.
| Fecha | A quién / qué aplica | Implicación técnica |
|---|---|---|
| 11 de septiembre de 2026 | Empiezan las notificaciones del Artículo 14 para fabricantes. | Los equipos de producto deben evaluar, encaminar y notificar vulnerabilidades explotadas activamente e incidentes graves incluidos en el ámbito. |
| 11 de diciembre de 2027 | Aplicación general del CRA; comienzan las notificaciones para stewards. | Las organizaciones que encajen en la definición deben contar con una política documentada y un proceso funcional para vulnerabilidades. |
| 11 de diciembre de 2027 | Aplicación general de las obligaciones del CRA para productos. | Los fabricantes necesitan evidencias de conformidad por producto, evaluación de riesgos y procesos de soporte y actualización. |
Para los fabricantes, el Artículo 14 fija varias etapas, entre ellas una alerta inicial en 24 horas y una notificación en 72 horas para las vulnerabilidades explotadas activamente y los incidentes graves cubiertos. No son plazos genéricos de respuesta para todos los mantenedores de código abierto. Define quién determina la aplicabilidad y quién presenta la notificación; utiliza la plataforma europea cuando corresponda.
Estructura el registro de vulnerabilidad: identificador, informante, fecha de recepción, rangos afectados, reproducción, justificación de gravedad, evidencia de explotación, partes coordinadoras, commits, versiones corregidas, avisos y evidencia de cierre. Restringe el acceso mientras se coordina la corrección; una vez publicada, conserva los enlaces necesarios para reconstruir qué cambió y qué productos se vieron afectados.
El Artículo 24 establece que los stewards documenten una política verificable de ciberseguridad para fomentar el desarrollo seguro y la gestión eficaz de vulnerabilidades, promuevan reportes voluntarios, traten y corrijan los problemas detectados, compartan información pertinente y cooperen con las autoridades de vigilancia del mercado. La política debe considerar la naturaleza y los acuerdos de la organización. No exige crear un departamento corporativo alrededor de un proyecto pequeño.
Para una biblioteca o componente mantenido, crearía un proceso de seguridad ligero con las herramientas existentes: formulario o correo privado, gestor de incidencias con acceso restringido, índice de SBOM y dependencias por release, CI que registre pruebas y procedencia, y un feed firmado de avisos. Un servicio sencillo podría correlacionar paquetes y rangos de versiones con los manifiestos de consumidores, y abrir tareas para cada responsable de producto.
El objetivo es la trazabilidad, no prometer que conocemos a todos los consumidores. Mediría el tiempo hasta confirmar el reporte, precisar las versiones afectadas, publicar una corrección y recibir confirmación downstream. Publicaría claramente las limitaciones. La clasificación legal y las decisiones de notificación corresponden a la organización que tiene la función jurídica pertinente.
| Fallo | Señal | Control |
|---|---|---|
| Se considera steward a cada mantenedor | La política asigna obligaciones a personas sin revisar los criterios de persona jurídica. | Documenta las premisas sobre la función y solicita una evaluación jurídica. |
| Se confunde el parche upstream con la corrección del producto | Se cierra el aviso mientras productos distribuidos conservan versiones vulnerables. | Rastrea la dependencia hasta la versión del producto y exige una decisión downstream. |
| El buzón de reportes no tiene responsable | Los reportes esperan durante ausencias o aparecen en incidencias públicas. | Prueba el enrutamiento principal/suplente y alerta sobre acuses pendientes. |
| La SBOM existe, pero no se puede consultar | El equipo no identifica releases afectados dentro del plazo de notificación. | Guarda SBOM legibles por máquina por digest inmutable y automatiza la búsqueda por componente y versión. |
| El reloj del incidente empieza tarde | Se pierde la hora del primer conocimiento entre soporte, seguridad y legal. | Persiste la hora inicial y escala de inmediato los posibles eventos regulatorios. |
El CRA regula la seguridad de productos y distingue funciones; no convierte a cada persona que contribuye a un repositorio en fabricante. Los stewards de código abierto tienen deberes específicos cuando cumplen la definición legal, y los fabricantes siguen respondiendo por sus productos. Empieza por los mecanismos compartidos: recepción privada, triaje reproducible, trazabilidad de dependencias y releases, correcciones coordinadas y traspasos claros a los consumidores. Después valida la función y los plazos de cada organización con fuentes oficiales y asesoramiento jurídico.
Nota editorial: Este artículo resume materiales de la Unión Europea para uso técnico, con referencia al 28 de septiembre de 2026. No es asesoramiento jurídico ni determina si una entidad o producto concreto está sujeto al CRA.