SBOM em software é um inventário estruturado dos componentes que formam uma aplicação, serviço, firmware ou produto digital. Ele registra nomes, versões, relações de dependência e evidências suficientes para que alguém entenda do que o software é feito antes de uma vulnerabilidade virar emergência.
A imagem mais simples é a lista de ingredientes de um produto. A diferença é que software muda toda semana, usa dependências transitivas e pode combinar código próprio, open source, bibliotecas comerciais, modelos de IA, imagens de contêiner e serviços externos. Um SBOM em software útil precisa acompanhar essa realidade, não apenas gerar um arquivo bonito no fim do build.
Neste artigo
O inventário começa pelos metadados
Antes de listar componentes, o SBOM precisa dizer quem o gerou, quando foi gerado, com qual ferramenta, em qual estágio do ciclo de build e qual versão do próprio documento está sendo entregue. A orientação de 2026 publicada por NSA e CISA reforça elementos como versão do SBOM, assinatura do autor e hash de componentes.
Esses campos evitam um problema comum: receber um inventário sem saber se ele representa o código-fonte, o artefato compilado, a imagem entregue ao cliente ou uma dependência declarada que nunca foi empacotada. Para auditoria, essa diferença muda tudo.
Componentes precisam ser identificáveis
O núcleo de um SBOM em software é a identificação de cada componente. Nome e versão ajudam, mas raramente bastam. Componentes devem ter produtor, identificadores reconhecíveis, hashes quando aplicável, relação de dependência e informação de licença quando ela for necessária para uso, distribuição ou compra.
Hashes são especialmente úteis porque nomes podem variar. A mesma biblioteca pode aparecer com nome de pacote, módulo interno, artefato Maven, imagem OCI ou arquivo dentro de um bundle. O hash ajuda a comparar o que foi declarado com o que foi distribuído.
Relações importam mais que lista solta
Um inventário plano responde pouco. O valor aparece quando o SBOM mostra que um serviço usa uma biblioteca, que essa biblioteca traz outra dependência, que uma imagem contém determinado pacote e que um componente foi incluído em um estágio específico do build.
Essa hierarquia ajuda a priorizar vulnerabilidades. Se uma falha afeta uma dependência transitiva, o time precisa saber quais produtos carregam aquela dependência, se ela é executável no contexto do produto e se há mitigação. O post sobre mitigação de vulnerabilidades web mostra por que inventário e correção precisam andar juntos.
SBOM não resolve tudo sozinho
O SBOM não prova que o software é seguro. Ele também não substitui análise de código, hardening de infraestrutura, revisão de segredo, teste de build reprodutível ou resposta a incidente. Ele cria visibilidade para que essas atividades sejam possíveis com menos adivinhação.
Um inventário desatualizado pode atrapalhar mais do que ajudar. Por isso, o processo precisa definir quando gerar, onde armazenar, quem pode consultar, como compartilhar com clientes e como ligar o SBOM a alertas de vulnerabilidade. A biblioteca da CISA também relaciona SBOM com práticas como compartilhamento e VEX, usado para indicar se uma vulnerabilidade é explorável em determinado produto.
Critério prático para começar
Um caminho pragmático é escolher um produto, gerar o SBOM no pipeline, guardar o artefato com o release e testar uma pergunta concreta: se uma biblioteca crítica aparecer em exploração ativa, o time consegue descobrir em quais versões ela está, quem é o dono do produto e qual cliente precisa de correção?
Se a resposta depender de planilha manual, busca em repositório e memória de uma pessoa, o SBOM em software ainda não virou processo. O objetivo é fazer o inventário conversar com build, release, vulnerabilidades e operação.
