SBOM para Empresas: Guia de Implementação

Aprenda a implementar SBOM para mapear componentes, responder a vulnerabilidades, avaliar fornecedores e fortalecer a segurança da cadeia de software.

O que é SBOM e por que empresas precisam dela?

SBOM para empresas é um inventário estruturado e legível por máquina dos componentes que formam um software. A sigla significa Software Bill of Materials. O documento identifica bibliotecas, pacotes, módulos e relações de dependência associados a uma versão específica de uma aplicação ou produto.

Na prática, a SBOM ajuda a responder com rapidez: “usamos este componente vulnerável?”, “em quais sistemas e versões ele aparece?”, “quem forneceu o pacote?”, “qual licença está associada?” e “qual produto precisa ser analisado primeiro?”. Sem esse inventário, a equipe depende de buscas manuais em repositórios, imagens de contêiner, servidores e planilhas que podem não representar o que foi realmente entregue.

O glossário do NIST define SBOM como um registro formal dos componentes e das relações de cadeia de suprimentos usados na construção de software. O valor, portanto, não está em produzir mais um arquivo: está em conectar a composição de cada versão a vulnerabilidades, fornecedores, ativos implantados e decisões de risco.

O que uma SBOM faz — e o que não faz

Uma SBOM fornece transparência sobre composição. Ela pode apoiar:

triagem de vulnerabilidades;
resposta a incidentes;
gestão de componentes open source e comerciais;
análise de licenças;
avaliação de fornecedores;
investigação de versões afetadas;
evidências de desenvolvimento seguro;
planejamento de atualização e fim de suporte.

Mas a SBOM não prova que o software é seguro. Ela não encontra automaticamente toda vulnerabilidade, não valida a qualidade do código próprio e não determina se uma falha conhecida é explorável no contexto do produto. Um componente listado pode estar presente sem que a função vulnerável seja usada; outro pode ter sido incorporado de forma que a ferramenta de geração não detectou.

Também não substitui testes de segurança, gestão de vulnerabilidades, assinatura de artefatos ou monitoramento. Ela é uma base de informação que torna esses processos mais rápidos e verificáveis.

Quando priorizar SBOM para empresas

A adoção costuma gerar mais valor quando a organização:

desenvolve ou mantém aplicações próprias;
entrega software a clientes;
usa muitos componentes de terceiros;
opera contêineres, aplicativos móveis ou firmware;
precisa responder a questionários de segurança;
compra sistemas críticos de fornecedores;
atende requisitos contratuais ou regulatórios;
demora para localizar componentes vulneráveis;
não consegue relacionar uma dependência ao ambiente implantado.

O escopo deve começar por sistemas críticos, produtos entregues externamente ou aplicações com alta exposição. Tentar gerar inventário de tudo sem definir quem irá consumir os dados costuma criar um repositório volumoso e pouco acionável.

Para conectar inventário, risco e evidências, a Mattos Tech Solutions atua em governança e compliance de TI, desenvolvimento de software sob medida e assessment de TI.

Quais dados precisam entrar na SBOM

A referência mais recente da CISA sobre elementos mínimos de SBOM organiza a base em campos de dados, suporte à automação e práticas e processos. Uma implementação empresarial deve, no mínimo, conseguir identificar o documento, o produto alvo e seus componentes sem depender de interpretação manual.

Campos úteis incluem:

autor, ferramenta, versão e horário de geração;
nome, versão e produtor do componente;
identificadores estáveis, como Package URL quando aplicável;
hash criptográfico do componente ou artefato;
licença declarada ou concluída;
relação entre o produto e a dependência;
dependências diretas e transitivas;
contexto em que o inventário foi criado;
versão exata do produto representado;
indicação de componentes sem informação suficiente.

Completude também precisa ser explícita. Se a ferramenta cobre pacotes da aplicação, mas não o sistema operacional da imagem, a SBOM deve registrar esse limite. “Sem vulnerabilidades encontradas” não equivale a “todos os componentes foram identificados”.

SBOM de fonte, build, análise ou execução

A SBOM pode representar momentos diferentes do ciclo de vida:

Design e fonte

Mostra dependências planejadas ou declaradas em arquivos de projeto e lockfiles. É útil cedo no desenvolvimento, mas pode incluir pacotes que não chegam ao artefato final ou omitir componentes adicionados durante o build.

Build

É gerada durante a criação do artefato e tende a representar melhor aquilo que foi efetivamente produzido. Para software entregue, costuma ser um ponto de partida forte porque pode ser vinculada ao identificador e ao hash da versão.

Análise do artefato

