La figura del OSS Steward («administrador de software de código abierto») surge en el marco del Cyber Resilience Act (CRA) como respuesta a una realidad clave del ecosistema digital: la creciente integración de software de código abierto en productos con elementos digitales y la necesidad de reforzar su seguridad sin alterar su naturaleza no comercial.
El CRA establece un marco regulatorio estructurado para la gestión de la seguridad y de vulnerabilidades de los productos con elementos digitales que se comercializan en el mercado europeo, reconociendo distintos tipos de actores con responsabilidades diferenciadas. Entre ellos, introduce una nueva categoría: el OSS Steward.
Concepto de productos con elementos digitales
El artículo 3.1 CRA define los productos con elementos digitales como cualquier producto de software o hardware, incluyendo sus soluciones de procesamiento remoto de datos, así como componentes comercializados separadamente:
Artículo 3.1 CRA: «producto con elementos digitales»: un producto de software o hardware y sus soluciones de procesamiento remoto de datos, incluidos los componentes de software o hardware que se comercialicen por separado».
En la práctica, esta categoría abarca la IoT y todo lo que es «Smart» (smartwatch, smart car, juguetes interactivos…), así como software comercializado de forma independiente y plataformas conectadas a estos productos.
Las Draft Guidelines de la Comisión confirman que este concepto debe interpretarse de manera amplia, funcional y tecnológicamente neutra. En particular:
- Sección 2.1.1: el software standalone —aplicaciones, sistemas operativos o software empresarial— puede constituir por sí mismo un producto con elementos digitales cuando se pone a disposición en el mercado.
- Sección 2.1.2: el producto debe entenderse como una unidad funcional completa, incluyendo las remote data processing solutions necesarias para su funcionamiento.
- Sección 2.2: el concepto se conecta con el de «electronic information system», ampliando el alcance a cualquier sistema capaz de procesar, almacenar o transmitir datos digitales.
Por tanto, la categoría abarca una gama muy amplia. En el ámbito del hardware conectado: routers, cámaras de seguridad inteligentes, sistemas de alarma doméstica, lectores de control de acceso y autenticación biométrica, smartwatches, smart TVs y vehículos conectados. En el ámbito del software standalone: sistemas operativos, aplicaciones empresariales, soluciones de antivirus, firewalls de software, o plataformas en la nube que prestan procesamiento remoto de datos necesario para el funcionamiento de un producto. Incluso componentes comercializados por separado —como librerías de software o módulos de firmware— pueden constituir por sí mismos productos con elementos digitales si se ponen a disposición en el mercado.
Concepto de OSS Steward
El artículo 3.14 CRA define formalmente al OSS Steward como:
Artículo 3.14 CRA: «administrador de comunidad de programas informáticos de código abierto»: una persona jurídica, distinta de un fabricante, que tiene la finalidad o el objetivo de dar soporte sistemáticamente y de forma sostenida para el desarrollo de productos específicos con elementos digitales que se consideren programas informáticos libres y de código abierto y estén destinados a actividades comerciales, y que garantiza la viabilidad de dichos productos».*
En definitiva, el OSS Steward es una organización que, sin comercializar directamente el software, desempeña un papel activo y sostenido en su mantenimiento, evolución y estabilidad, especialmente cuando ese software se utiliza en productos o servicios con uso comercial. En la práctica, este rol suele ser asumido por fundaciones y organizaciones sin ánimo de lucro
Requisitos para ser considerado OSS Steward
Para que una entidad sea calificada como OSS Steward bajo el CRA, deben cumplirse los siguientes requisitos de forma acumulativa. Si falta alguno de ellos, la entidad no puede ser considerada OSS Steward a efectos del CRA:
- Persona jurídica: quedan excluidos expresamente los individuos; quedan incluidas fundaciones, asociaciones…
- Distinta del fabricante: el OSS Steward no introduce productos en el mercado ni asume las obligaciones propias del fabricante, en particular las previstas en los artículos 13 y 14 CRA.
- Soporte sistemático y sostenido: debe interpretarse de manera amplia e incluye mantenimiento del código, gestión de contribuciones y gestión de vulnerabilidades. Debe prestarse de forma organizada y estructurada (sistemáticamente) y con continuidad en el tiempo (sostenidamente), excluyendo intervenciones puntuales o periódicas. Las Draft Guidelines precisan que este soporte puede adoptar distintas formas: desde apoyo no técnico —gestión de marca, gobernanza, eventos de comunidad, recaudación de donaciones— hasta soporte en infraestructura técnica —repositorios, control de versiones, claves de firma— e incluso recursos de ingeniería —emplear desarrolladores, coordinar el desarrollo, revisar o fusionar código, gestionar releases o tramitar vulnerabilidades y parches de seguridad—. El mero hosting pasivo del código es insuficiente.
- Software destinado a actividades comerciales: excluye proyectos puramente académicos o personales sin conexión con el mercado.
En la práctica, el rol de OSS Steward es asumido típicamente por fundaciones y organizaciones sin ánimo de lucro. Los ejemplos más representativos son: la Apache Software Foundation (ASF), que gestiona proyectos como Apache HTTP Server, Kafka o Tomcat, ampliamente utilizados en entornos comerciales; la Eclipse Foundation, que coordina cientos de proyectos de herramientas de desarrollo y frameworks; la Linux Foundation, que actúa como steward de proyectos como el kernel de Linux, Kubernetes o el proyecto Sigstore —este último siendo gestionado específicamente a través de la OpenSSF (Open Source Security Foundation), que es parte de la Linux Foundation—; y fundaciones como la Python Software Foundation, la PHP Foundation, la OpenSSL Software Foundation, la Rust Foundation y la Blender Foundation, todas ellas involucradas activamente en la preparación para el cumplimiento del CRA. De hecho, estas siete fundaciones anunciaron en 2024 una colaboración conjunta, liderada desde Bruselas por la Eclipse Foundation, con el objetivo de desarrollar estándares comunes de desarrollo seguro de software para facilitar el cumplimiento del CRA.
Obligaciones del OSS Steward (artículo 24 CRA)
El régimen de obligaciones del OSS Steward es más limitado que el de los fabricantes, pero introduce un elemento clave: un sistema de obligaciones escalonadas en función del nivel de control (Sección 3.3.1 de las Guidelines). Cuanto mayor sea el control efectivo sobre el proyecto, mayor será la responsabilidad; y a la inversa. Este enfoque responde al principio de que «solo eres responsable de lo que controlas».
Las tres obligaciones principales del OSS Steward son:
- Política de ciberseguridad adecuada a su tamaño y estructura, que incluya medidas para el desarrollo seguro del software y la gestión de vulnerabilidades (Art. 24.1 CRA).
- Facilitación de la notificación de vulnerabilidades y participación en el intercambio de información dentro de la comunidad (Art. 24.1 CRA).
- Cooperación con las autoridades competentes, proporcionándoles información clara y colaborando en la mitigación de riesgos. Las obligaciones de notificación formal son más reducidas y solo aplican en determinados supuestos, como las notificaciones de vulnerabilidades del artículo 14.1 (Art. 24.2 CRA).
Las Guidelines también delimitan claramente qué no es un OSS Steward (Sección 3.3.2): no pone el producto en el mercado, no realiza evaluaciones de conformidad, no emite declaraciones UE ni coloca el marcado CE.
La principal diferencia respecto al fabricante reside en que este responde plenamente por un producto que introduce en el mercado, mientras que el OSS Steward tiene una responsabilidad más acotada, centrada en el soporte y la seguridad del software open source.
Acumulación de roles: fabricante y OSS Steward en una misma entidad
Bajo el CRA, los roles no se atribuyen a la empresa en abstracto, sino en función de cada caso concreto. Una misma persona jurídica puede actuar simultáneamente como fabricante respecto de un FOSS y como OSS Steward respecto de otro. Los roles deben analizarse proyecto por proyecto, o incluso versión por versión.
Un supuesto habitual es el de empresas que gestionan un mismo proyecto FOSS con dos versiones:
- Versión comercial → fabricante
- Versión gratuita → steward
La consecuencia es que el CRA exige un enfoque granular de cumplimiento: la entidad debe identificar su rol para cada software o versión, ya que de ello dependerán las obligaciones aplicables en cada caso.
Conclusión: rol y alcance del OSS Steward en el CRA
El OSS Steward se configura como una figura intermedia en el ecosistema del desarrollo de software open source: no es fabricante ni comercializa el software, pero asume un papel activo en su mantenimiento, soporte y viabilidad. Su responsabilidad bajo el CRA en cuanto a la gestión de vulnerabilidades se delimita según el grado de control que ejerce sobre el proyecto.
↳ Descubre más contenidos en nuestra sección Insight.
↳ ¿Quieres estar al tanto de las novedades más relevantes del sector? Síguenos en LinkedIn
