Checklist de qualidade de SBOM: como validar as SBOM dos seus fornecedores

As três camadas da qualidade de uma SBOM

Camada	Pergunta	O que a verifica	O que não consegue dizer
Válida	O ficheiro é interpretável e segue o esquema do formato e da versão que declara?	Validadores de esquema	Se algum campo está preenchido com algo útil
Utilizável	Os campos de que precisa estão lá, e uma ferramenta consegue usá-los: identificadores que correspondem a avisos de segurança, licenças, hashes, relações?	Verificações de campos, perfis de conformidade e pontuações de qualidade	O que falta no ficheiro
Completa	Indica tudo o que está no software que recebeu?	Comparação com o build, ou com uma análise do binário entregue	Nada que leia apenas a SBOM consegue responder a isto

A maioria das equipas que recebem SBOM fica pela primeira camada. "O ficheiro valida" é o início da verificação, não o resultado. A terceira camada é a completude da SBOM.

Os frameworks num minuto

Indique o framework em cada pedido e em cada feedback, para que o critério seja um critério publicado e não a sua opinião.

• NTIA, The Minimum Elements for a Software Bill of Materials (12 de julho de 2021). Sete campos de dados (supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data, timestamp), suporte à automatização em SPDX, CycloneDX ou etiquetas SWID, e práticas: frequência, profundidade, incógnitas conhecidas, distribuição e entrega, controlo de acessos e acomodação de erros. Hashes, licenças, fase do ciclo de vida e assinaturas aparecem como recomendados, para lá do mínimo.
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29 de julho de 2026, depois de um rascunho a 22 de agosto de 2025). Substitui os elementos da NTIA. Redigido por 18 organizações de 14 países, entre elas a CISA, a NSA, o FBI, o BSI alemão e o METI e o NCO japoneses. Tem 17 campos de dados, dez deles novos: SBOM author signature, data format name, data format version, generation context, tool name, tool version, SBOM version, component hash value, component hash algorithm e component license. "Supplier name" passa a "Component Producer". As práticas são cobertura, identificação explícita da informação desconhecida, dados processáveis por máquina, acomodação de atualizações, frequência, e distribuição e entrega. O documento formula cada elemento com "should" e diz que não cria novos requisitos; os compradores tornam-no vinculativo ao incluí-lo nos contratos.
• BSI, TR-03183-2 versão 2.1.0 (20 de agosto de 2025), Alemanha. A mais exigente das três, redigida com MUST: JSON ou XML, CycloneDX 1.6 ou posterior ou SPDX 3.0.1 ou posterior, uma SBOM por versão de software, resolução recursiva de dependências com a completude de cada lista de dependências declarada, um hash SHA-512 de cada componente implementável, o nome de ficheiro do componente, licenças de distribuição como identificadores SPDX, e package URL ou CPE "if it exists". Diz também que uma SBOM não pode conter informação sobre vulnerabilidades; essa pertence a um documento VEX ou a um aviso de segurança.
• Alinhamento internacional. A Shared Vision of SBOM for Cybersecurity (3 de setembro de 2025) é assinado por 18 organizações de 15 países. O trabalho do G7 sobre SBOM diz respeito a sistemas de IA ("A shared G7 vision on SBOM for AI", 2025, e "SBOM for AI – Minimum Elements", maio de 2026) e não define requisitos para SBOM de fornecedores de software embarcado.
• Automóvel. A Auto-ISAC publicou um SBOM Informational Report a 11 de fevereiro de 2025.

A checklist

Como ler as células: Obrigatório significa que o documento diz must. Elemento mínimo significa que consta da lista mínima desse documento (a base da NTIA, ou os elementos "should" da CISA). Recomendado significa que o documento o refere para lá do mínimo. Não mencionado significa que o documento não o pede. Como testar cada verificação, e a frase de feedback a enviar, segue na secção seguinte.

Verificações ao nível da SBOM

