Lista de comprobación de calidad de SBOM: cómo validar las SBOM que envían sus proveedores

Las tres capas de la calidad de una SBOM

Capa	Pregunta	Qué la comprueba	Lo que no puede decirle
Válida	¿Se puede leer el archivo y cumple el esquema del formato y la versión que declara?	Validadores de esquema	Si algún campo contiene algo útil
Utilizable	¿Están los campos que necesita y puede usarlos una herramienta: identificadores que coincidan con los avisos de seguridad, licencias, hashes, relaciones?	Comprobaciones de campos, perfiles de cumplimiento y puntuaciones de calidad	Lo que falta en el archivo
Completa	¿Incluye todo lo que contiene el software que ha recibido?	La comparación con el build, o con un análisis del binario entregado	Nada que lea solo la SBOM puede responder a esto

La mayoría de los equipos que reciben SBOM se quedan en la primera capa. «El archivo es válido» es el comienzo de la comprobación, no su resultado. La tercera capa es la completitud de la SBOM.

Los marcos de referencia en un minuto

Cite el marco en cada solicitud y en cada respuesta, para que el listón sea uno publicado y no su opinión.

• NTIA, The Minimum Elements for a Software Bill of Materials (12 de julio de 2021). Siete campos de datos (nombre del proveedor, nombre del componente, versión, otros identificadores únicos, relación de dependencia, autor de los datos de la SBOM, marca de tiempo), soporte de automatización en SPDX, CycloneDX o etiquetas SWID, y prácticas: frecuencia, profundidad, incógnitas conocidas, distribución y entrega, control de acceso, tolerancia a errores. Los hashes, las licencias, la fase del ciclo de vida y las firmas figuran como recomendados, más allá del mínimo.
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29 de julio de 2026, tras un borrador del 22 de agosto de 2025). Sustituye a los elementos de la NTIA. Lo redactaron 18 organizaciones de 14 países, entre ellas la CISA, la NSA, el FBI, el BSI alemán y el METI y el NCO japoneses. Tiene 17 campos de datos, diez de ellos nuevos: firma del autor de la SBOM, nombre del formato de datos, versión del formato de datos, contexto de generación, nombre de la herramienta, versión de la herramienta, versión de la SBOM, valor del hash del componente, algoritmo del hash del componente y licencia del componente. «Supplier name» pasa a ser «Component Producer». Sus prácticas son la cobertura, la identificación explícita de la información desconocida, datos procesables por máquina, la gestión de actualizaciones, la frecuencia y la distribución y entrega. El documento formula cada elemento con «should» (debería) y afirma que no crea nuevos requisitos; son los compradores quienes lo hacen vinculante al incluirlo en sus contratos.
• BSI, TR-03183-2 versión 2.1.0 (20 de agosto de 2025), Alemania. La más estricta de las tres, redactada con MUST (debe): JSON o XML, CycloneDX 1.6 o posterior o SPDX 3.0.1 o posterior, una SBOM por versión del software, resolución recursiva de dependencias indicando la completitud de cada lista de dependencias, un hash SHA-512 de cada componente desplegable, el nombre de archivo del componente, las licencias de distribución como identificadores SPDX, y package URL o CPE «if it exists» (si existe). También indica que una SBOM no debe contener información de vulnerabilidades; esa información va en un documento VEX o en un aviso de seguridad.
• Alineación internacional. A Shared Vision of SBOM for Cybersecurity (3 de septiembre de 2025) lo firman 18 organizaciones de 15 países. El trabajo del G7 sobre SBOM trata de sistemas de IA («A shared G7 vision on SBOM for AI», 2025, y «SBOM for AI – Minimum Elements», mayo de 2026) y no fija requisitos para las SBOM de proveedores de sistemas embebidos.
• Automoción. Auto-ISAC publicó un SBOM Informational Report el 11 de febrero de 2025.

La lista de comprobación

Cómo leer las celdas: Obligatorio significa que el documento dice «debe». Elemento mínimo significa que está en la lista mínima de ese documento (la base de la NTIA o los elementos «should» de la CISA). Recomendado significa que el documento lo incluye más allá del mínimo. No mencionado significa que el documento no lo pide. Cómo probar cada control, y el mensaje que debe enviar, se explican en la sección siguiente.

Controles a nivel de SBOM

