Requisitos SBOM del CRA: formato, alcance, actualizaciones y conservación
El CRA exige que todo producto con elementos digitales se entregue con una Software Bill of Materials (SBOM) legible por máquina que enumere sus componentes de software y cubra al menos sus dependencias de máximo nivel. La SBOM forma parte de la documentación técnica y debe estar lista para una autoridad de vigilancia del mercado a petición, no presentarse por adelantado.
Resumen
- Todo producto con elementos digitales necesita una SBOM legible por máquina como parte de la evidencia de gestión de vulnerabilidades. Es obligatoria, sin exención por tamaño.
- El mínimo legal son las dependencias de máximo nivel. La cobertura transitiva es una práctica más sólida y lo que esperan la mayoría de los marcos de calidad SBOM.
- Un producto significa un solo cuerpo de evidencia SBOM, aunque el producto se construya a partir de muchos repositorios o componentes.
- Mantén la SBOM actualizada durante el período de soporte, especialmente tras versiones, cambios de componentes y decisiones sobre vulnerabilidades.
- Conserva la SBOM con la documentación técnica durante al menos 10 años, o el período de soporte si es mayor.
- Las obligaciones de notificación de vulnerabilidades comienzan el 11 de septiembre de 2026; la aplicación plena del CRA llega el 11 de diciembre de 2027.
¿Qué es un SBOM?
Una Software Bill of Materials (SBOM) es un inventario estructurado del software que contiene un producto: bibliotecas, frameworks, paquetes del sistema operativo y las dependencias entre ellos. Para el CRA es el registro que usaría una autoridad de vigilancia del mercado para comprobar cuáles de tus componentes están afectados por una vulnerabilidad notificada, por eso debe ser legible por máquina y no un documento en prosa.
Qué exige el CRA en una SBOM
La obligación de la SBOM tiene dos capas prácticas: qué debe cubrir el inventario y dónde debe estar la evidencia dentro del expediente técnico.
¿Qué componentes debe cubrir la SBOM?
Los fabricantes deben identificar y documentar los componentes y las vulnerabilidades de sus productos con elementos digitales, y elaborar una SBOM en un formato comúnmente utilizado y legible por máquina que cubra al menos las dependencias de máximo nivel del producto.
Esto significa que:
- La SBOM debe ser legible por máquina y estar en un formato comúnmente utilizado. Un PDF o una hoja de cálculo puede ayudar a revisar el inventario, pero no sustituye al archivo SBOM.
- Debe cubrir como mínimo las dependencias de máximo nivel. La cobertura transitiva va más allá del mínimo, y es la mejor base para monitorizar vulnerabilidades.
Todo producto con elementos digitales introducido en el mercado de la UE debe tener una SBOM legible por máquina. No existe exención ni umbral de tamaño por debajo del cual desaparezca la obligación. El nivel de detalle que documentas es proporcional al riesgo del producto, pero el deber de elaborar una SBOM no lo es.
Por ahora las reglas solo piden un formato comúnmente utilizado y legible por máquina que cubra al menos las dependencias de máximo nivel. No nombran un formato concreto ni una lista fija de campos. Ese mínimo puede elevarse: el CRA deja margen para que la Comisión establezca más adelante un formato y un conjunto de campos exactos para la SBOM. Elegir ahora un formato bien soportado, CycloneDX o SPDX, y capturar más que el mínimo es la mejor protección frente a un formato prescrito en el futuro.
Dónde encaja la SBOM en el expediente técnico
La SBOM forma parte de tu documentación técnica, archivada junto al resto de la evidencia de gestión de vulnerabilidades: la política de divulgación coordinada de vulnerabilidades, una dirección de contacto para notificaciones y la forma de distribuir actualizaciones de manera segura. No la presentas por adelantado. Debe existir cuando el producto se introduce en el mercado de la UE y estar lista para una autoridad de vigilancia del mercado si lo solicita de forma motivada.
En la práctica, la SBOM debe permitir rastreo de vulnerabilidades a nivel de componente, comprobaciones de proveedor y origen, revisión de licencias y planificación de fin de vida.
¿Cuántas SBOM necesita un producto?
Un producto suele construirse a partir de muchos repositorios y componentes, y cada uno puede emitir su propia SBOM. El CRA fija la unidad de evidencia en el producto, no en el repositorio ni en la compilación.
El CRA define la SBOM como un registro de los componentes del software de un producto y cómo se relacionan, y espera que ese registro cubra al menos las dependencias de máximo nivel del producto. El objeto de evidencia es el producto que introduces en el mercado de la UE, identificado por producto y versión. Un producto ensamblado a partir de diez repositorios no queda cubierto por diez SBOM de componentes sueltas que nada vincula entre sí. Debes evidencia SBOM que represente el producto tal como se entrega.
El CRA no obliga a un único archivo físico, ni prohíbe conservar SBOM de componentes. Dos vías funcionan, siempre que el resultado sea legible por máquina, esté a nivel de producto y cubra al menos las dependencias de máximo nivel:
- Componer. Conserva las SBOM de componentes como documentos separados y vincúlalas en una SBOM de producto, usando componentes de ensamblaje de CycloneDX con referencias BOM-Link, o relaciones SPDX con referencias a documentos externos.
- Fusionar. Aplana cada componente en un único documento CycloneDX o SPDX para la versión de producto.
Como la SBOM debe capturar cómo se relacionan los componentes, una lista plana de nombres de paquetes no basta por sí sola. Elijas la vía que elijas, la SBOM debe mostrar cómo los componentes dependen unos de otros y se contienen entre sí, algo que aportan tanto los grafos de dependencias de CycloneDX como las relaciones de SPDX. Para la mecánica de los formatos, consulta CycloneDX vs SPDX.
¿Quién debe recibir la SBOM?
La SBOM es material del expediente técnico, no un documento público. El CRA no exige que la publiques, y la única parte que puede reclamarla es una autoridad de vigilancia del mercado, que puede pedirla mediante una solicitud motivada cuando necesite comprobar tu conformidad. Compartir la SBOM con los usuarios es opcional. Si decides compartirla con ellos, tendrás que indicarles dónde encontrarla.
| Quién | Qué espera el CRA |
|---|---|
| Autoridad de vigilancia del mercado | Puede solicitar la SBOM mediante una solicitud motivada, cuando sea necesaria para comprobar la conformidad |
| Usuarios y público | Sin deber de publicarla ni entregarla; compartirla es decisión tuya |
| Importadores y distribuidores | Sin derecho a la SBOM en sí; deben poder facilitar tu documentación técnica a las autoridades a petición |
| Integradores que construyen sobre tu producto | Cuando tu producto está destinado a integrarse en el suyo, les das la información que necesitan para cumplir sus propias obligaciones, que no es automáticamente la SBOM completa |
No publiques la SBOM ni la envíes a los usuarios por defecto. Una SBOM es un mapa preciso de tus componentes y versiones, justo lo que quiere un atacante, y el CRA no te obliga a entregarla de forma generalizada. Facilítala a una autoridad de vigilancia del mercado cuando lo solicite de forma motivada, y a los clientes empresariales que construyen sobre tu producto, bajo acuerdo de confidencialidad o contrato, porque la necesitan para montar su propia SBOM a nivel de producto y cumplir sus obligaciones. Lleva un registro de quién recibió cada versión.
Qué debe incluir el SBOM
Separa el mínimo legal del CRA de los campos que hacen útil la SBOM en flujos reales de vulnerabilidades. El reglamento fija el mínimo. TR-03183, las herramientas CycloneDX/SPDX y las expectativas de clientes suelen elevar el listón operativo.
| Área | Mínimo CRA | Implementación sólida |
|---|---|---|
| Formato | Comúnmente utilizado y legible por máquina | CycloneDX JSON/XML o SPDX JSON/tag-value, generado por herramientas de build |
| Alcance | Al menos dependencias de máximo nivel | Dependencias directas y transitivas, bibliotecas internas, firmware y paquetes del sistema operativo cuando proceda |
| Componentes | Componentes presentes en el producto | Nombre, versión, proveedor, PURL o CPE, hash y datos de relación |
| Vulnerabilidades | Componentes y vulnerabilidades identificados y documentados | Estado actual de vulnerabilidad, decisión VEX o de explotabilidad, referencia de corrección y fecha de revisión |
| Evidencia técnica | SBOM incluida con la evidencia del proceso de gestión de vulnerabilidades | Referencia estable de archivo por versión de producto, herramienta de generación, fecha de generación y resultado de validación |
| Acceso de autoridades | Disponible cuando sea necesaria ante una solicitud motivada de vigilancia del mercado | Archivo seguro con responsable de recuperación, controles de integridad y cobertura del período de soporte |
El CRA te exige identificar y documentar las vulnerabilidades, pero eso no significa que los datos de vulnerabilidad o VEX tengan que estar dentro del propio archivo SBOM. Llevarlos ahí es buena práctica, no un mínimo. Para los requisitos de campo que van más allá de esta lista (identificadores PURL, valores hash, metadatos del documento), consulta cómo BSI TR-03183 amplía el CRA. Para comparar las herramientas de CycloneDX y SPDX, consulta CycloneDX vs SPDX.
Cómo es un resumen de SBOM del expediente técnico
Un buen expediente técnico acompaña la SBOM legible por máquina con un breve registro de resumen. El resumen es una portada para la revisión humana. La SBOM real es el archivo CycloneDX o SPDX adjunto al que apunta.
RESUMEN DE SBOM DEL EXPEDIENTE TÉCNICO
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.6
Generated: 2027-01-15
Tools: Syft (generación), Trivy (escaneo)
ARCHIVO SBOM:
sbom-ssp3000-v2.4.1.json (adjunto, legible por máquina)
RESUMEN DE COMPONENTES:
-------------------------------------------------------------
Total Components: 127
Direct Dependencies: 23
Transitive Dependencies: 104
By Type:
Libraries: 98
Frameworks: 12
Operating System: 1 (FreeRTOS)
Firmware Modules: 16
ESTADO DE VULNERABILIDADES EN LA EVALUACIÓN:
-------------------------------------------------------------
Scan Date: 2027-01-17
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (aceptadas, ver abajo)
VULNERABILIDADES ACEPTADAS:
CVE-2026-15432 (Medium): libexpat 2.5.0
Status: No explotable en nuestra configuración
Justification: Funcionalidad no habilitada, ruta de código no alcanzable
Review Date: 2027-04-15
-------------------------------------------------------------
Cuándo actualizar tu SBOM
La SBOM no es un documento único. Tu documentación técnica debe elaborarse antes de introducir el producto en el mercado y mantenerse actualizada, cuando proceda, al menos durante el período de soporte. El período de soporte refleja cuánto tiempo se prevé que el producto esté en uso, y es de al menos cinco años salvo que realmente se prevea un uso menor.
Revisa o regenera la SBOM cuando:
| Desencadenante | Qué cambia | Acción práctica |
|---|---|---|
| Nueva versión de firmware o software | Nuevo artefacto de compilación | Regenerar la SBOM para esa versión de producto |
| Parche de seguridad | Cambia una versión de componente | Actualizar componentes afectados y archivar la nueva SBOM |
| Vulnerabilidad descubierta y evaluada | Cambia el estado VEX o de explotabilidad | Actualizar estado de vulnerabilidad y evidencia de decisión |
| Componente añadido, eliminado o sustituido | Cambia el grafo de dependencias | Regenerar y validar la SBOM |
| Cambio de diseño relevante para seguridad | Cambian componentes o arquitectura | Regenerar la SBOM y actualizar referencias del expediente técnico |
| Cambio de normas o especificaciones aplicadas | Cambian metadatos de cumplimiento | Revisar metadatos y evidencias vinculadas |
Revisiones periódicas. El CRA no fija un intervalo de revisión concreto. Estas cadencias son una base práctica:
| Cadencia | Alcance |
|---|---|
| Trimestral | SBOM y estado de vulnerabilidades |
| Anual | Revisión completa del expediente técnico |
| Antes del fin del período de soporte | Congelación final de la documentación |
Cada compilación debe producir un artefacto SBOM actualizado, para que la evidencia siga el ritmo de lo que entregas. Consulta los errores más comunes en SBOM para ver qué sale mal cuando los equipos omiten la automatización.
Cuánto tiempo conservar la evidencia SBOM
Conserva la SBOM con la documentación técnica durante al menos 10 años después de introducir el producto con elementos digitales en el mercado, o durante el período de soporte si este es más largo. La misma regla de conservación se aplica a la documentación técnica y a la declaración UE de conformidad. Esto trata de conservar la documentación. Es distinto del deber de mantener disponibles las propias actualizaciones de seguridad, que corre sus propios diez años desde que se publica cada actualización.
Para una línea de productos vendida durante un período prolongado, conserva evidencia de las versiones y unidades introducidas en el mercado. No trates la fecha del primer lanzamiento como el final práctico de la obligación de evidencia mientras se sigan suministrando unidades o versiones posteriores.
| Hito | Fecha de ejemplo |
|---|---|
| Producto introducido por primera vez en el mercado | Marzo de 2027 |
| Última unidad introducida en el mercado | Diciembre de 2030 |
| Cobertura práctica de evidencia | Hasta diciembre de 2040 o más si lo exige el período de soporte |
El plazo corre desde la última unidad introducida en el mercado, así que diciembre de 2030 más diez años llega al menos hasta diciembre de 2040, y más si el período de soporte se extiende más allá. Conserva la SBOM en un lugar seguro y con copias de seguridad, con protección de integridad, para poder recuperar y suministrar la versión correcta ante una solicitud motivada.
Fechas y aplicación
La aplicación plena del CRA comienza el 11 de diciembre de 2027. La obligación de notificación de vulnerabilidades empieza antes, el 11 de septiembre de 2026. Esa fecha anterior no es un plazo separado para presentar la SBOM, pero exige que sepas rápidamente qué versiones de producto y componentes están afectados por una vulnerabilidad o incidente notificable. Para productos introducidos en el mercado de la UE después de la aplicación plena, la SBOM forma parte de la base de evidencia detrás de la evaluación de la conformidad, la declaración UE de conformidad y el marcado CE. Para el flujo de notificación, consulta notificación de vulnerabilidades e incidentes bajo el CRA. Para el calendario general del CRA, consulta qué es el CRA; para la tabla de sanciones, consulta sanciones y aplicación del CRA.
Preguntas frecuentes
¿El CRA exige un SBOM legible por máquina o se acepta un PDF?
La SBOM debe estar en un formato comúnmente utilizado y legible por máquina. Un PDF o una hoja de cálculo puede acompañar el archivo para revisión humana, pero no sustituye a la SBOM. CycloneDX o SPDX serializado como JSON o XML es la vía práctica.
¿El CRA exige un SBOM para componentes de código abierto?
Sí. Los componentes de código abierto siguen siendo componentes presentes en el producto, así que deben aparecer en la SBOM con su versión e identificador. El CRA también espera que ejerzas la diligencia debida sobre los componentes de terceros que integras, incluido el software de código abierto que no se te haya comercializado en el transcurso de una actividad comercial, y que notifiques cualquier vulnerabilidad que encuentres en un componente integrado, también de código abierto, a quien lo mantiene.
¿Cuándo debe presentarse el SBOM: al introducir el producto en el mercado o a petición?
La SBOM normalmente no se presenta de forma proactiva. Debe formar parte de la documentación técnica, estar lista y disponible para las autoridades de vigilancia del mercado ante una solicitud motivada, y existir cuando el producto se introduce en el mercado de la UE.
¿Cuáles son los elementos mínimos de la NTIA y satisfacen los requisitos del CRA?
Los elementos mínimos de la NTIA (nombre del proveedor, nombre del componente, versión, identificadores únicos, relaciones de dependencia, autor del SBOM y marca de tiempo) son un punto de partida razonable. Por sí solos no responden a todas las preguntas de evidencia del CRA ni a todas las expectativas de calidad de TR-03183. Para trabajo CRA, valida el archivo generado contra el formato elegido, registra el estado de vulnerabilidades y completa campos más ricos como PURL/CPE, hashes y datos de relación cuando tu marco de calidad lo exija.
¿Puedo reutilizar SBOM de proveedores para cumplir el CRA?
Parcialmente. Los SBOM de proveedores son entradas válidas para los componentes que suministran, pero sigues debiendo una SBOM del producto tal como se introduce en el mercado. Eso implica consolidar las SBOM de proveedores con tus componentes propios y dependencias de compilación en evidencia a nivel de producto, como se explica más arriba en cuántas SBOM necesita un producto. Trata las SBOM de proveedores como materia prima, no como el artefacto de cumplimiento terminado.