Verificação	Porque é importante	NTIA 2021	CISA 2026	BSI TR-03183-2
1. É interpretável e valida contra o esquema declarado	Um ficheiro que as suas ferramentas não conseguem ler não é uma SBOM	Obrigatório: SPDX, CycloneDX ou etiquetas SWID	Prática: SPDX ou CycloneDX processável por máquina	Obrigatório: JSON ou XML
2. A versão da especificação cumpre o seu mínimo	Versões antigas não suportam campos de que precisa	Não mencionado	Elemento mínimo: nome e versão do formato de dados; evitar versões obsoletas	Obrigatório: CycloneDX 1.6+ ou SPDX 3.0.1+
3. Autor da SBOM	Alguém responde pelo conteúdo	Elemento mínimo: "Author of SBOM Data"	Elemento mínimo: "SBOM Author", a organização, não a ferramenta	Obrigatório: "Creator of the SBOM", email ou URL
4. Carimbo temporal	Indica qual é a SBOM atual	Elemento mínimo	Elemento mínimo	Obrigatório; UTC recomendado
5. Nome e versão da ferramenta	Indica o que se pode confiar que a SBOM cobre	Não mencionado	Elemento mínimo	Não mencionado
6. Contexto de geração	Uma análise do código-fonte e um registo do build da mesma versão são diferentes	Recomendado: fase do ciclo de vida ("source", "build", "post-build")	Elemento mínimo: "before build", "build" ou "after build"	Sem campo; o conteúdo tem de corresponder ao que estava disponível durante o build
7. Versão ou número de série da SBOM	Distingue uma correção do original	Não mencionado	Elemento mínimo: "SBOM Version"	Obrigatório se o formato o tiver: "SBOM-URI"
8. Assinatura do autor	Mostra que o ficheiro veio do fornecedor sem alterações	Recomendado: a assinatura é incentivada	Elemento mínimo: "SBOM Author Signature"	Apenas informativo: assinada "ideally"
9. O componente de topo corresponde ao que recebeu	A SBOM da versão errada é pior do que nenhuma	Elemento mínimo: componentes primários	Elemento mínimo: o componente-alvo	Obrigatório: o componente primário, a raiz da árvore

Verificações ao nível dos componentes

Verificação	Porque é importante	NTIA 2021	CISA 2026	BSI TR-03183-2
10. Nome do componente	A primeira coisa que qualquer correspondência usa	Elemento mínimo	Elemento mínimo	Obrigatório; o nome de ficheiro se não houver nome
11. Versão: sem valores latest, unknown ou vazios	Os avisos de segurança aplicam-se a intervalos de versões	Elemento mínimo	Elemento mínimo; indicar se for desconhecida	Obrigatório; a data do ficheiro se não houver versão
12. Produtor ou fornecedor	Distingue dois componentes com o mesmo nome e indica quem os corrige	Elemento mínimo: "Supplier Name"	Elemento mínimo: "Component Producer"	Obrigatório: "Component creator", email ou URL
13. Package URL sempre que o ecossistema o tenha, CPE quando não tem; ambos bem formados	Sem um identificador (package URL, CPE), nada pode ser associado a uma base de dados de vulnerabilidades	Elemento mínimo: "Other Unique Identifiers", como CPE, SWID ou PURL, se existirem	Elemento mínimo: pelo menos um identificador, como CPE ou PURL; incluir todos	Obrigatório se existir: CPE ou purl
14. Valor e algoritmo de hash, correspondentes ao ficheiro recebido	Prova que esta SBOM descreve este binário	Recomendado	Elemento mínimo: hash do artefacto executável, com um algoritmo aprovado por uma autoridade como o NIST	Obrigatório: SHA-512 do componente implementável
15. Licença como identificadores ou expressões SPDX, sem NOASSERTION generalizado	O especialista em licenças avalia com base nela o copyleft e outras obrigações	Recomendado	Elemento mínimo; identificadores SPDX sempre que possível	Obrigatório: licenças de distribuição, de preferência identificadores SPDX
16. Relações de dependência, e se a lista está completa	Mostra o que trouxe um pacote vulnerável e se as lacunas são de confiança	Elemento mínimo; indicar quando as dependências diretas estão totalmente listadas	Elemento mínimo	Obrigatório, com a completude de cada lista declarada
17. Nome de ficheiro	Liga a entrada a um ficheiro no dispositivo	Não mencionado	Não mencionado	Obrigatório
18. Propriedades de executável, arquivo e estruturado	Indica que tipo de ficheiro é cada componente	Não mencionado	Não mencionado	Obrigatório

