La mayoría de los fabricantes descubren las deficiencias en su SBOM durante la primera revisión de cumplimiento, no antes. Para entonces, el plazo de aplicación está más cerca y el alcance de la remediación es mayor. La obligación del SBOM en el anexo I del CRA es sencilla de enunciar: formato legible por máquina, dependencias de máximo nivel como mínimo, almacenado en tu expediente técnico del anexo VII. Lo que complica la vida a los fabricantes es la frase «como mínimo». Este artículo cubre seis errores que generan la mayor brecha entre un SBOM formal y uno que resistiría una auditoría de una autoridad de vigilancia del mercado.
Resumen
- Detenerse en las dependencias directas deja las vulnerabilidades transitivas fuera del SBOM
- Un SBOM creado una sola vez queda obsoleto en cuestión de semanas a medida que se publican nuevos CVE
- La ausencia de valores hash e identificadores PURL no supera los controles de calidad de BSI TR-03183
- La creación manual del SBOM no satisface la obligación de actualización continua del CRA
- Los componentes internos y propietarios deben aparecer junto a las bibliotecas de código abierto
- Los SBOM de los proveedores son materia prima, no un artefacto de cumplimiento terminado
Errores de un vistazo
| # | Error | Por qué falla | Solución |
|---|---|---|---|
| 1 | Detenerse en las dependencias directas | Los CVE transitivos son invisibles para los escáneres | Archivos de bloqueo más análisis del artefacto compilado |
| 2 | Tratar el SBOM como un documento puntual | Queda obsoleto en semanas ante nuevos CVE | Generación en CI/CD en cada compilación |
| 3 | Campos de identidad incompletos | Sin concordancia de CVE, TR-03183 falla | Versión exacta, SHA-256, PURL, proveedor |
| 4 | Generación manual | No sigue el ritmo de las publicaciones | Automatización con Syft, Trivy o cdxgen |
| 5 | Omitir componentes internos o propietarios | El anexo I no establece tal distinción | IDs internos, tu organización como proveedor, SHA-256 |
| 6 | Tratar los SBOM de los proveedores como artefacto final | El fabricante asume la obligación del anexo I | Consolida en un único SBOM del producto |
Error 1: detenerse en las dependencias directas
El anexo I, parte II, punto 1, establece el mínimo legal en las dependencias de máximo nivel. Muchos fabricantes se detienen exactamente ahí. El problema no es cumplir el mínimo legal. El problema es el riesgo que ese mínimo deja fuera de tu visibilidad. Una dependencia transitiva (una biblioteca de la que depende tu dependencia directa) es igual de explotable que una directa. Cuando se publica un CVE contra un paquete transitivo que tu SBOM no registra, no puedes identificarlo, no puedes notificarlo y estás expuesto sin saberlo.
Tu producto
+-- Biblioteca A (directa) ← mínimo legal, suelo del anexo I
| +-- Biblioteca B (transitiva) ← fuera del SBOM, invisible para los escáneres de vulnerabilidades
| \-- Biblioteca C (transitiva) ← fuera del SBOM, invisible para los escáneres de vulnerabilidades
\-- Biblioteca D (directa) ← mínimo legal, suelo del anexo I
La solución pasa por las herramientas y su configuración. Usa archivos de bloqueo y analiza los artefactos compilados, no solo el código fuente. Trivy, Syft y cdxgen admiten la captura de dependencias transitivas cuando se configuran correctamente. BSI TR-03183 considera la cobertura transitiva completa como el indicador de calidad que separa un SBOM mínimamente conforme de uno genuinamente útil. Consulta los niveles de calidad de BSI TR-03183 para conocer los requisitos de cada campo en cada nivel.
Error 2: tratar el SBOM como un documento puntual
Un SBOM generado una sola vez y nunca actualizado crea una falsa sensación de seguridad. Cada día se publican nuevos CVE contra componentes que ya están en tu producto. Un SBOM que era exacto en el momento de la compilación queda obsoleto en cuestión de semanas. La obligación del anexo I del CRA es continua: el SBOM debe reflejar el estado actual del producto durante todo el período de soporte.
Desencadenantes de actualización obligatorios bajo el CRA:
| Desencadenante | Qué cambia | ¿Requiere actualización del SBOM? |
|---|---|---|
| Nueva versión de firmware o software | Nuevo artefacto de compilación | Sí, regeneración completa |
| Publicación de parche de seguridad | Versión del componente actualizada | Sí, componentes afectados |
| Vulnerabilidad descubierta y abordada | Estado VEX o de explotabilidad | Sí, campos VEX |
| Componente añadido, eliminado o sustituido | Grafo de dependencias | Sí, regeneración completa |
| Cambio de diseño que afecta a la seguridad | Componentes y arquitectura | Sí, regeneración completa |
La solución es la integración en CI/CD. Cada compilación debe producir un artefacto SBOM actualizado almacenado junto a la versión publicada. Una exportación manual no puede seguir el ritmo de la frecuencia de actualización que exige el CRA. Consulta los requisitos de SBOM del CRA para ver la lista completa de desencadenantes y el plazo de conservación de 10 años.
A partir del 11 de septiembre de 2026, debes notificar a ENISA las vulnerabilidades explotadas activamente en un plazo de 24 horas. Un SBOM obsoleto significa que no puedes determinar si tu producto está afectado antes de que comience el plazo. Necesitas datos de componentes actualizados antes del incidente, no después.
Error 3: campos de identidad incompletos
Un SBOM sin campos precisos de versión, hash e identificador es prácticamente inútil para la concordancia de vulnerabilidades. Estos campos conectan una entrada de componente con un registro CVE en la Base de Datos Nacional de Vulnerabilidades (NVD), OSV o CISA KEV. Sin ellos, los escáneres de vulnerabilidades no pueden cotejar tus componentes y los controles de calidad de BSI TR-03183 fallarán.
Cada componente debe incluir:
| Campo | Por qué importa | Fuente |
|---|---|---|
| Número de versión exacto | Necesario para la concordancia con CVE/NVD/OSV (no "latest" ni rangos) | Anexo I; TR-03183 obligatorio |
| Hash SHA-256 | Verificación de integridad para componentes binarios | TR-03183 obligatorio |
| Identificador PURL | Vincula el componente con su registro de paquete | TR-03183 obligatorio |
| Nombre del proveedor | Obligatorio en todos los niveles de calidad | Anexo I; TR-03183 |
Un error frecuente de versión es usar CycloneDX 1.3 o anterior. El soporte básico de VEX se añadió en CycloneDX 1.4 (enero de 2022), y la estructura de evidence de componente más rica (identity, occurrences) utilizada para demostrar la trazabilidad del CRA llegó en la versión 1.5 (junio de 2023). Apunta a CycloneDX 1.6 o posterior para la conformidad con el CRA. Comprueba la versión de salida de tu herramienta antes de asumir el cumplimiento.
Error 4: generar los SBOM manualmente
La creación manual del SBOM es propensa a errores y no escala entre versiones de producto. Un SBOM elaborado a mano omite componentes que las herramientas automatizadas detectarían, contiene errores tipográficos en las cadenas de versión y no puede regenerarse de forma fiable cuando cambia un componente. Más importante aún, un proceso manual no puede satisfacer la obligación de actualización continua del CRA: cada publicación, cada parche y cada cambio de componente requiere un SBOM actualizado.
Automatiza la generación con Syft, Trivy o cdxgen. Las entradas manuales deben reservarse para componentes que las herramientas automatizadas no pueden detectar, como bibliotecas comerciales sin entradas en bases de datos de paquetes o blobs de firmware propietario. Todo lo demás debe provenir de la compilación. Las autoridades de vigilancia del mercado pueden solicitar el SBOM en cualquier momento; debe reflejar el estado actual del producto.
Error 5: ignorar los componentes internos y propietarios
Un atajo habitual es documentar solo las dependencias de código abierto y omitir las bibliotecas internas, los módulos propietarios o los blobs de firmware. El anexo I no establece tal distinción. Si un componente está en el producto, pertenece al SBOM.
Los componentes internos a menudo no tienen PURL ni entrada en ningún registro. El enfoque correcto es asignar un identificador interno, listar tu propia organización como proveedor e incluir el hash SHA-256 del artefacto binario. BSI TR-03183 cubre explícitamente los componentes propietarios en todos los niveles de calidad.
Para productos con firmware integrado de un ODM o fabricante de chips, no puedes auditar lo que no has construido tú. La solución es contractual: exige a tus proveedores de firmware la entrega del SBOM. Bajo el CRA, eres responsable del producto completo independientemente de quién haya escrito el código. Para productos hardware-software, consulta el HBOM en el CRA para saber cuándo se necesita un Hardware Bill of Materials junto al SBOM.
Error 6: confiar en los SBOM de los proveedores como artefacto terminado
Los SBOM de los proveedores son una entrada válida, y el CRA espera que los fabricantes usen la documentación de la cadena de suministro. No son un sustituto de un SBOM integrado del producto. La obligación del anexo I recae sobre el fabricante del producto introducido en el mercado de la UE: debes consolidar los SBOM de los proveedores con tus propios componentes de primera parte, dependencias de compilación y código de integración en un único SBOM para el producto integrado.
Si al SBOM de un proveedor le faltan campos exigidos por BSI TR-03183 (PURL, hash, licencia), eres responsable de cubrir esas lagunas antes de que tu producto salga al mercado. Trata los SBOM de los proveedores como materia prima. Tu SBOM del producto es el artefacto de cumplimiento terminado.
Preguntas frecuentes
¿Puedo reutilizar los SBOM de mis proveedores para satisfacer el CRA?
Parcialmente. Los SBOM de los proveedores son una entrada válida para los componentes que suministran, y el CRA espera que los fabricantes aprovechen la documentación de la cadena de suministro en lugar de reinventarla. Pero la obligación del anexo I recae sobre el fabricante del producto introducido en el mercado de la UE: debes producir y mantener un SBOM para el producto integrado, lo que significa consolidar los SBOM de los proveedores con tus propios componentes de primera parte, tus dependencias de compilación y cualquier código de integración. Si al SBOM de un proveedor le faltan campos exigidos por BSI TR-03183 (PURL, hash, licencia), eres responsable de cubrir esas lagunas antes de que tu producto salga al mercado. Trata los SBOM de los proveedores como materia prima, no como un artefacto de cumplimiento terminado.
¿Cuál es el mínimo legal de cobertura de dependencias del SBOM en el CRA?
El anexo I, parte II, punto 1, establece el suelo en las dependencias de máximo nivel. El texto oficial dice: «identificarán y documentarán las vulnerabilidades y los componentes presentes en el producto con elementos digitales, también mediante la elaboración de una nomenclatura de materiales de los programas informáticos en un formato comúnmente utilizado y legible por máquina, que incluya, como mínimo, las dependencias de máximo nivel del producto». Esto significa que las dependencias directas son el mínimo legal. Las dependencias transitivas no son legalmente obligatorias, pero se recomiendan como buena práctica: son lo que los escáneres de vulnerabilidades necesitan realmente para identificar CVE con precisión, y BSI TR-03183 considera la cobertura transitiva como un indicador de calidad.
¿Hay que actualizar el SBOM con cada publicación de parche?
Sí. Cada publicación de parche de seguridad es un desencadenante de actualización obligatoria del SBOM bajo el CRA. El expediente técnico, que incluye el SBOM, debe mantenerse actualizado durante todo el ciclo de vida del producto. Si parcheas un componente vulnerable, tu SBOM debe reflejar la nueva versión. Automatiza la generación del SBOM en CI/CD para que las publicaciones de parches produzcan un artefacto SBOM actualizado de forma automática, sin un paso manual que pueda pasarse por alto bajo presión de plazos.