Elaborar documentación técnica a petición
- Se aplica a
- Open-source steward
- Citas de fuentes
- Art. 24(4)
- Clases de productos
- DefaultImportant — Class IImportant — Class IICritical
Lenguaje claro
A diferencia de los fabricantes, los administradores de OSS no necesitan preparar de forma proactiva la documentación técnica completa del Anexo VII. Sin embargo, si una autoridad de vigilancia del mercado lo solicita, deben poder facilitar documentación técnica sobre su componente OSS que cubra sus propiedades de seguridad, las vulnerabilidades conocidas y las prácticas de desarrollo. La obligación más ligera para los administradores de OSS refleja el modelo de código abierto, pero la información subyacente debe estar disponible.
Texto jurídico
El artículo 24(4) del Reglamento (UE) 2024/2847 establece que, a petición de una autoridad de vigilancia del mercado, los administradores de software de código abierto elaborarán y mantendrán actualizada la documentación técnica a que se refiere el Anexo VII para los componentes de software de código abierto que administran.
La documentación se pondrá a disposición de la autoridad de vigilancia del mercado cuando se solicite y deberá permitir evaluar el cumplimiento de los requisitos aplicables del presente Reglamento.
Requisitos clave
- Obligación a petición: a diferencia de los fabricantes, los administradores de OSS no necesitan mantener de forma proactiva la documentación del Anexo VII, pero deben elaborarla cuando se solicite
- Alcance del Anexo VII: la documentación debe ser suficiente para permitir la evaluación de la conformidad; abarca las propiedades de seguridad, el proceso de desarrollo y la gestión de vulnerabilidades
- Mantenimiento actualizado: una vez elaborada, la documentación debe mantenerse actualizada para que siga siendo exacta
- Producción oportuna: debe facilitarse en un plazo razonable tras la solicitud
Documentación que puede necesitar
- Inventario de los componentes OSS administrados y sus propiedades relevantes para la seguridad
- Notas de arquitectura de seguridad, modelos de amenazas o documentación de diseño equivalente
- Base de datos de vulnerabilidades o lista de problemas conocidos de los componentes
- Registros de las prácticas de desarrollo seguro aplicadas