CRA Open Source Steward 2027 – política de ciberseguridad, procedimientos de vulnerabilidad y certificación gubernamental | Word/PDF/Excel

¿Su fundación, asociación u organización impulsa el desarrollo y la gestión a largo plazo de proyectos de código abierto utilizados con fines comerciales? En ese caso, su función puede ser la de open-source software steward según la Ley de Ciberresiliencia de la UE – Reglamento (UE) 2024/2847. El artículo 24 exige, entre otros requisitos, una política de ciberseguridad verificablemente documentada que favorezca el desarrollo seguro, la documentación y la corrección de vulnerabilidades, así como la notificación voluntaria y el intercambio coordinado de información con la comunidad de código abierto.

Diferencia importante con respecto a las plantillas CRA habituales: Un steward es una persona jurídica distinta del fabricante que apoya de forma sistemática y duradera el desarrollo y desempeña un papel fundamental en la continuidad de determinados productos de código abierto destinados a actividades comerciales. Ser mantenedor, escribir código en el tiempo libre o dirigir una asociación no implica automáticamente estar sujeto a esta normativa. Una organización puede ser steward de un proyecto y fabricante de otro. Se debe comprobar esta función para cada producto/versión.

Fechas: La obligación de los fabricantes de presentar informes conforme al artículo 14 entró en vigor el 11 de septiembre de 2026. Las obligaciones específicas y condicionadas de notificación de los stewards conforme al artículo 24.3 comienzan el 11 de diciembre de 2027. ENISA ha verificado esta distinción. Por lo tanto, este paquete está diseñado específicamente para una preparación adecuada, no para afirmar que todos los stewards deben notificar incidentes ya en 2026.

¿Qué actividades se benefician realmente del producto?

El público objetivo son fundaciones de código abierto, asociaciones sectoriales, personas jurídicas sin ánimo de lucro o comerciales que gestionan infraestructuras de repositorios/desarrollo, proporcionan asistencia organizativa o técnica a largo plazo y garantizan la continuidad de un producto FOSS relevante. Un ejemplo es una fundación que gestiona varias bibliotecas y mantiene un proceso documentado de seguridad y divulgación.

**El producto difiere de nuestras plantillas existentes:** CRA Compliance para fabricantes, evaluación de riesgos y SBOM se centra en las obligaciones generales de los productos, y CRA PSIRT – 24/72h y notificación de vulnerabilidades apoya la gestión real de incidentes del fabricante. Este producto está especialmente destinado a la política del artículo 24 del steward, su función de gobernanza y sus limitadas obligaciones de notificación y respuesta ante las autoridades.

¿Qué exige el artículo 24.1 a un steward de software de código abierto?

El artículo 24.1 exige una política de ciberseguridad documentada y verificable que fomente un desarrollo seguro y que los desarrolladores gestionen eficazmente las vulnerabilidades. La política debe cubrir especialmente la detección, documentación, evaluación, gestión y corrección, así como fomentar la notificación voluntaria conforme al artículo 15 y el intercambio de información dentro de la comunidad de código abierto. Debe adaptarse a la estructura jurídica y organizativa real de la organización. No basta con escribir «cumplimos la CRA»: se deben indicar responsabilidades, un contacto de seguridad, el proceso, el número de versión y pruebas reales.

¿Qué ocurre ante una solicitud de las autoridades?

Conforme al artículo 24.2, un steward debe colaborar con las autoridades de control del mercado para reducir los riesgos de seguridad. Ante una solicitud justificada, el steward debe poder entregar la política documentada del punto 1 en papel o electrónicamente, en un idioma que la autoridad pueda comprender fácilmente. El paquete incluye material para verificar al remitente, recopilar los documentos adecuados, proteger los datos sensibles y conservar un acuse de recibo real de la respuesta.

Notificación conforme al artículo 24.3 – dos situaciones distintas

Vulnerabilidad activamente explotada: La referencia al artículo 14.1 se aplica a un steward en la medida en que la organización participe realmente en el desarrollo del producto digital afectado. Incidente grave: Las referencias a los artículos 14.3 y 14.8 se aplican en la situación delimitada en la que el incidente afecte a los sistemas de red e información que el propio steward proporciona para el desarrollo de los productos. Por lo tanto, no todos los errores, ataques contra terceros o interrupciones internas de TI implican automáticamente la obligación de notificación conforme al artículo 24.3.

El responsable debe documentar el momento en que tuvo conocimiento, su función exacta, el incidente, la evaluación jurídica y el canal de notificación real. La Plataforma Única de Notificación (SRP) de ENISA es la vía oficial para las notificaciones aplicables. Las plantillas no pueden enviar ningún mensaje en nombre del cliente ni generar acuses de recibo reales de la SRP. Planifique para cumplir los plazos vigentes y verifique la aplicación jurídica actual con ENISA antes de realizar la notificación.

¿Qué requisitos no se aplican automáticamente a un steward?

La categoría de steward constituye un marco normativo independiente y proporcionado. La organización no debe, únicamente por ser steward, emitir la declaración CE del fabricante, crear un SBOM del fabricante ni cumplir todas las obligaciones técnicas del producto del anexo I de la CRA. La guía de la Comisión Europea distingue expresamente las obligaciones del steward de las del fabricante. Sin embargo, desempeñar una función de fabricante separada en otro proyecto sí cambia la situación.

