Comparar
Cumplimiento del CRA: requisitos de SBOM y herramientas
El Cyber Resilience Act hace obligatoria una lista de materiales de software para los productos con elementos digitales. Esto es lo que le exige el reglamento, lo que añade la directriz alemana del BSI y cómo se comparan las herramientas de cumplimiento del CRA.
Actualizado el
Cada comparativa explica lo que el otro producto hace bien, en qué se diferencia CRACI y cuándo usaría ambos. Para todas las categorías, consulte todas las comparativas.
Qué exige el CRA a una SBOM
El Cyber Resilience Act, Reglamento (UE) 2024/2847, sitúa la SBOM entre sus requisitos de gestión de vulnerabilidades. Pide menos de lo que muchos suponen: un registro legible por máquina de, como mínimo, las dependencias de nivel superior, que se conserva en la documentación técnica y se muestra a una autoridad cuando lo solicita. Esto es lo que dice el reglamento, pregunta por pregunta.
| Función | Qué dice el CRA | Dónde |
|---|---|---|
| ¿Es obligatoria una SBOM? | Sí. Los fabricantes deben identificar y documentar los componentes de sus productos, «también mediante la elaboración de una nomenclatura de materiales de software» | Anexo I, parte II, punto 1 |
| ¿Qué es una SBOM? | «Un registro formal que contiene los detalles y las relaciones de la cadena de suministro de los componentes incluidos en los elementos de software de un producto con elementos digitales» | Artículo 3, punto 39 |
| ¿En qué formato? | «Un formato de uso común y legible por máquina». La Comisión puede especificar el formato y los elementos mediante actos de ejecución | Anexo I, parte II, punto 1; artículo 13, apartado 24 |
| ¿Con qué profundidad? | «Como mínimo, las dependencias de nivel superior de los productos» | Anexo I, parte II, punto 1 |
| ¿Dónde se incluye? | En la documentación técnica, como parte de la información sobre la gestión de vulnerabilidades | Anexo VII, punto 2, letra b) |
| ¿Tiene que ser pública? | No. «Los fabricantes no deben estar obligados a hacer pública la nomenclatura de materiales de software». Si la comparte con los usuarios, la información para el usuario indica dónde encontrarla | Considerando 77; anexo II, punto 9 |
| ¿Quién puede solicitarla? | Una autoridad de vigilancia del mercado, previa solicitud motivada, para comprobar la conformidad. Las autoridades también pueden solicitar SBOM para una evaluación de dependencias a escala de la UE | Anexo VII, punto 8; artículo 13, apartado 25 |
| ¿Cuánto tiempo hay que conservarla? | La documentación técnica se conserva durante al menos 10 años después de la introducción del producto en el mercado, o durante el periodo de soporte si este es más largo | Artículo 13, apartado 13 |
El reglamento se aplica en su totalidad desde el 11 de diciembre de 2027, y sus obligaciones de notificación se aplican desde el 11 de septiembre de 2026. Para el resto del reglamento, consulte qué exige el CRA.
Más allá del mínimo: BSI TR-03183-2
Hasta que la Comisión especifique el formato mediante un acto de ejecución, la orientación pública más detallada procede de la Oficina Federal de Seguridad de la Información de Alemania (BSI). Su directriz técnica TR-03183-2, versión 2.1.0 de agosto de 2025, es una orientación y no forma parte del reglamento, pero muestra hacia dónde van las expectativas:
- Formato: JSON o XML, válido conforme a CycloneDX 1.6 o superior, o a SPDX 3.0.1 o superior.
- Profundidad: resolución recursiva de dependencias para cada componente del alcance de la entrega, hasta el primer componente que queda fuera de él, incluido.
- Fuente de verdad: la SBOM debe contener «la misma información que está disponible durante el proceso de build», o información equivalente cuando no hay proceso de build.
La directriz también nombra los tipos de SBOM. Una Build SBOM «se crea como parte del proceso de build». Una Analysed SBOM «se crea después del proceso de build analizando artefactos como ejecutables, paquetes, contenedores e imágenes de máquinas virtuales». Esa distinción es la principal diferencia entre las herramientas de esta página.
Dependencias de nivel superior o transitivas
Las dependencias de nivel superior son el mínimo, no el objetivo. Una vulnerabilidad en un paquete transitivo sigue estando en su producto, y el CRA pide a los fabricantes que aborden y corrijan las vulnerabilidades de los componentes que distribuyen. Una SBOM que se detiene en el primer nivel deja esos paquetes fuera de su gestión de vulnerabilidades. La cuestión práctica no es si registrar las dependencias transitivas, sino cómo asegurarse de que el registro coincide con lo que se distribuyó. Consulte dependencias transitivas para saber cómo listarlas y corregir las vulnerables.
Build SBOM o Analysed SBOM
La mayoría de las herramientas de SBOM generan una Analysed SBOM después del build, o gestionan SBOM que producen otras herramientas. CRACI registra una Build SBOM mientras se ejecuta el build. Para comparar generadores y gestores de SBOM, consulte la gestión de SBOM y la comparativa de herramientas de SBOM. Para las herramientas creadas en torno al CRA, consulte la comparativa de herramientas de cumplimiento del CRA.
Dónde encaja CRACI
CRACI registra la SBOM mientras se ejecuta su build de GitHub Actions. Un proxy que entiende de paquetes en el runner registra cada paquete que descargó el job, incluidos los restaurados desde cachés de CI, de modo que la SBOM describe el build que produjo el artefacto y no un escaneo ejecutado en algún lugar cercano. La SBOM de cada job lleva un estado de completitud, y las exportaciones en CycloneDX y SPDX incluyen las dependencias transitivas y la licencia declarada de cada componente.
Después del lanzamiento, CRACI sigue reevaluando las SBOM monitorizadas a medida que aparecen nuevas vulnerabilidades, y envía en su nombre las notificaciones del CRA (alerta temprana, notificación e informe final). La API devuelve SBOM, trazas de red y procedencia. CRACI conserva los datos de build durante 180 días por defecto, con conservación personalizada en Enterprise, así que exporte lo que deba ir en su expediente técnico de 10 años. CRACI automatiza una parte importante de la visibilidad y la evidencia de la cadena de suministro que necesita su proceso del CRA; la evaluación de la conformidad y el expediente técnico siguen correspondiendo al fabricante. Para ver cada requisito del CRA como una hoja de ruta paso a paso, consulte la guía del CRA. Más información sobre la generación de SBOM durante el build, o reserve una demo para ver una SBOM registrada a partir de uno de sus builds.
CRACI comparado con cada herramienta
- CRACI frente a Cybeats Un sistema de registro de SBOM frente a SBOM registradas y monitorizadas.
- CRACI frente a FOSSA Gestión de SBOM frente a build, SBOM y monitorización en uno.
- CRACI frente a Anchore Escanear imágenes frente a registrar y monitorizar builds.
- CRACI frente a Black Duck Escaneo de código, fragmentos y binarios frente a evidencias del build.
- CRACI frente a Sonatype Control de acceso al repositorio y SCA frente a evidencias del build.
- CRACI frente a ONEKEY Análisis binario de firmware frente a evidencias generadas durante el build.
- CRACI frente a Finite State Análisis binario y de SBOM de proveedores frente a un registro del build.
- CRACI frente a Exein Seguridad en tiempo de ejecución en el dispositivo frente a evidencias del build.
Lado a lado
Varias herramientas en una página, para cuando elige una categoría y no un producto concreto.
Preguntas sobre la SBOM del CRA, respondidas
¿Exige el CRA dependencias transitivas en la SBOM?
El reglamento fija el mínimo en «como mínimo, las dependencias de nivel superior de los productos» (anexo I, parte II, punto 1). No menciona las dependencias transitivas, pero un paquete transitivo vulnerable sigue estando en su producto, y el CRA le pide gestionar las vulnerabilidades de los componentes que distribuye. La directriz alemana BSI TR-03183-2 va más allá y pide una resolución recursiva de dependencias.
¿Tiene que ser pública la SBOM del CRA?
No. El considerando 77 indica que los fabricantes no deben estar obligados a hacer pública la SBOM. Forma parte de la documentación técnica, y una autoridad de vigilancia del mercado puede pedirla mediante una solicitud motivada. Si decide compartirla con los usuarios, la información que acompaña al producto debe indicar dónde encontrarla (anexo II, punto 9).
¿Debe una SBOM para el CRA estar en CycloneDX o en SPDX?
El CRA pide «un formato de uso común y legible por máquina» y no nombra ninguno; la Comisión puede especificar el formato mediante un acto de ejecución (artículo 13, apartado 24). CycloneDX y SPDX son las dos opciones habituales. BSI TR-03183-2 v2.1.0 acepta CycloneDX 1.6 o superior y SPDX 3.0.1 o superior, en JSON o XML.
¿Durante cuánto tiempo tengo que conservar la SBOM?
La SBOM forma parte de la documentación técnica, que los fabricantes mantienen a disposición de las autoridades de vigilancia del mercado durante al menos 10 años después de la introducción del producto en el mercado, o durante el periodo de soporte si es más largo (artículo 13, apartado 13).
¿Cuándo se aplican los requisitos de SBOM del CRA?
Las obligaciones de notificación del CRA se aplican desde el 11 de septiembre de 2026, y el reglamento se aplica en su totalidad, incluido el requisito de SBOM del anexo I, desde el 11 de diciembre de 2027.
Otras categorías
Vea CRACI en su propio pipeline
Reserve una demo y repasaremos juntos sus builds, sus SBOM y sus evidencias de cumplimiento.
Reservar una demo