Verificações de cobertura

Verificação	Porque é importante	NTIA 2021	CISA 2026	BSI TR-03183-2
19. Profundidade transitiva, não apenas o nível superior	A maior parte do código vulnerável chega de forma indireta	Nível superior obrigatório; transitivo recomendado	Prática de cobertura: incluir dependências transitivas; sem profundidade mínima	Obrigatório: resolução recursiva
20. Incógnitas conhecidas declaradas	Uma SBOM que declara as suas lacunas é de confiança para o que indica	Prática obrigatória	Prática: informação desconhecida e retida assinalada	Obrigatório através da declaração de completude
21. Uma SBOM por versão de software entregue	A versão que utiliza é a que importa	Obrigatório: uma nova SBOM para cada build ou versão	Prática: frequência	Obrigatório
22. Correções enviadas como uma nova SBOM	Um erro corrigido em silêncio não pode ser rastreado	Prática: acomodação de erros	Prática: acomodação de atualizações	Obrigatório: uma SBOM atualizada quando são corrigidos erros
23. Plausibilidade: sem duplicados, um número de componentes adequado ao produto, pacotes do sistema operativo presentes num dispositivo baseado em Linux	O teste de completude mais barato	Não mencionado	Prática de cobertura: várias instâncias listadas em separado	Várias instâncias têm de ser listadas em separado

Como testar cada verificação, e o que dizer ao fornecedor

Verificação	Como testá-la automaticamente	Frase de feedback para o fornecedor
1, 2. Esquema e versão da especificação	Um validador de esquema para o formato e a versão declarados; depois, comparar specVersion (CycloneDX) ou a versão SPDX com o seu mínimo	"O ficheiro falha a validação de esquema para CycloneDX 1.6 nos caminhos indicados. Gere-o novamente com um gerador e valide-o antes de o enviar."
3 a 7. Autor, carimbo temporal, ferramenta, contexto, versão	Metadados obrigatórios presentes: em CycloneDX metadata.authors, metadata.timestamp, metadata.tools, metadata.lifecycles, serialNumber e version; em SPDX a creation information	"A SBOM não indica a ferramenta que a produziu nem o contexto de geração. Ambos são CISA 2026 Minimum Elements."
8. Assinatura	Existe uma assinatura e é verificada com a chave que o fornecedor publicou	"Assine a SBOM, ou envie uma assinatura destacada, como descreve o elemento SBOM Author Signature da CISA 2026."
9. Componente de topo	O nome e a versão de metadata.component (CycloneDX) ou do elemento raiz descrito (SPDX) correspondem ao número de peça e à versão de software recebidos	"Esta SBOM descreve a versão 5.2.0; recebemos a 5.3.0. Envie a SBOM da 5.3.0."
10, 11. Nome e versão	Sem nomes vazios; sem versões vazias, latest ou unknown, salvo se declaradas como desconhecidas	"14 componentes não têm versão. Indique a versão exata, ou assinale-a como desconhecida."
12. Produtor	Um fornecedor, fabricante ou autor em cada componente	"Os componentes não têm produtor, que o elemento Component Producer da CISA 2026 pede."
13. Identificadores	Cada purl é interpretado por uma biblioteca de package URL segundo a ECMA-427; cada CPE tem sintaxe CPE 2.3 válida e existe no dicionário CPE da NVD	"Nenhum componente tem package URL ou CPE, pelo que nenhum pode ser associado às bases de dados de vulnerabilidades. Acrescente um purl para cada pacote proveniente de um gestor de pacotes."
14. Hashes	Uma entrada SHA-512 em cada componente implementável; calcular sha512sum do ficheiro recebido e comparar	"A SBOM não tem hashes. A BSI TR-03183-2 pede o SHA-512 de cada componente implementável."
15. Licenças	IDs ou expressões de licença que constam da lista de licenças SPDX; contar NOASSERTION e valores vazios	"92% dos componentes têm NOASSERTION como licença. Indique identificadores de licença SPDX."
16. Dependências	Um grafo dependencies (CycloneDX) ou relações de dependência (SPDX); uma declaração de completude, como compositions do CycloneDX com um valor aggregate	"A SBOM é uma lista plana. Inclua as relações de dependência e indique se cada lista está completa."
17, 18. Nome de ficheiro e propriedades do ficheiro	As propriedades que a BSI TR-03183-2 define para cada formato estão presentes	"Acrescente o nome de ficheiro e as propriedades de executável, arquivo e estruturado, como exige a BSI TR-03183-2 v2.1.0."
19 a 23. Cobertura	Profundidade do grafo de dependências, deteção de duplicados, número de componentes comparado com produtos semelhantes, componentes esperados por tipo de produto	"A SBOM não indica kernel, bootloader nem pacotes do sistema base para um ecrã baseado em Linux. Envie a SBOM da imagem completa."