Control	Por qué importa	NTIA 2021	CISA 2026	BSI TR-03183-2
1. Se puede leer y es válida según el esquema que declara	Un archivo que sus herramientas no pueden leer no es una SBOM	Obligatorio: SPDX, CycloneDX o etiquetas SWID	Práctica: SPDX o CycloneDX procesable por máquina	Obligatorio: JSON o XML
2. La versión de la especificación alcanza su mínimo	Las versiones antiguas no pueden contener campos que usted necesita	No mencionado	Elemento mínimo: nombre y versión del formato de datos; evitar versiones obsoletas	Obligatorio: CycloneDX 1.6+ o SPDX 3.0.1+
3. Autor de la SBOM	Alguien responde del contenido	Elemento mínimo: «Author of SBOM Data»	Elemento mínimo: «SBOM Author», la organización, no la herramienta	Obligatorio: «Creator of the SBOM», correo electrónico o URL
4. Marca de tiempo	Indica qué SBOM es la vigente	Elemento mínimo	Elemento mínimo	Obligatorio; se recomienda UTC
5. Nombre y versión de la herramienta	Indica qué puede cubrir la SBOM de forma fiable	No mencionado	Elemento mínimo	No mencionado
6. Contexto de generación	Un análisis del código fuente y un registro del build de la misma versión son distintos	Recomendado: fase del ciclo de vida («source», «build», «post-build»)	Elemento mínimo: «before build», «build» o «after build»	Sin campo; el contenido debe coincidir con lo que estaba disponible durante el build
7. Versión o número de serie de la SBOM	Distingue una corrección del original	No mencionado	Elemento mínimo: «SBOM Version»	Obligatorio si el formato lo tiene: «SBOM-URI»
8. Firma del autor	Demuestra que el archivo llegó del proveedor sin cambios	Recomendado: se fomenta la firma	Elemento mínimo: «SBOM Author Signature»	Solo informativo: «ideally» (idealmente) firmada
9. El componente de primer nivel coincide con lo que ha recibido	La SBOM de la versión equivocada es peor que no tener ninguna	Elemento mínimo: componentes principales	Elemento mínimo: el componente objetivo	Obligatorio: el componente principal, la raíz del árbol

Controles a nivel de componente

Control	Por qué importa	NTIA 2021	CISA 2026	BSI TR-03183-2
10. Nombre del componente	Lo primero que usa cualquier coincidencia	Elemento mínimo	Elemento mínimo	Obligatorio; el nombre de archivo si no hay nombre
11. Versión: sin valores latest, unknown ni vacíos	Los avisos de seguridad se aplican a rangos de versiones	Elemento mínimo	Elemento mínimo; indicarlo si se desconoce	Obligatorio; la fecha del archivo si no hay versión
12. Productor o proveedor	Distingue dos componentes con el mismo nombre e indica quién lo corrige	Elemento mínimo: «Supplier Name»	Elemento mínimo: «Component Producer»	Obligatorio: «Component creator», correo electrónico o URL
13. Package URL siempre que el ecosistema la tenga, CPE cuando no; ambos bien formados	Sin un identificador (package URL, CPE), nada puede cruzarse con una base de datos de vulnerabilidades	Elemento mínimo: «Other Unique Identifiers», como CPE, SWID o PURL, si existen	Elemento mínimo: al menos un identificador, como CPE o PURL; incluirlos todos	Obligatorio si existe: CPE o purl
14. Valor y algoritmo del hash, que coincidan con el archivo recibido	Demuestra que esta SBOM describe este binario	Recomendado	Elemento mínimo: hash del artefacto ejecutable, con un algoritmo aprobado por una autoridad como el NIST	Obligatorio: SHA-512 del componente desplegable
15. Licencia como identificadores o expresiones SPDX, sin NOASSERTION generalizado	Su especialista en licencias evalúa a partir de ella el copyleft y otras obligaciones	Recomendado	Elemento mínimo; identificadores SPDX cuando sea posible	Obligatorio: licencias de distribución, preferentemente identificadores SPDX
16. Relaciones de dependencia, y si la lista está completa	Muestra qué incorporó un paquete vulnerable y si se puede confiar en las lagunas	Elemento mínimo; indicar cuándo las dependencias directas están listadas por completo	Elemento mínimo	Obligatorio, indicando la completitud de cada lista
17. Nombre de archivo	Vincula la entrada con un archivo del dispositivo	No mencionado	No mencionado	Obligatorio
18. Propiedades de ejecutable, archivo comprimido y estructurado	Indica qué tipo de archivo es cada componente	No mencionado	No mencionado	Obligatorio

