SBOM y registros de componentes de la CRA
Sytance · Actualizado
La CRA utiliza la visibilidad de los componentes como parte de la gestión de vulnerabilidades. El anexo I exige a los fabricantes identificar y documentar vulnerabilidades y componentes, entre otras cosas mediante la elaboración de una lista de materiales de software.
Requisito del anexo I
identificar y documentar las vulnerabilidades y los componentes que contienen los productos con elementos digitales, también mediante la elaboración de una lista de materiales de software en un formato legible por máquina y de uso común que abarque, como mínimo, las dependencias de nivel superior de los productos;
Reglamento (UE) 2024/2847, anexo I, parte II, punto 1
La SBOM forma parte de un registro de componentes más amplio. Ayuda al fabricante a comprender qué componentes contiene el producto y qué vulnerabilidades pueden afectarlos.
Qué hay que distinguir
SBOM
Registro de componentes de software legible por máquina. El anexo I exige, como mínimo, las dependencias de nivel superior.
Componente integrado
Un componente contenido en el producto puede generar obligaciones de gestión de vulnerabilidades para el producto terminado.
Componente de terceros
El artículo 13 exige diligencia debida cuando se integran componentes de terceros en el producto.
Acceso de las autoridades
El anexo VII contempla el acceso a la SBOM previa solicitud motivada cuando sea necesario para verificar el cumplimiento del anexo I.
Ejemplo: registro de componentes trazable
El siguiente registro ficticio describe una dependencia directa de software en una versión del firmware de un controlador. Ilustra información de ingeniería útil; los campos no son un esquema adicional impuesto por la CRA.
- Producto: firmware del controlador 1.2.0, compilación de lanzamiento 120; inventario creado a partir de la compilación publicada y de sus datos de dependencias.
- Componente: example-parser 2.4.0, suministrado por el proyecto ficticio Example Components; dependencia directa del firmware.
- Identidad y origen: identificador del paquete, revisión exacta del código fuente o referencia del proveedor, y un resumen criptográfico real del artefacto suministrado.
- Uso: el componente analiza un archivo de configuración cargado a través de una interfaz de mantenimiento autenticada. Registre las opciones de compilación pertinentes y el componente que lo invoca.
- Pruebas: enlace la SBOM legible por máquina y los registros de compilación o del proveedor utilizados para verificar esta entrada. Conserve el inventario de la versión anterior cuando cambie el componente.
El nombre y la versión de un componente pueden ayudar a encontrar posibles vulnerabilidades. Determinar si afectan al producto requiere un análisis adicional: si se incluye el código vulnerable, si se ejecuta la función afectada, qué entrada puede alcanzar un atacante y qué controles son pertinentes. Una coincidencia no resuelta sigue investigándose; no demuestra que el producto no esté afectado.
Una declaración como «no afectado» debe identificar la versión del producto, la vulnerabilidad, el motivo técnico y las pruebas que la respaldan. Vuelva a comprobarla si cambian las opciones de compilación, la versión del componente, la interfaz o un supuesto de implementación.
Vínculo con la documentación técnica
El anexo VII incorpora a la documentación técnica la información sobre componentes y SBOM. También solicita información sobre el proceso de gestión de vulnerabilidades, la política de divulgación coordinada, el contacto para notificaciones y la distribución segura de actualizaciones.
El proceso se explica en Registros de gestión de vulnerabilidades y prEN 40000-1-3 Gestión de vulnerabilidades.
Estado del formato
El anexo I exige una SBOM de uso común y legible por máquina que abarque, como mínimo, las dependencias de nivel superior. El artículo 13(24) también permite a la Comisión especificar su formato y sus elementos mediante un acto de ejecución, teniendo en cuenta las normas europeas o internacionales y las buenas prácticas. Por ello, al elegir un formato hay que distinguir entre la base establecida por el Reglamento y los requisitos de ejecución que resulten aplicables.
- Una lista de componentes en PDF no cumple el requisito de formato legible por máquina de una SBOM.
- La SBOM identifica componentes; la gestión de vulnerabilidades también requiere analizar el impacto, aplicar correcciones y comunicarlo.
- El anexo VII prevé el acceso a la SBOM a petición de una autoridad; no establece una obligación general de publicarla.