O que é uma SBOM?

O que significa SBOM?

SBOM significa software bill of materials, ou lista de materiais de software. O termo vem da indústria transformadora, onde uma lista de materiais enumera as peças que compõem um produto. A CISA descreve uma SBOM como um inventário aninhado, uma lista dos ingredientes que compõem os componentes de software.

A maior parte do código de uma aplicação moderna foi escrita por outras pessoas, e a maior parte desse código chega indiretamente: acrescenta um pacote e este traz dezenas de dependências transitivas. Uma SBOM regista tudo isso, para que possa responder à pergunta «estamos afetados?» sem ler um único repositório.

O que contém uma SBOM?

Uma SBOM útil tem duas partes: dados sobre a própria SBOM e dados sobre cada componente. Os 2026 Minimum Elements, publicados pela CISA, pela NSA e pelo FBI com parceiros internacionais a 29 de julho de 2026, substituem a lista da NTIA de 2021 e definem a base a que a maioria dos compradores se refere atualmente.

Parte	Campos
Sobre a SBOM	Autor e assinatura do autor, data e hora, nome e versão do formato de dados, nome e versão da ferramenta, versão da SBOM e contexto de geração
Sobre cada componente	Nome, versão, produtor, identificadores como um package URL, valor e algoritmo de hash, licença e relações de dependência

O contexto de geração importa mais do que parece. Indica quando a SBOM foi criada: antes do build, durante o build, a partir do artefacto final ou depois dele. Duas SBOM da mesma versão podem diferir exatamente por esse motivo. Consulte exemplos de SBOM para ver como são estes campos num ficheiro real.

Formatos de SBOM

Dois formatos cobrem quase todas as SBOM em uso. O CycloneDX, da OWASP, nasceu na área da segurança e descreve também vulnerabilidades e serviços. O SPDX, da Linux Foundation, nasceu na conformidade de licenças. Ambos podem conter os elementos mínimos, e a maioria das ferramentas escreve nos dois. Consulte CycloneDX vs SPDX para saber como escolher.

Porque são importantes as SBOM

• Resposta mais rápida a incidentes. Quando surge uma vulnerabilidade como a Log4Shell, a questão é saber quais dos seus produtos a contêm. Com SBOM, isso é uma pesquisa. Sem elas, é um projeto.
• Monitorização de vulnerabilidades após o lançamento. Um software que estava limpo quando foi distribuído pode estar vulnerável amanhã. Voltar a verificar as SBOM armazenadas face a novos avisos de segurança deteta isso sem recompilar nada.
• Risco de licenças. A licença declarada de cada componente revela termos copyleft ou comerciais antes de chegarem ao produto.
• Perguntas de clientes e reguladores. Os compradores pedem cada vez mais uma SBOM nos processos de aquisição, e vários enquadramentos esperam um inventário de componentes.

Quem precisa de uma SBOM?

Quem distribui software e quem tem de responder pelo que nele se encontra. A exigência costuma chegar por uma destas vias:

• Dispositivos médicos. A secção 524B da FDA exige uma SBOM para dispositivos cibernéticos nas submissões pré-comercialização.
• Produtos vendidos na UE. O Cyber Resilience Act pede uma SBOM aos fabricantes. Consulte requisitos e ferramentas de SBOM para o CRA.
• Contratação pública federal dos EUA. O memorando M-26-05 do OMB de janeiro de 2026 deixa a cada agência a decisão de a exigir ou não, pelo que deve contar com uma análise caso a caso.
• Software de pagamentos. O requisito 6.3.2 da PCI DSS 4.0 pede um inventário do software à medida e dos respetivos componentes de terceiros. Não prescreve uma SBOM, mas uma SBOM satisfaz essa necessidade.

Como gerar uma SBOM

Há três formas de criar uma SBOM, e o método determina o que acaba no ficheiro.

Método	O que lê	Lacuna típica
Analisar o código-fonte	Manifestos e lockfiles no repositório	Tudo o que o build obtém e que nenhum lockfile lista
Analisar o resultado	Uma imagem de contentor ou um binário final	O código compilado é ambíguo e as ferramentas de build não deixam rasto
Registar o build	O que o build efetivamente obteve durante a execução	Tráfego que contorna o registador, o que deve ser assinalado

Os geradores open source como o Syft, o Trivy e o cdxgen usam os dois primeiros métodos. Discordam entre si para o mesmo commit, porque cada um tem as suas próprias regras sobre o que ler. Para ver as opções lado a lado, consulte as melhores ferramentas de SBOM.

SBOM vs SCA vs VEX

• Uma SBOM é um inventário. Diz o que lá está, não se é seguro.
• A análise de composição de software é a análise. Encontra componentes e verifica os seus riscos, e muitas ferramentas de SCA produzem uma SBOM pelo caminho.
• O VEX é uma declaração sobre o impacto. Indica se uma vulnerabilidade conhecida afeta efetivamente o seu produto, o que reduz o ruído que uma SBOM, por si só, cria.

Gerar uma SBOM é a parte fácil

Um ficheiro que ninguém lê não muda nada. O valor está em manter uma SBOM por versão, monitorizá-las e conseguir encontrá-las quando é preciso. Esse trabalho é a gestão de SBOM, e as boas práticas de SBOM explicam como o conduzir.

Como o CRACI cria SBOM

O CRACI é um runner de GitHub Actions que regista cada pacote que cada job obtém, a qualquer profundidade da árvore e incluindo pacotes restaurados de caches de CI. O resultado é uma SBOM do build que produziu a versão, com um estado de completude que indica o que o job não conseguiu ver. É exportada em CycloneDX ou SPDX, e o CRACI continua a reavaliá-la à medida que são publicadas novas vulnerabilidades. Consulte geração de SBOM durante o build.

SBOM: perguntas frequentes

O que é uma SBOM, em termos simples?

Uma SBOM é uma lista de ingredientes para software. Identifica cada componente de um produto, com a sua versão, o seu produtor e a sua licença, num formato que as máquinas conseguem ler.

O que significa SBOM?

SBOM significa software bill of materials, ou lista de materiais de software.

Porque é que precisa de uma SBOM?

Para saber rapidamente se uma vulnerabilidade recém-publicada afeta o que distribui, ver o risco de licenças antes do lançamento e responder aos clientes e reguladores que perguntam o que está no seu produto.

Quais são os dois principais formatos de SBOM?

CycloneDX e SPDX. O CycloneDX vem da OWASP e nasceu na área da segurança. O SPDX vem da Linux Foundation e nasceu na conformidade de licenças. Ambos podem conter os elementos mínimos.

Uma SBOM é obrigatória por lei?

Depende do produto e do mercado. A secção 524B da FDA exige uma para dispositivos cibernéticos, e o Cyber Resilience Act da UE pede uma aos fabricantes. Na contratação pública federal dos EUA, a decisão cabe agora a cada agência. Para muitas outras empresas, é uma exigência dos clientes e não uma exigência legal.

Com que frequência deve uma SBOM ser atualizada?

Gere uma nova SBOM para cada versão, porque cada build pode trazer versões diferentes. A SBOM de uma versão não muda depois disso, mas deve continuar a verificá-la face a novas vulnerabilidades.

Quem cria a SBOM?

Normalmente, a equipa que compila o software, idealmente na CI, para que cada versão receba uma automaticamente. O software que compra deve vir acompanhado de uma SBOM do fornecedor.