Controles de cobertura

Control	Por qué importa	NTIA 2021	CISA 2026	BSI TR-03183-2
19. Profundidad transitiva, no solo el primer nivel	La mayor parte del código vulnerable llega de forma indirecta	Primer nivel obligatorio; transitivas recomendadas	Práctica de cobertura: incluir dependencias transitivas; sin profundidad mínima	Obligatorio: resolución recursiva
20. Incógnitas conocidas declaradas	Una SBOM que declara sus lagunas es fiable en lo que incluye	Práctica obligatoria	Práctica: información desconocida y retenida marcada	Obligatorio mediante la declaración de completitud
21. Una SBOM por versión de software entregada	La versión que usted ejecuta es la que importa	Obligatorio: una SBOM nueva para cada build o versión	Práctica: frecuencia	Obligatorio
22. Correcciones enviadas como una SBOM nueva	Un error corregido en silencio no se puede rastrear	Práctica: tolerancia a errores	Práctica: gestión de actualizaciones	Obligatorio: una SBOM actualizada cuando se corrigen errores
23. Verosimilitud: sin duplicados, un número de componentes acorde con el producto, paquetes del sistema operativo presentes en un dispositivo basado en Linux	La prueba de completitud más barata	No mencionado	Práctica de cobertura: varias instancias listadas por separado	Las instancias múltiples deben listarse por separado

Cómo probar cada control y qué decir al proveedor

Control	Cómo probarlo automáticamente	Mensaje para el proveedor
1, 2. Esquema y versión de la especificación	Un validador de esquema para el formato y la versión declarados; después, comparar specVersion (CycloneDX) o la versión de SPDX con su mínimo	«El archivo no supera la validación del esquema de CycloneDX 1.6 en las rutas indicadas. Por favor, vuelva a generarlo con un generador y valídelo antes de enviarlo.»
3 a 7. Autor, marca de tiempo, herramienta, contexto, versión	Metadatos obligatorios presentes: en CycloneDX metadata.authors, metadata.timestamp, metadata.tools, metadata.lifecycles, serialNumber y version; en SPDX, la información de creación	«La SBOM no indica la herramienta que la generó ni el contexto de generación. Ambos son CISA 2026 Minimum Elements.»
8. Firma	Hay una firma y se verifica con la clave que publicó el proveedor	«Por favor, firme la SBOM o envíe una firma separada, como describe el elemento SBOM Author Signature de CISA 2026.»
9. Componente de primer nivel	El nombre y la versión de metadata.component (CycloneDX) o del elemento raíz descrito (SPDX) coinciden con la referencia y la versión de software recibidas	«Esta SBOM describe la versión 5.2.0; hemos recibido la 5.3.0. Por favor, envíe la SBOM de la 5.3.0.»
10, 11. Nombre y versión	Ningún nombre vacío; ninguna versión vacía, latest ni unknown salvo que se declare desconocida	«14 componentes no tienen versión. Por favor, indique la versión exacta o márquela como desconocida.»
12. Productor	Un proveedor, fabricante o autor en cada componente	«Hay componentes sin productor, algo que pide el elemento Component Producer de CISA 2026.»
13. Identificadores	Cada purl se analiza sin errores con una biblioteca de package URL conforme a ECMA-427; cada CPE tiene sintaxis CPE 2.3 válida y existe en el diccionario CPE de la NVD	«Ningún componente tiene package URL ni CPE, así que ninguno puede cruzarse con las bases de datos de vulnerabilidades. Por favor, añada una purl para cada paquete procedente de un gestor de paquetes.»
14. Hashes	Una entrada SHA-512 en cada componente desplegable; calcular el sha512sum del archivo recibido y comparar	«La SBOM no tiene hashes. BSI TR-03183-2 pide el SHA-512 de cada componente desplegable.»
15. Licencias	Identificadores o expresiones de licencia que se resuelvan en la lista de licencias SPDX; contar los valores NOASSERTION y vacíos	«El 92 % de los componentes tienen NOASSERTION como licencia. Por favor, indique identificadores de licencia SPDX.»
16. Dependencias	Un grafo dependencies (CycloneDX) o relaciones de dependencia (SPDX); una declaración de completitud, como las compositions de CycloneDX con un valor aggregate	«La SBOM es una lista plana. Por favor, incluya las relaciones de dependencia e indique si cada lista está completa.»
17, 18. Nombre de archivo y propiedades de archivo	Están presentes las propiedades que BSI TR-03183-2 define para cada formato	«Por favor, añada el nombre de archivo y las propiedades de ejecutable, archivo comprimido y estructurado, como exige BSI TR-03183-2 v2.1.0.»
19 a 23. Cobertura	Profundidad del grafo de dependencias, detección de duplicados, número de componentes comparado con productos similares, componentes esperados según el tipo de producto	«La SBOM no incluye kernel, bootloader ni paquetes del sistema base para una pantalla basada en Linux. Por favor, envíe la SBOM de la imagen completa.»

