OpenSSF define tres roles para que el código abierto cumpla la Ley de Resiliencia Cibernética

La Ley de Resiliencia Cibernética (CRA) de la Unión Europea introduce una serie de obligaciones de seguridad para productos que contienen componentes digitales, y la normativa tiene implicaciones de gran alcance para la cadena de suministro de código abierto. Para desmitificar estas obligaciones, la Open Source Security Foundation (OpenSSF) publicó en septiembre de 2026 una vía de preparación que identifica tres roles distintos dentro de la comunidad de código abierto y describe los deberes que cada uno debe cumplir.

Tres roles, tres conjuntos de responsabilidades

La guía separa el ecosistema en (1) mantenedores o contribuyentes, (2) guardianes de código abierto y (3) fabricantes de productos que integran código abierto. Esta taxonomía está diseñada para coincidir con el lenguaje legal del CRA, que diferencia entre las partes que solo aportan código y las que comercializan productos terminados.

La mayoría de los contribuyentes no comerciales quedan fuera de la definición de "fabricante" bajo el CRA, lo que significa que no están automáticamente sujetos a las amplias obligaciones de reporte y remediación de la Ley. Su responsabilidad principal sigue siendo garantizar la calidad y seguridad del código que generan, sin la pesada carga de cumplimiento que recae sobre los actores comerciales.

Qué hace un guardián

Un guardián de código abierto se define como una entidad legal que brinda soporte a largo plazo para proyectos que se utilizan en actividades comerciales. Los guardianes asumen funciones de coordinación, gobernanza y seguridad, como mantener una política de seguridad, gestionar divulgaciones de vulnerabilidades y facilitar la cooperación entre usuarios descendentes.

Aunque el CRA no impone obligaciones específicas a los guardianes hasta el 11 de diciembre de 2027, OpenSSF recomienda que ya implementen contactos de seguridad según buenas prácticas, rutas de escalada y procesos colaborativos. Esta postura proactiva ayuda a los fabricantes descendentes a cumplir sus propios plazos del CRA.

Los fabricantes enfrentan el calendario más estricto

Un fabricante que vende un producto bajo su propia marca es la parte con el conjunto más amplio de obligaciones. Desde el 11 de septiembre de 2026, los fabricantes deben reportar cualquier vulnerabilidad explotada activamente o incidente grave dentro de las 24 horas y emitir una notificación formal a los clientes en un plazo de 72 horas. No cumplir estos plazos puede conllevar multas y restricciones de mercado bajo el CRA.

• Mantener un archivo SECURITY.md actualizado en cada repositorio
• Proveer una dirección de contacto de seguridad dedicada y monitorizada continuamente
• Adoptar herramientas de attestación de cadena de suministro como SLSA, Sigstore, GUAC y OSPS Baseline
• Documentar procedimientos de escalada y compartirlos con los socios descendentes

La guía también subraya la importancia de integrar estas herramientas en pipelines automatizados de CI/CD. Al generar registros criptográficos de procedencia (SLSA) y firmar artefactos (Sigstore), los proyectos pueden demostrar la integridad de sus compilaciones, requisito que los fabricantes deberán evidenciar cuando sean auditados por autoridades europeas.

Dado que una sola organización puede ocupar más de un rol, la guía aconseja un mapeo interno claro de responsabilidades. Por ejemplo, una empresa que tanto contribuye a una biblioteca de código abierto como vende un dispositivo hardware que la incorpora debe tratar la parte de contribución como actividad de mantenedor y la parte del dispositivo como actividad de fabricación, cada una con su propia lista de verificación de cumplimiento.

Las recomendaciones de OpenSSF no constituyen asesoramiento legal, sino que buscan ayudar a la comunidad a alinearse con el espíritu del CRA. La fundación anima a los interesados a consultar a asesores legales para obtener interpretaciones definitivas, sobre todo a medida que evolucionan los mecanismos de aplicación de la Ley.

Para las organizaciones hispanohablantes, el impacto práctico es claro: deben identificar cuál de los tres roles desempeñan, adoptar la documentación y las herramientas de seguridad sugeridas por OpenSSF, y establecer procesos de reporte rápido de vulnerabilidades. Así reducirán el riesgo de sanciones por incumplimiento y contribuirán a una cadena de suministro de código abierto más resiliente en el mercado de la UE.