Examina binários, imagens de contêiner, pacotes ou sistemas de arquivos depois da construção. Ajuda a descobrir componentes incorporados, mas depende da capacidade de reconhecimento e pode perder contexto de origem.

Implantação e runtime

Representa o que está instalado ou observado em execução. É útil para responder “onde está rodando?”, inclusive quando plugins e dependências são carregados dinamicamente.

Nenhum tipo é universalmente completo. Uma empresa pode combinar SBOM de build com análise do artefato e inventário do ambiente, reconciliando divergências. A especificação SPDX distingue tipos de SBOM para que o consumidor saiba quais conclusões os dados permitem.

CycloneDX ou SPDX?

CycloneDX e SPDX são padrões abertos, não simples extensões de arquivo. Ambos podem representar composição e relações, mas possuem histórias e ecossistemas diferentes.

O CycloneDX foi projetado para aplicações de segurança da cadeia de suprimentos e possui modelos para diferentes tipos de BOM, componentes, serviços, vulnerabilidades e evidências.

O SPDX é um padrão internacional aberto, com forte cobertura de composição, proveniência, licenças, integridade e relações. Sua especificação atual também abrange outros domínios além do inventário tradicional de software.

Não escolha apenas pelo número de campos. Avalie:

formatos aceitos por clientes e fornecedores;
suporte das linguagens e ferramentas usadas;
validação disponível;
capacidade de preservar relações transitivas;
integração com gestão de vulnerabilidades;
assinatura e distribuição;
maturidade operacional da equipe;
necessidade de interoperabilidade.

Converter formatos não corrige uma SBOM incompleta.

Como implementar SBOM em oito etapas

1. Defina o caso de uso e o consumidor

Escolha uma decisão concreta: responder a vulnerabilidades críticas, atender contratos, avaliar fornecedores ou controlar licenças. Defina quem usará o inventário, em qual sistema e com qual prazo de resposta.

2. Selecione produtos e versões críticas

Comece com poucos sistemas representativos. Registre o proprietário, repositório, pipeline, artefato, ambientes e modelo de distribuição. Um mesmo produto precisa de SBOM distinta por versão quando sua composição muda.

3. Escolha o ponto de geração

Prefira geração automatizada no pipeline e próxima do build. Arquivos de manifesto e lockfiles ajudam, mas o artefato produzido deve ser verificado. Para componentes não cobertos, complemente com análise posterior.

4. Vincule a SBOM ao artefato

Armazene hash, versão, commit e identificador do pacote, imagem ou binário. A equipe deve conseguir provar qual SBOM representa exatamente o que foi liberado. Gerar um inventário da branch principal depois do deploy não oferece essa garantia.

5. Valide formato e qualidade

Valide o schema do padrão e crie testes para campos obrigatórios, componentes sem versão, identificadores ausentes, relações quebradas e quedas inesperadas na quantidade de dependências. Compare ferramentas em uma amostra conhecida para entender cobertura e diferenças.

6. Preserve, assine e controle acesso

Guarde a SBOM como artefato imutável da versão, com retenção compatível com o ciclo de suporte. Assinaturas ou atestações podem proteger integridade e origem. Defina quem pode publicar, corrigir, consultar e compartilhar.

7. Consuma os dados

Envie o inventário para o processo que correlaciona componentes com fontes de vulnerabilidade, ativos e responsáveis. Abra ações somente depois de confirmar produto, versão, alcance e prioridade. O guia NIST SSDF recomenda manter dados de proveniência dos componentes e integridade do software como parte das práticas de desenvolvimento seguro.

8. Incorpore ao ciclo de mudança

Uma nova versão deve gerar nova SBOM. Alterações de dependência precisam passar por revisão, e componentes fora de suporte devem acionar decisões. O inventário também deve alimentar incidentes, renovações contratuais e avaliação de risco.

Como usar VEX sem esconder risco

VEX, ou Vulnerability Exploitability eXchange, comunica o status de uma vulnerabilidade em relação a um produto. Ele complementa a SBOM: o inventário diz quais componentes existem; o VEX informa se uma vulnerabilidade está em análise, afeta o produto, foi corrigida ou não o afeta.

A orientação da CISA sobre requisitos mínimos de VEX enfatiza informação legível por máquina sobre produto, vulnerabilidade, status e justificativa.

Uma declaração “não afetado” precisa de evidência. Razões aceitáveis podem envolver componente ausente, código vulnerável não presente, caminho não executável ou mitigação inline. A justificativa deve ser revisada quando o produto, o ambiente ou o conhecimento sobre a falha mudar.

VEX não deve ser usado para encerrar alertas em massa sem investigação. Registre autor, evidências, validade, versão do produto e responsável pela decisão.