As percentagens e contagens nas frases de feedback são exemplos. Coloque os números reais e indique sempre o framework e a versão.

O que uma pontuação positiva continua a não ver

Um ficheiro pode validar, ter 9 em 10 e ainda assim omitir metade do produto. As pontuações de qualidade leem os campos que existem; não veem os componentes que faltam.

Exemplo prático. Um fornecedor envia a SBOM de um ecrã baseado em Linux. É CycloneDX 1.6 válido, cada componente tem versão, package URL, licença e hash SHA-512, e o grafo de dependências está bem formado. Indica a aplicação do ecrã e 40 bibliotecas. Não indica o kernel Linux, o bootloader nem qualquer pacote do sistema base. Todas as verificações de campos passam. A SBOM é inútil para as CVE do kernel, que um dispositivo Linux tem de monitorizar, porque o kernel não está nela.

Como uma equipa recetora pode testar a completude:

• Comparar com uma análise binária do firmware entregue. Alguns OEM usam-na como SBOM substituta até a SBOM do fornecedor ser suficientemente boa, e depois como verificação cruzada.
• Procurar os componentes esperados por tipo de produto. Uma imagem Linux tem um kernel, uma biblioteca C e um sistema init; um controlador industrial tem as suas pilhas de protocolos.
• Pedir o contexto de geração e a ferramenta. Uma análise do código-fonte não vê o que o build foi buscar.
• Perguntar se a SBOM veio do build que produziu o software recebido. É essa a pergunta que decide a terceira camada.

SBOM pequenas podem ser legítimas. Uma ECU bare-metal com firmware proprietário e uma calibração do fornecedor pode, com toda a honestidade, ter dois componentes. Aceite-o quando a SBOM o diz e declara as suas incógnitas conhecidas, em vez de a penalizar pelo tamanho.

Ferramentas que automatizam as verificações

Verificado no GitHub a 11 de novembro de 2026. Nenhum destes repositórios está arquivado.

Ferramenta	O que verifica	O que não faz	Estado
CycloneDX CLI	Validação de esquema de CycloneDX 1.0 a 1.7, JSON ou XML; --fail-on-errors para CI	SPDX, qualidade dos campos, perfis de frameworks	v0.33.1, julho de 2026
sbom-utility	Validação de esquema de CycloneDX 1.2 a 1.7 e SPDX 2.1 a 2.3 JSON, com variantes de esquema personalizadas	SPDX 3, XML, perfis de frameworks	v0.19.2, junho de 2026
SPDX tools-java	Verify para SPDX 2.0 a 2.3 e 3.0.1	CycloneDX, perfis de frameworks	v2.0.7, junho de 2026
SPDX tools-python	pyspdxtools -i: validação completa de SPDX 2.2 e 2.3	Ler SPDX 3, cujo suporte é experimental	v0.8.5, março de 2026
SPDX NTIA Conformance Checker	SPDX 2.2, 2.3 e 3.0 face a NTIA 2021, CISA FSCT3 e BSI TR-03183-2 v2.1.0; também em versão web	CycloneDX; CISA 2026 é um pedido em aberto	v6.0.0, outubro de 2026
sbomqs	Uma score de 0 a 10 sobre identificação, proveniência, integridade, completude, licenciamento, vulnerabilidades e estrutura; perfis compliance para CISA 2026, NTIA 2021, BSI TR-03183-2 v1.1 a v2.1.0, FSCT v3 e OpenChain Telco	Ver componentes em falta	v2.1.3, outubro de 2026; perfil CISA 2026 desde a v2.1.0, corrigido na v2.1.2
sbom-scorecard	Uma pontuação ponderada da conformidade com a especificação, da informação de geração, e dos identificadores, versões e licenças dos pacotes	Perfis de frameworks	0.0.7, abril de 2023, a última versão