Los porcentajes y las cifras de los mensajes son ejemplos. Ponga los números reales y cite el marco y su versión cada vez.

Lo que una buena puntuación sigue sin ver

Un archivo puede ser válido, sacar un 9 sobre 10 y aun así omitir la mitad del producto. Las puntuaciones de calidad leen los campos que están; no pueden ver los componentes que faltan.

Ejemplo práctico. Un proveedor envía la SBOM de una pantalla basada en Linux. Es CycloneDX 1.6 válido, cada componente tiene versión, package URL, licencia y hash SHA-512, y el grafo de dependencias está bien formado. Incluye la aplicación de la pantalla y 40 bibliotecas. No incluye el kernel de Linux, el bootloader ni ningún paquete del sistema base. Todas las comprobaciones de campos se superan. La SBOM no sirve para las CVE del kernel, que un dispositivo Linux debe vigilar, porque el kernel no está en ella.

Cómo puede un equipo receptor probar la completitud:

• Comparar con un análisis binario del firmware entregado. Algunos OEM lo usan como SBOM provisional hasta que la del proveedor es lo bastante buena, y después como contraste.
• Buscar los componentes esperados según el tipo de producto. Una imagen Linux tiene un kernel, una biblioteca C y un sistema init; un controlador industrial, sus pilas de protocolos.
• Pedir el contexto de generación y la herramienta. Un análisis del código fuente no ve lo que descargó el build.
• Preguntar si la SBOM procede del build que produjo el software recibido. Esa es la pregunta que decide la tercera capa.

Las SBOM pequeñas pueden ser legítimas. Una ECU bare-metal con firmware propietario y una calibración del fabricante puede tener honestamente dos componentes. Acéptelo cuando la SBOM lo diga y declare sus incógnitas conocidas, en lugar de penalizarla por su tamaño.

Herramientas que automatizan los controles

Comprobadas en GitHub el 11 de noviembre de 2026. Ninguno de estos repositorios está archivado.

Herramienta	Qué comprueba	Qué no hace	Estado
CycloneDX CLI	Validación de esquema de CycloneDX 1.0 a 1.7, JSON o XML; --fail-on-errors para CI	SPDX, calidad de los campos, perfiles de marcos	v0.33.1, julio de 2026
sbom-utility	Validación de esquema de CycloneDX 1.2 a 1.7 y SPDX 2.1 a 2.3 en JSON, con variantes de esquema personalizadas	SPDX 3, XML, perfiles de marcos	v0.19.2, junio de 2026
SPDX tools-java	Verify para SPDX 2.0 a 2.3 y 3.0.1	CycloneDX, perfiles de marcos	v2.0.7, junio de 2026
SPDX tools-python	pyspdxtools -i: validación completa de SPDX 2.2 y 2.3	Leer SPDX 3, cuyo soporte es experimental	v0.8.5, marzo de 2026
SPDX NTIA Conformance Checker	SPDX 2.2, 2.3 y 3.0 frente a NTIA 2021, CISA FSCT3 y BSI TR-03183-2 v2.1.0; también en versión web	CycloneDX; CISA 2026 es una solicitud abierta	v6.0.0, octubre de 2026
sbomqs	Una puntuación (score) de 0 a 10 sobre identificación, procedencia, integridad, completitud, licencias, vulnerabilidades y estructura; perfiles compliance para CISA 2026, NTIA 2021, BSI TR-03183-2 v1.1 a v2.1.0, FSCT v3 y OpenChain Telco	Ver los componentes que faltan	v2.1.3, octubre de 2026; perfil CISA 2026 desde la v2.1.0, corregido en la v2.1.2
sbom-scorecard	Una puntuación ponderada del cumplimiento de la especificación, la información de generación y los identificadores, versiones y licencias de los paquetes	Perfiles de marcos	0.0.7, abril de 2023, la última versión publicada