SBOM recebida de fornecedores

Solicitar um arquivo no contrato é apenas o começo. Defina:

produtos e versões cobertos;
formato e versão aceitos;
campos e identificadores mínimos;
frequência e eventos de atualização;
entrega de VEX e avisos de segurança;
canal e controle de acesso;
período de suporte;
tratamento de componentes sem manutenção;
prazo de resposta a vulnerabilidades;
permissão para validação;
procedimento no encerramento do contrato.

A SBOM do fornecedor precisa ser relacionada aos ativos realmente usados pela empresa. Caso contrário, uma lista extensa não ajuda a saber se a versão vulnerável está implantada. Veja também o guia de gestão de fornecedores de TI.

Proteja o próprio inventário

Uma SBOM pode revelar tecnologias, versões, arquitetura e componentes desatualizados. Isso não significa que deva permanecer inutilizável, mas que a distribuição precisa ser proporcional ao risco.

Separe conteúdo público, informação compartilhada sob contrato e dados internos. Use autenticação, autorização, criptografia, registro de acesso e expiração de links. Evite enviar versões conflitantes por e-mail. Mantenha uma origem controlada e mecanismos para revogar ou substituir um documento incorreto.

A assinatura protege integridade e autoria, não confidencialidade. Também não garante que a geração cobriu todo o produto.

Métricas que indicam valor operacional

Métricas úteis incluem:

percentual de produtos críticos com SBOM por versão;
percentual de builds que geram e validam SBOM;
cobertura de dependências diretas e transitivas;
componentes sem versão ou identificador;
tempo para localizar produtos afetados por um novo CVE;
tempo para produzir uma avaliação VEX;
SBOMs recebidas e validadas de fornecedores críticos;
versões implantadas sem inventário correspondente;
componentes sem suporte;
exceções abertas e vencidas.

Não use apenas a quantidade de componentes como indicador de maturidade. Crescimento pode significar melhor cobertura, aumento desnecessário de dependências ou mudança de ferramenta.

Erros comuns

Os erros mais frequentes são:

gerar a SBOM uma única vez;
depender apenas do manifesto da aplicação;
não incluir dependências transitivas;
misturar versões do produto;
não vincular documento e artefato;
aceitar campos vazios sem registrar limites;
transformar todo componente em alerta urgente;
ignorar licenças e componentes comerciais;
armazenar inventários sem consumidores;
publicar detalhes sensíveis sem controle;
confiar em “não afetado” sem evidência;
exigir de fornecedores o que a própria empresa não consegue processar.

Uma implementação madura reduz incerteza. Se o volume de alertas cresce e o tempo de resposta não melhora, o fluxo de consumo precisa ser redesenhado.

Plano de adoção em 90 dias

Dias 1 a 30: provar o fluxo

Escolha um produto, defina o caso de uso, gere SBOM de fonte e de build, compare resultados e documente lacunas. Selecione formato e identificadores.

Dias 31 a 60: automatizar e consumir

Inclua geração e validação no pipeline. Relacione a SBOM ao artefato, armazene-a por versão e conecte componentes ao processo de vulnerabilidades. Teste uma investigação real.

Dias 61 a 90: governar e ampliar

Defina retenção, acesso, assinatura, VEX, métricas e requisitos de fornecedores. Expanda para outro produto com tecnologia diferente e revise o padrão. O artigo sobre pipeline CI/CD seguro ajuda a organizar essa automação.

Checklist de SBOM para empresas

Antes de ampliar a adoção, confirme:

existe um caso de uso e um responsável;
cada SBOM identifica produto e versão;
componentes diretos e transitivos são cobertos;
o contexto de geração está registrado;
formato e campos são validados;
documento e artefato estão vinculados;
inventários são preservados por versão;
acesso e compartilhamento são controlados;
vulnerabilidades chegam aos responsáveis;
decisões VEX possuem evidência;
fornecedores críticos têm requisitos definidos;
métricas avaliam cobertura e tempo de resposta;
exceções possuem prazo e aprovação.

Para estruturar o processo junto à gestão de risco, fale com a Mattos Tech Solutions.

Conclusão

SBOM para empresas transforma a composição do software em informação operacional. O benefício aparece quando cada versão gera um inventário confiável, vinculado ao artefato e consumido por segurança, desenvolvimento, compras e resposta a incidentes.

Comece por um produto crítico, valide a cobertura, automatize no build e conecte os componentes ao processo de gestão de vulnerabilidades. A SBOM não elimina o risco da cadeia de software, mas reduz o tempo entre uma nova informação e uma decisão fundamentada.