Até agora, só o sbomqs verifica os CISA 2026 Minimum Elements. Consulte as notas de versão de cada ferramenta antes de confiar num perfil: no sbomqs 2.1.1, a opção CISA 2026 executava por engano a verificação de 2021. Para a BSI TR-03183-2 v2.1.0 no sbomqs, use --bsi-v21 ou --bsi; --bsi-v2 verifica a v2.0.0.

Um passo mínimo de receção para a SBOM CycloneDX de um fornecedor:

# 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 do NTIA Conformance Checker. Leia o relatório de conformidade e rejeite o ficheiro nas verificações que o seu requisito torna obrigatórias; devolva-o ao fornecedor com as frases de feedback acima.

Incluir nos requisitos para fornecedores

Uma checklist que o fornecedor nunca viu não é um requisito. Coloque-a no anexo do contrato:

• O framework e a versão: por exemplo "BSI TR-03183-2 v2.1.0" ou "CISA 2026 Minimum Elements". Indique um; não escreva "norma da indústria".
• O formato e a versão mínima da especificação: por exemplo CycloneDX 1.6 ou posterior, ou SPDX 3.0.1 ou posterior, em JSON.
• Os campos que acrescenta, como hashes SHA-512 ou package URL para cada pacote.
• Entrega: uma SBOM por versão de software entregue, antes ou juntamente com o software.
• A validação que o fornecedor executa antes de enviar, identificada pela ferramenta e pelo perfil.
• O ciclo de feedback: quem recebe o feedback, e em que prazo é devida uma SBOM corrigida.

O lado do fornecedor do mesmo acordo está no guia de SBOM para fornecedores. Para um fornecedor de software que responde a um pedido pontual, consulte pedidos de SBOM de clientes.

Corrigir uma SBOM reprovada (para fornecedores)

• Ficheiros escritos à mão. Use um gerador ou uma biblioteca de SBOM, nunca um editor de texto.
• Package URL em falta. Gere-os a partir do gestor de pacotes ou do build, não à mão. Um purl escrito à mão é um purl adivinhado.
• Licenças em falta. Retire a licença declarada dos metadados do pacote, como identificador SPDX.
• Sem hashes. Calcule-os sobre os ficheiros que efetivamente entrega, no fim do build.
• A versão errada. Gere a SBOM no build da versão e dê-lhe o nome da versão.
• Apenas o nível superior. Use um método que resolva as dependências transitivas.

A forma mais fiável de corrigir a completude e os identificadores em simultâneo é gerar a SBOM a partir do build que produziu o software entregue. Consulte SBOM em tempo de build e boas práticas de SBOM.

De onde vêm as boas SBOM, e onde entra o CRACI

Para fornecedores que compilam no GitHub Actions, o CRACI substitui os runners alojados pelo GitHub e regista a SBOM durante o build, pelo que esta indica o que o build efetivamente trouxe.

• Cada pacote com um package URL, e cada componente com a sua licença declarada.
• Dependências transitivas, a todas as profundidades que o build alcançou.
• Um estado de completude para cada job, que responde à questão das incógnitas conhecidas por build: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.
• Exportada como CycloneDX ou SPDX; a API de SBOM devolve CycloneDX 1.7 JSON.