Por ahora, solo sbomqs comprueba los CISA 2026 Minimum Elements. Revise las notas de versión de cada herramienta antes de fiarse de un perfil: en sbomqs 2.1.1, la opción de CISA 2026 ejecutaba por error la comprobación de 2021. Para BSI TR-03183-2 v2.1.0 en sbomqs, use --bsi-v21 o --bsi; --bsi-v2 comprueba la v2.0.0.

Un paso mínimo de recepción para la SBOM CycloneDX de un proveedor:

# 1. Valid: fail the intake on schema errors
cyclonedx-cli validate --input-file supplier-sbom.json --input-format json --fail-on-errors

# 2. Usable: run the profile your requirement names
sbomqs compliance --bsi-v21 supplier-sbom.json
sbomqs compliance --ntia supplier-sbom.json   # CISA 2026 Minimum Elements

# 3. Track field quality over time
sbomqs score supplier-sbom.json

# 4. The hash in the SBOM matches the file you received
sha512sum firmware-5.3.0.bin

Para SPDX, use sbomcheck -s spdx3 -c bsi supplier-sbom.json del NTIA Conformance Checker. Lea el informe de cumplimiento y rechace el archivo en los controles que su requisito hace obligatorios; devuélvalo al proveedor con los mensajes de arriba.

Incluirlo en los requisitos para proveedores

Una lista que el proveedor nunca ha visto no es un requisito. Inclúyala en el anexo del contrato:

• El marco y su versión: por ejemplo «BSI TR-03183-2 v2.1.0» o «CISA 2026 Minimum Elements». Cite uno; no escriba «estándar del sector».
• El formato y la versión mínima de la especificación: por ejemplo CycloneDX 1.6 o posterior, o SPDX 3.0.1 o posterior, en JSON.
• Los campos que añade por su cuenta, como hashes SHA-512 o package URL para cada paquete.
• La entrega: una SBOM por versión de software entregada, antes que el software o junto con él.
• La validación que el proveedor ejecuta antes del envío, indicando herramienta y perfil.
• El circuito de respuesta: quién recibe las observaciones y en qué plazo debe llegar una SBOM corregida.

La parte del proveedor en el mismo acuerdo está en la guía de SBOM para proveedores. Para un fabricante de software que responde a una solicitud puntual, consulte solicitudes de SBOM de clientes.

Corregir una SBOM rechazada (para proveedores)

• Archivos escritos a mano. Use un generador o una biblioteca de SBOM, nunca un editor de texto.
• Faltan package URL. Genérelas desde el gestor de paquetes o el build, no a mano. Una purl tecleada es una purl adivinada.
• Faltan licencias. Tome la licencia declarada de los metadatos del paquete, como identificador SPDX.
• Sin hashes. Calcúlelos sobre los archivos que realmente entrega, al final del build.
• La versión equivocada. Genere la SBOM en el build de la versión y póngale el nombre de la versión.
• Solo el primer nivel. Use un método que resuelva las dependencias transitivas.

La forma más fiable de corregir a la vez la completitud y los identificadores es generar la SBOM a partir del build que produjo el software entregado. Consulte SBOM generadas en el build y buenas prácticas de SBOM.

De dónde salen las buenas SBOM y qué papel tiene CRACI

Para los proveedores que compilan en GitHub Actions, CRACI sustituye a los runners alojados en GitHub y registra la SBOM durante el build, de modo que incluye lo que el build descargó realmente.

• Cada paquete con una package URL, y cada componente con su licencia declarada.
• Las dependencias transitivas, a cualquier profundidad que alcanzara el build.
• Un estado de completitud para cada job, que responde a la cuestión de las incógnitas conocidas build a build: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.
• Exportación en CycloneDX o SPDX; la API de SBOM devuelve CycloneDX 1.7 en JSON.