Índice completo de archivos

Excel con nueve pestañas y ocho medidas administrativas probadas

Las pestañas se denominan Visión general, Proyecto y funciones, Políticas, Vulnerabilidades, Incidentes, Notificación, Asuntos con las autoridades, Medidas y Fuentes y guía. La visión general contabiliza proyectos registrados, evaluaciones de función poco claras, políticas ausentes, vulnerabilidades abiertas, incidentes que requieren investigación, asuntos de notificación poco claros, asuntos con las autoridades sin respuesta y medidas abiertas.

Los ocho valores están en 0 en el archivo original. Partidas de prueba sintéticas separadas dieron el esperado 1 para las ocho medidas. Las tareas de prueba no están incluidas en la versión para clientes. No se realiza ninguna clasificación jurídica, verificación externa, notificación ni aprobación de las autoridades de forma automática.

Cómo utilizar los documentos

1. Inventarie cada proyecto FOSS, editor, organización de apoyo, contexto de licencia y de actividad comercial.
2. Compruebe si cada relación real es steward, fabricante o no está cubierta. Guarde la base y la fuente.
3. Adapte, adopte y versione la política de ciberseguridad con un canal de seguridad concreto y pruebas de código/lanzamiento.
4. Implemente la recepción privada de vulnerabilidades, el triaje, el parcheo, las pruebas de regresión y la divulgación segura a la comunidad.
5. Prepare la evaluación de notificación para el 11 de diciembre de 2027. Distinga la explotación activa de los incidentes graves en la infraestructura de desarrollo del steward.
6. Cree un proceso para solicitudes justificadas de las autoridades y recopile pruebas verificables y protegidas de datos.
7. Actualice el Excel, haga un seguimiento de las medidas y deje que la persona adecuada dé la aprobación manual de cada asunto.

Preguntas frecuentes sobre la CRA y los stewards de código abierto

¿Una asociación sin ánimo de lucro está automáticamente exenta de la CRA?

No. La función jurídica y la actividad lo determinan. Una persona jurídica que apoya sistemáticamente proyectos OSS relevantes puede ser un steward incluso sin ánimo de lucro propio, pero se requiere una evaluación individual por proyecto.

¿Se aplican los mismos requisitos CE a los stewards y a los fabricantes de productos?

No. El artículo 24 comprende obligaciones separadas. Un steward no debe cumplir automáticamente todas las obligaciones CE, SBOM y de producto del fabricante. Si la organización también es fabricante de otro producto, pueden aplicarse otros requisitos allí.

¿Cuándo comienza la obligación del steward de notificar a ENISA?

El artículo 24.3 comienza a aplicarse el 11 de diciembre de 2027. Las obligaciones de los fabricantes conforme al artículo 14 entraron en vigor ya el 11 de septiembre de 2026. No debe confundirse el grupo de las dos fechas.

¿Deben enviarse todos los errores de seguridad a ENISA?

No. Se requiere una evaluación jurídica de, entre otros factores, la explotación activa real, la participación del steward o un incidente grave especial en la infraestructura de desarrollo del steward.

¿Basta con una política de seguridad genérica?

No, si no documenta los procesos reales de seguridad y vulnerabilidades que exige el artículo 24.1, y no puede demostrarse mediante responsabilidades reales, versiones y pruebas de trabajo. La plantilla debe adaptarse a la organización.

¿El paquete genera una notificación real a ENISA?

No. El documento 04 proporciona preparación jurídica y técnica interna. La notificación real debe realizarla una persona autorizada a través del canal oficial adecuado, y solo se introducen acuses de recibo reales.

¿Qué ocurre si las autoridades exigen nuestra política?

Verifique la identidad de la autoridad y qué solicitud jurídica se ha realizado. Utilice el documento 05 para recopilar la política adoptada, la cadena de pruebas real, la decisión de respuesta y el acuse de recibo conforme al artículo 24.2.

¿Están las cinco plantillas de trabajo disponibles en inglés?

No. Las cinco plantillas de trabajo y el Excel están en sueco. Se incluye una guía de usuario en sueco y una Guía de usuario en inglés separada, no una traducción completa de todos los documentos de trabajo.

Fuentes jurídicas, transparencia y control jurídico

Reglamento (UE) 2024/2847 – texto original, artículos 3.14/24/71 · Comisión Europea: CRA y código abierto · Comisión Europea: notificación CRA · ENISA SRP – fechas y notificación · Linux Foundation/OpenSSF – trabajo práctico del steward (no vinculante).

Versión 1.0, control de fuentes jurídicas asistido por IA el 11 de noviembre de 2026. No se ha realizado ninguna revisión jurídica externa, clasificación real de una organización, prueba de penetración, auditoría cibernética, certificado CE ni notificación real a las autoridades. Revise las fuentes ante futuras guías y cambios jurídicos. Entrega en ZIP solo cuando la versión preliminar se publique eventualmente y los archivos de Shopify Digital Products se vinculen por separado.