Para uma organização de engenharia inteira, consulte normalizar a geração de SBOM, e para Linux embarcado, porque é que os scanners não veem o que está nos builds Yocto.

Para OEM, é possível adicionar SBOM de terceiros ao CRACI, para que os componentes comprados sejam monitorizados quanto a novas vulnerabilidades juntamente com os seus próprios builds. Consulte ferramentas de gestão de SBOM para ver como isso se compara.

Quando o CRACI não é a resposta

• Validar e pontuar as SBOM que recebe. O CRACI não oferece um validador de SBOM nem uma pontuação de qualidade. Use as ferramentas acima.
• Fornecedores sem CI, ou cujo código é gerado por ferramentas baseadas em modelos sem obtenção de pacotes. Um gravador de builds acrescenta pouco; uma SBOM validada a partir de uma biblioteca geradora é a resposta realista.
• Firmware que só recebe como binário. A análise binária responde a isso.
• SBOM assinadas, a author signature da CISA 2026. O CRACI não assina SBOM.

Qualidade e validação de SBOM: perguntas frequentes

Como verifico a qualidade de uma SBOM que um fornecedor me enviou?

Teste três camadas. Valide o ficheiro face ao esquema, verifique os campos face a um framework identificado, como a BSI TR-03183-2 ou os CISA 2026 Minimum Elements, e depois teste a completude: compare-a com uma análise binária do que recebeu e procure os componentes que o tipo de produto tem de conter.

Que campos tem uma SBOM de conter?

Depende do framework que indicar. Os 2026 Minimum Elements da CISA enumeram 17 campos, incluindo autor, carimbo temporal, ferramenta, contexto de geração e, por componente, nome, versão, produtor, identificadores, hash e licença. A BSI TR-03183-2 acrescenta um hash SHA-512, o nome de ficheiro e as propriedades do ficheiro, e torna-os obrigatórios.

O que mudou entre os minimum elements da NTIA e os 2026 Minimum Elements da CISA?

A lista de 2026 da CISA substitui os sete campos da NTIA por 17. São novos a author signature, o nome e a versão do formato de dados, o contexto de geração, o nome e a versão da ferramenta, a versão da SBOM, o valor e o algoritmo de hash do componente e a licença do componente. Supplier name passou a Component Producer, e a profundidade passou a cobertura.

O que exige a BSI TR-03183-2 numa SBOM?

A versão 2.1.0 exige CycloneDX 1.6+ ou SPDX 3.0.1+ em JSON ou XML, uma SBOM por versão de software, dependências recursivas com a respetiva completude declarada e, por componente, criador, nome, versão, nome de ficheiro, licenças, hash SHA-512 e propriedades do ficheiro, com um package URL ou CPE se existir.

Uma SBOM precisa de hashes? Com que algoritmo?

A NTIA recomendava-os; a CISA 2026 torna o hash um elemento mínimo, com um algoritmo aprovado por uma autoridade como o NIST; a BSI TR-03183-2 exige SHA-512 de cada componente implementável. Peça SHA-512 e compare-o com o ficheiro que recebeu.

Preciso de um CPE e de um PURL?

Nem sempre. Peça um package URL sempre que o ecossistema o tenha, e um CPE quando não tem, como em muitos componentes comerciais ou embarcados. A CISA 2026 pede pelo menos um identificador e todos os que forem conhecidos; a BSI exige cada um, se existir.

Como valido um ficheiro CycloneDX ou SPDX?

Para CycloneDX, cyclonedx-cli validate com --fail-on-errors, ou sbom-utility. Para SPDX, o comando Verify do SPDX tools-java, ou pyspdxtools para SPDX 2.2 e 2.3. Depois, execute um perfil de framework com o sbomqs ou o SPDX NTIA Conformance Checker.

O que é uma boa pontuação de qualidade de SBOM?

Não existe um limiar padrão, nem uma referência que possamos citar. Uma pontuação mede os campos presentes, não a completude: um ficheiro pode ter 9 em 10 e omitir metade do produto. Defina antes critérios de aprovação por verificação no seu requisito para fornecedores e acompanhe a pontuação como tendência.