Para toda una organización de ingeniería, consulte estandarizar la generación de SBOM, y para Linux embebido, por qué los escáneres no ven lo que hay en los builds de Yocto.

Para los OEM, se pueden añadir a CRACI SBOM de terceros, de modo que los componentes que compra se vigilan frente a nuevas vulnerabilidades junto con sus propios builds. Consulte herramientas de gestión de SBOM para ver cómo se compara.

Cuándo CRACI no es la respuesta

• Validar y puntuar las SBOM que recibe. CRACI no ofrece un validador de SBOM ni una puntuación de calidad. Use las herramientas de arriba.
• Proveedores sin CI, o cuyo código se genera con herramientas basadas en modelos sin descarga de paquetes. Un registrador de builds aporta poco; una SBOM validada procedente de una biblioteca generadora es la respuesta realista.
• Firmware que solo recibe como binario. Eso lo resuelve el análisis binario.
• SBOM firmadas, la firma del autor de CISA 2026. CRACI no firma SBOM.

Calidad y validación de SBOM: preguntas frecuentes

¿Cómo compruebo la calidad de una SBOM que me ha enviado un proveedor?

Pruebe tres capas. Valide el archivo frente a su esquema, revise los campos frente a un marco concreto como BSI TR-03183-2 o los CISA 2026 Minimum Elements y, después, pruebe la completitud: compárela con un análisis binario de lo recibido y busque los componentes que el tipo de producto debe contener.

¿Qué campos debe contener una SBOM?

Depende del marco que cite. Los 2026 Minimum Elements de la CISA incluyen 17 campos, entre ellos autor, marca de tiempo, herramienta, contexto de generación y, por componente, nombre, versión, productor, identificadores, hash y licencia. BSI TR-03183-2 añade un hash SHA-512, el nombre de archivo y las propiedades de archivo, y los hace obligatorios.

¿Qué cambió entre los elementos mínimos de la NTIA y los 2026 Minimum Elements de la CISA?

La lista de 2026 de la CISA sustituye los siete campos de la NTIA por 17. Son nuevos la firma del autor, el nombre y la versión del formato de datos, el contexto de generación, el nombre y la versión de la herramienta, la versión de la SBOM, el valor y el algoritmo del hash del componente y la licencia del componente. Supplier name pasó a ser Component Producer, y la profundidad pasó a ser cobertura.

¿Qué exige BSI TR-03183-2 en una SBOM?

La versión 2.1.0 exige CycloneDX 1.6+ o SPDX 3.0.1+ en JSON o XML, una SBOM por versión del software, dependencias recursivas con su completitud indicada y, por componente, creador, nombre, versión, nombre de archivo, licencias, hash SHA-512 y propiedades de archivo, con package URL o CPE si existe.

¿Necesita hashes una SBOM? ¿Con qué algoritmo?

La NTIA los recomendaba; CISA 2026 hace del hash un elemento mínimo, con un algoritmo aprobado por una autoridad como el NIST; BSI TR-03183-2 exige el SHA-512 de cada componente desplegable. Pida SHA-512 y compárelo con el archivo recibido.

¿Necesito tanto un CPE como una PURL?

No siempre. Pida una package URL siempre que el ecosistema la tenga, y un CPE cuando no, como ocurre con muchos componentes comerciales o embebidos. CISA 2026 pide al menos un identificador y todos los que se conozcan; el BSI exige cada uno si existe.

¿Cómo valido un archivo CycloneDX o SPDX?

Para CycloneDX, cyclonedx-cli validate con --fail-on-errors, o sbom-utility. Para SPDX, el comando Verify de SPDX tools-java, o pyspdxtools para SPDX 2.2 y 2.3. Después, ejecute un perfil de marco con sbomqs o con el SPDX NTIA Conformance Checker.

¿Qué es una buena puntuación de calidad de SBOM?

No hay un umbral estándar ni una referencia que nos atrevamos a citar. Una puntuación mide los campos presentes, no la completitud: un archivo puede sacar un 9 sobre 10 y omitir la mitad del producto. Fije mejor criterios de aceptación por control en su requisito para proveedores y siga la puntuación como tendencia.