Completude da SBOM

Uma SBOM está completa quando lista cada componente que entrou no software que descreve, em todos os níveis da árvore de dependências, incluindo os componentes que nenhum lockfile ou manifesto lista. A completude da SBOM é essa propriedade. Os 2026 Minimum Elements da CISA pedem aos autores de SBOM que indiquem explicitamente quando uma informação é desconhecida, e notam que os destinatários podem considerar uma SBOM incompleta se forem retidos dados essenciais dos componentes.

Completude, validade e qualidade são coisas diferentes

Pergunta	O que significa	O que a verifica	O que não consegue dizer
Válida	O ficheiro cumpre o esquema CycloneDX ou SPDX	Um validador de esquemas	Se faltam componentes
Qualidade dos campos	Cada componente tem nome, versão, fornecedor, identificador, licença e hash	Um avaliador de qualidade	Se faltam componentes
Completa	Não falta nada do que entrou no software	Uma comparação com o que o build recebeu realmente	Entradas que a comparação não viu

O identificador da segunda linha é normalmente um package URL ou um CPE. Um ficheiro pode passar perfeitamente nas duas primeiras verificações e deixar de fora metade do software.

Porque a completude é difícil de medir depois

Um scanner trabalha a partir de lockfiles, manifestos ou do resultado final. Não pode saber de um pacote transferido por um script post-install, de um crate compilado dentro de um binário ou de uma camada da imagem base que nunca lhe foi mostrada. Cada um deles é uma dependência oculta.

Pense num serviço Node.js cujo lockfile lista 400 pacotes. Um deles tem um script postinstall que transfere um binário pré-compilado durante npm ci. Uma SBOM gerada a partir de package-lock.json é válida, cada componente tem versão e package URL, e o binário não está lá. Nenhuma pontuação de qualidade o assinala, porque nada no ficheiro aponta para o que falta.

Reconstruir mais tarde também não resolve a questão: a menos que o build seja um build reprodutível, um segundo build pode receber algo diferente do primeiro.

Como indicar a completude com honestidade

• Indique o contexto de geração: se a SBOM foi criada a partir do código-fonte antes do build, registada durante o build ou produzida analisando o resultado depois.
• Liste as lacunas conhecidas: partes do software que a ferramenta não conseguiu ver, como código incorporado, binários pré-compilados ou componentes instalados fora de um gestor de pacotes.
• Prefira um estado com motivos a uma pontuação. Uma percentagem de completude exige um total, e esse total é exatamente o que ninguém conhece. Uma indicação como «incompleta: o job permitiu tráfego não monitorizado» permite agir.

Boas práticas de SBOM aborda de forma mais ampla a prática de indicar o que uma SBOM não conseguiu ver.

Estados de completude no CRACI

O CRACI atribui um estado de completude à SBOM de cada job, e as caches também recebem um. Os estados, tal como a documentação do CRACI os define:

• Complete: «O CRACI observou evidências completas do job, e cada cache restaurada estava completa».
• Complete with connections: «Os requisitos foram cumpridos, mas o job usou uma ou mais ligações de rede personalizadas».
• Incomplete: «O CRACI identificou uma condição que pode deixar dependências fora da SBOM».
• Unavailable: «O CRACI não conseguiu concluir a avaliação das evidências».
• Not recorded: «O job é anterior à indicação de completude».

O CRACI consegue indicá-lo porque vê o tráfego de cada job para as fontes de pacotes e sabe, portanto, quando algo pode ter passado ao lado: tráfego que não monitorizou, ou uma cache restaurada cuja própria SBOM estava incompleta. Quando um job está incompleto, mostra o motivo, por exemplo «Unmonitored traffic was allowed». Veja geração de SBOM.

Estes estados aplicam-se aos builds executados em runners do CRACI. Para uma SBOM de um fornecedor, ou de um pipeline que não corre no CRACI, use as comparações e as regras acima.