Errores de SBOM en el CRA: 7 correcciones prácticas para fabricantes
Tu generador de SBOM termina, el archivo se valida y la siguiente revisión de producto puede seguir encontrando lagunas. Los fallos recurrentes en la preparación para el CRA no suelen ser casos legales oscuros. Son árboles de dependencias superficiales, inventarios solo de código fuente, registros obsoletos y componentes que los escáneres no pueden vincular a una vulnerabilidad. El Reglamento de Ciberresiliencia exige un SBOM en formato legible por máquina y ampliamente utilizado, que cubra al menos las dependencias de máximo nivel y se conserve junto a la documentación técnica. Este artículo cubre las siete brechas entre un SBOM que existe formalmente y uno que puede sostener la gestión de vulnerabilidades. Ese es el SBOM que una autoridad de vigilancia del mercado espera encontrar.
Resumen
- Un SBOM generado desde manifiestos de código fuente puede no incluir lo que realmente se envía en el artefacto
- Los componentes sin versión exacta, hash y PURL son difíciles de vincular a CVE
- Las dependencias directas son el mínimo del CRA, no son suficientes para una gestión útil de vulnerabilidades
- Un SBOM generado una sola vez queda obsoleto a medida que aparecen nuevas vulnerabilidades y versiones del producto
- Los componentes internos, propietarios, comerciales y de firmware también forman parte del alcance
- Los SBOM de proveedores son entradas que hay que conciliar, no el SBOM de producto terminado
- Una versión de producto necesita un único registro SBOM autorizado, no fragmentos dispersos
Errores de un vistazo
- Árbol fuente, no artefacto enviado: genera desde el artefacto o imagen compilada para que el código compilado, los paquetes del SO y el firmware sean visibles.
- Campos de identidad superficiales: usa versiones exactas, hashes, PURLs donde estén disponibles y nombres de proveedor para que los escáneres puedan vincular CVE.
- Solo dependencias directas: añade análisis de lockfiles y artefactos compilados para que las dependencias indirectas y empaquetadas entren en el SBOM.
- Archivo puntual: regenera y archiva el SBOM en cada versión, y mantén actualizada la concordancia de vulnerabilidades.
- Código de producto omitido: los componentes internos, propietarios, comerciales y de firmware siguen necesitando identificadores y evidencia.
- Copia de proveedor sin integrar: los SBOM de proveedores son entradas. Concílialos con el código de primera parte y el artefacto de versión final.
- Fragmentación del SBOM: mantén un único SBOM de producto autorizado por versión para que la 1.4.2 tenga un registro defendible.
Captura el código de la aplicación, los paquetes del SO, los blobs de firmware y los archivos generados.
Usa versiones exactas, hashes, nombres de proveedor y PURLs donde estén disponibles.
Combina los SBOM de upstream con el código de primera parte y de integración.
Archiva el SBOM de producto con la versión y la documentación técnica.
Vuelve a ejecutar la concordancia de vulnerabilidades a medida que aparecen nuevos avisos y señales de explotación.
Lo que importa en la evidencia del SBOM
- Usa un formato legible por máquina y ampliamente utilizado.
- Cubre al menos las dependencias de máximo nivel, luego ve más profundo para una gestión útil de vulnerabilidades.
- Conserva el SBOM junto a la documentación técnica y la evidencia de versión.
- No asumas que el CRA obliga a un único formato, un tipo de hash o la publicación pública.
Ese mínimo legal no equivale a un mínimo útil para la gestión de vulnerabilidades. Un SBOM solo de dependencias directas puede satisfacer la frase de cobertura mínima pero seguir siendo demasiado superficial para identificar productos afectados con rapidez. Conviene tratar BSI TR-03183, la guía de ENISA, la guía de SBOM de CISA y la práctica actual con herramientas como referencias de calidad que ayudan a los fabricantes a hacer operativa la obligación del CRA.
Error 1: tu SBOM describe el árbol fuente, no el producto que enviaste
Los manifiestos de código fuente son cómodos, pero no son el producto. Un análisis de fuente puede sobreinformar dependencias de desarrollo y no detectar lo que aparece solo tras la compilación, el empaquetado, la estratificación de contenedor, el enlazado estático o la integración de firmware. Para un fabricante, el SBOM debe responder qué había en la versión del producto, no solo qué se declaró en un archivo de paquete.
La diferencia importa más en productos embebidos y en contenedores. Un análisis a nivel de lenguaje puede no detectar paquetes del SO en una capa base de contenedor. Una exportación de Yocto o Buildroot puede no detectar firmware de proveedor de silicio, cargadores de arranque, módulos del kernel o blobs binarios que entraron fuera del sistema de compilación. Si esos componentes están en el artefacto enviado, pertenecen a la evidencia de versión aunque un escáner automatizado no pueda inferirlos.
La solución es generar desde el artefacto o imagen de versión, y luego compararlo con la salida del código fuente y los lockfiles. Para contenedores, escanea la imagen final por digest. Para firmware, combina la salida de SBOM del sistema de compilación con análisis binario y registros manuales para componentes que las herramientas no pueden identificar automáticamente.
Error 2: la ausencia de hashes y PURLs hace los componentes imposibles de vincular
Un SBOM sin versión exacta, hash, proveedor e identificadores de paquete es difícil de usar para la concordancia de vulnerabilidades. El archivo puede ser legible por máquina, pero un escáner sigue necesitando una identidad estable del componente para decidir si le afecta un CVE, un aviso de OSV, un aviso de seguridad de GitHub o una entrada de CISA KEV.
Cada componente debe tener suficiente identidad para resistir la concordancia automatizada:
Evita "latest", rangos poco precisos y nombres de fork ambiguos.
Campo de identidad principalVincula el registro al archivo, imagen o binario concreto.
SHA-256 o más fuerte en la prácticaRelaciona los datos del paquete con registros, OSV y fuentes tipo GHSA.
Usar donde esté disponibleDiferencia componentes con el mismo nombre y código propietario.
Útil para todos los componentesIndica si el SBOM proviene de fuente, compilación, artefacto, sistema desplegado o entorno de ejecución.
Evidencia de revisiónNo es solo buenas prácticas. NIST anunció el 15 de abril de 2026 que el enriquecimiento de NVD se prioriza ahora para CVE seleccionados porque el volumen de vulnerabilidades ha superado la capacidad de enriquecimiento completo. Eso hace que la concordancia solo por CPE sea un enfoque más débil para las operaciones futuras de vulnerabilidades. Usa PURL donde esté disponible, conserva hashes para los artefactos enviados y no trates el nombre de un componente por sí solo como suficiente.
Un error de formato frecuente es usar CycloneDX 1.3 o anterior. El soporte básico de VEX llegó en CycloneDX 1.4, y la estructura de evidence de componente más rica llegó en CycloneDX 1.5. Para la preparación actual del CRA, apunta a CycloneDX 1.6 o posterior, o a un perfil SPDX actual que tus herramientas puedan consumir con fiabilidad. Comprueba la salida de tu generador antes de asumir que el formato admite los campos que tu proceso necesita.
Error 3: detenerse en las dependencias directas
Las dependencias directas son el mínimo del CRA. No son suficientes para una gestión útil de vulnerabilidades. Una dependencia transitiva es un componente que trae otra dependencia, y puede contener la vulnerabilidad que importa. Cuando un CVE afecta a un paquete transitivo que tu SBOM no registra, el producto puede estar afectado mientras tu flujo de concordancia no emite ninguna alerta.
- Versión del producto
- Biblioteca A incluida
- Biblioteca D incluida
- Biblioteca B y Biblioteca C no son visibles para el escáner
- Versión del producto
- Biblioteca A incluida
- Biblioteca B y Biblioteca C vinculadas bajo Biblioteca A
- Biblioteca D incluida
- Menos puntos ciegos
- El alcance es más fácil de explicar
- Las versiones afectadas son más claras
- Las decisiones VEX tienen mejor evidencia
Un estudio revisado por pares del NDSS 2025, JBomAudit, encontró que 7.907 de 25.882 SBOM de Java no declaraban al menos una dependencia directa. La lección práctica es sencilla: si incluso las dependencias directas suelen estar ausentes, la cobertura transitiva requiere comprobaciones deliberadas.
Para cerrar esta brecha, usa lockfiles donde el ecosistema los admita, escanea artefactos compilados además del código fuente, e inspecciona paquetes que agrupan o reempaquetan dependencias. Trata la cobertura transitiva como una práctica de calidad para auditoría, no como una opción poco importante oculta en la configuración por defecto del escáner.
Error 4: tratar el SBOM como un documento puntual
Un SBOM generado una sola vez y nunca actualizado crea una falsa sensación de seguridad. Se publican nuevos CVE contra componentes que ya están en el producto. Nuevas versiones de firmware, parches y actualizaciones de proveedor cambian el producto. El CRA también espera que la documentación técnica se actualice de forma continua donde corresponda durante el período de soporte.
Desencadenantes habituales de actualización:
Usa el artefacto de software o firmware que introduces en el mercado.
La versión del componente o su estado de corrección ha cambiado.
El grafo de dependencias ha cambiado porque se añadió, eliminó o sustituyó un componente.
La identidad del componente upstream ha cambiado, así que no guardes el archivo del proveedor sin modificar.
Los paquetes del SO o archivos embebidos han cambiado en el binario, paquete de firmware o imagen de contenedor.
El CI/CD es el control práctico. Cada versión debe producir un artefacto SBOM actualizado almacenado junto a la compilación y vinculado a la documentación técnica. Las entradas manuales solo deben existir para componentes que las herramientas no pueden detectar, y esas entradas también necesitan revisión cuando el producto cambia.
Desde el 11 de septiembre de 2026, la notificación del artículo 14 se aplica a las vulnerabilidades explotadas activamente y a los incidentes graves. Para una vulnerabilidad explotada activamente, el flujo es: aviso temprano en 24 horas, notificación de vulnerabilidad en 72 horas e informe final no más tarde de 14 días después de que esté disponible una medida correctiva o de mitigación. Un SBOM obsoleto ralentiza la primera decisión de triaje.
Error 5: omitir componentes internos, propietarios y de firmware
Un atajo habitual es documentar solo las dependencias de código abierto y omitir las bibliotecas internas, los módulos comerciales, el firmware propietario o los blobs de proveedor. Eso no es un SBOM de producto. Si un componente está en el producto, pertenece al alcance, aunque no tenga página en ningún registro público.
Los componentes internos a menudo no tienen PURL ni registro de paquete público. Usa un identificador interno, tu propia organización como proveedor donde corresponda, la versión exacta o el ID de compilación, y el hash del artefacto binario. Para componentes comerciales, conserva el nombre del proveedor, la versión, la evidencia de licencia y las referencias del contrato o de la fuente de verdad en la documentación técnica.
Para productos hardware-software, el firmware es donde esto se hace visible. Los módulos Wi-Fi, módems, elementos seguros, cargadores de arranque, binarios de entorno de ejecución de confianza y módulos del kernel fuera de árbol pueden contener vulnerabilidades pero seguir siendo invisibles para los escáneres de paquetes de lenguaje. Usa los SBOM de proveedores donde estén disponibles, añade registros manuales donde no los haya, y usa el análisis binario como comprobación. Para la parte hardware del paquete de evidencia, consulta HBOM en el CRA.
Error 6: confiar en los SBOM de proveedores como artefacto terminado
Los SBOM de proveedores son entradas válidas. No son tu SBOM de producto terminado. El fabricante introduce en el mercado de la UE el producto integrado. El SBOM del producto tiene que combinar componentes de proveedor, código de primera parte, salidas de compilación, firmware, código de integración y relaciones de dependencia específicas del producto.
El fallo es fácil de pasar por alto: un proveedor te da un archivo CycloneDX, otro te da SPDX, un tercero te da un inventario en PDF y la carpeta del producto final contiene enlaces a los tres. Eso es evidencia de proveedor, no un registro de producto. Un revisor sigue necesitando saber qué componentes tenía la versión 1.4.2 del producto.
Concilia en lugar de copiar. Fusiona los SBOM de proveedores en el SBOM del producto, normaliza los campos de identidad, registra los desconocidos conocidos y conserva los SBOM de upstream como evidencia de apoyo. Si al SBOM de un proveedor le falta PURL, hash, licencia o versión exacta, documenta la laguna y cierra lo que puedas antes de la versión. Una URL a un archivo upstream no equivale a un SBOM de producto integrado.
Error 7: muchos SBOM, ningún registro único de producto
La fragmentación del SBOM es la fase siguiente cuando los equipos adoptan herramientas. Hay un SBOM de aplicación, un SBOM de contenedor, un SBOM de firmware, varios SBOM de proveedores y una hoja de cálculo mantenida por un product manager. Ninguno de ellos es la respuesta autorizada para la versión del producto introducida en el mercado.
Eso crea riesgo en auditorías y operaciones. Cuando aparece una nueva vulnerabilidad explotada activamente, el equipo tiene que buscar entre fragmentos antes de poder decir si el producto está afectado. Cuando una autoridad hace una solicitud motivada, el paquete de evidencia no debe depender de que alguien recuerde en qué carpeta está la fusión más reciente.
Usa un único SBOM de producto autorizado por versión, con los SBOM de componentes de apoyo conservados por debajo. Consérvalo durante al menos 10 años desde que el producto se haya introducido en el mercado, o durante el período de soporte, el plazo que sea mayor. Almacénalo donde la versión, la monitorización de vulnerabilidades, las decisiones VEX y la documentación técnica puedan referenciar la misma versión.
Preguntas frecuentes
Mi escáner no muestra ninguna vulnerabilidad. ¿Es suficiente el SBOM?
Por sí solo, no. Un análisis de vulnerabilidades limpio solo prueba que el escáner no vinculó vulnerabilidades conocidas a los componentes que pudo ver. Si el SBOM se generó solo desde manifiestos de código fuente, no detecta blobs de firmware, le faltan PURLs o hashes, u omite componentes de proveedor, el resultado limpio puede ser un problema de cobertura, no un resultado de seguridad.
¿Hay que publicar el SBOM o entregarlo a todos los clientes?
No. El CRA no crea una obligación general de publicar el SBOM. Consérvalo en la documentación técnica y prepárate para entregarlo a una autoridad de vigilancia del mercado ante una solicitud motivada cuando sea necesario para comprobar el cumplimiento. Puedes optar por compartir información del SBOM contractualmente con clientes, pero eso es distinto de una obligación general de publicación bajo el CRA.
¿Cuál es el mínimo legal de cobertura de dependencias?
El CRA exige que el SBOM cubra al menos las dependencias de máximo nivel. Ese es el mínimo. Para una gestión real de vulnerabilidades, la cobertura solo de directas es insuficiente porque muchas vulnerabilidades están en componentes transitivos, agrupados o reempaquetados. Define tu objetivo operativo en torno al artefacto enviado y las relaciones de dependencia, no solo en torno a la frase del mínimo legal.
Generamos desde código fuente. ¿Es suficiente?
Por lo general, no. Los SBOM de código fuente son útiles para la revisión de desarrollo, pero la evidencia del producto debe reflejar lo que se envió. Genera desde el artefacto o imagen compilada, compara con la salida de lockfiles y código fuente, y añade registros manuales para componentes que las herramientas automatizadas no pueden inferir.
Nuestro proveedor no nos da un SBOM completo. ¿Qué podemos hacer?
Empieza por el contrato y el proceso de compra. Si el proveedor sigue sin poder dar datos completos, registra los desconocidos conocidos, recoge los campos que puedas verificar tú mismo, añade hashes y evidencia de versión para los binarios entregados, y documenta la laguna en el expediente técnico. No omitas en silencio el componente del SBOM del producto.