Recebi uma SBOM de um fornecedor. Agora o que faço com ela?

O fornecedor concluiu uma entrega e enviou junto um arquivo como bom.json ou sbom.spdx.json.

A primeira reação costuma ser positiva: finalmente existe uma lista estruturada dos componentes usados no software.

A segunda pergunta é mais difícil:

Agora o que fazemos com isso?

Uma SBOM não reduz risco apenas por existir.

Seu valor aparece quando a organização consegue validar o documento, relacioná-lo ao software recebido, enriquecer os dados e transformar o inventário em decisões de segurança, operação, suporte e resposta.

Comece pela identidade: essa SBOM pertence ao software que recebi?

Antes de procurar CVEs, existe uma pergunta mais básica.

A SBOM precisa corresponder ao produto, versão e artefato que está sendo avaliado.

Verifique, quando disponíveis:

• Nome do produto;
• Versão;
• Fornecedor;
• Data de geração;
• Identificadores dos componentes;
• Relações entre componentes;
• Hashes;
• Versão do formato;
• Ferramenta ou processo de geração;
• Referência ao artefato ou release correspondente;
• Informações de proveniência;
• Mecanismo de assinatura ou atestado, quando disponível;
• Evidências de integridade e autenticidade da SBOM.

Se o fornecedor entregou a versão 5.4.2 do produto, mas a SBOM representa a 5.3.9, a análise pode estar tecnicamente correta, mas operacionalmente inútil.

O mesmo vale para SBOM gerada a partir de um manifesto que não reflete o artefato final.

SPDX ou CycloneDX não é a primeira decisão

SPDX e CycloneDX são formatos amplamente usados para representar composição e informações relacionadas.

Enquanto o SPDX é um padrão aberto internacional cuja linha 3.x amplia o modelo para diferentes tipos de BOM, o CycloneDX oferece capacidades específicas projetadas para SBOM, VEX e outros inventários técnicos.

A escolha do formato importa para interoperabilidade, ferramentas e detalhes disponíveis, mas o consumidor deveria evitar transformar a discussão em:

Qual formato é melhor?

antes de responder:

O documento possui os dados que precisamos para tomar a decisão?

Uma SBOM incompleta em um formato excelente continua incompleta.

Verifique a profundidade da composição

Um dos primeiros controles é avaliar se o inventário representa apenas componentes de primeiro nível ou também dependências transitivas.

Considere:

Aplicação
└── biblioteca A
    └── biblioteca B
        └── biblioteca C

Se a SBOM apresenta somente biblioteca A, uma vulnerabilidade ou problema de suporte na biblioteca C pode permanecer invisível.

O CRA europeu estabelece, em seus requisitos de vulnerability handling, que fabricantes identifiquem e documentem vulnerabilidades e componentes, incluindo por meio de SBOM em formato comumente usado e legível por máquina cobrindo pelo menos as dependências de primeiro nível.

Esse é um mínimo regulatório específico do CRA, não necessariamente o nível de detalhe suficiente para todos os casos de risco.

Para segurança operacional, dependências transitivas frequentemente são necessárias.

Uma SBOM não é uma lista de CVEs

É importante separar composição de inteligência.

A SBOM responde principalmente:

O que existe neste software?

A análise de vulnerabilidades responde:

O que sabemos hoje sobre riscos conhecidos nesses componentes?

Esses dados mudam em ritmos diferentes.

Uma SBOM pode permanecer igual enquanto uma nova vulnerabilidade é publicada amanhã.

Por isso, o modelo correto não é analisar o arquivo uma vez e arquivá-lo. É manter a composição ligada a fontes atualizadas de:

• Vulnerabilidades;
• Malware;
• Licenças;
• EOL/suporte;
• Advisories do fornecedor;
• Políticas internas.

1. 01SBOM recebidacomposição declarada pelo fornecedor
2. 02Validaçãoidentidade, versão, formato e relações
3. 03Enriquecimentovulnerabilidades, licenças, EOL e intelligence
4. 04ContextoVEX, exposição e uso real
5. 05Políticacritérios de aceitação e exceção
6. 06Decisãoaceitar, corrigir, bloquear ou escalar
7. 07Monitoramentoreavaliar quando surgem novos dados

Malware exige uma pergunta diferente

Uma SBOM pode ajudar a localizar um componente conhecido como malicioso, mas possuir a lista de componentes não equivale a realizar detecção de malware.

Por isso, vulnerabilidades, malware, integridade, procedência e confiança na origem precisam ser tratados como sinais complementares. Uma vulnerabilidade pode ser identificada por um identificador conhecido; já um componente comprometido ou malicioso exige outras fontes de inteligência e mecanismos de análise.

Na prática, a pergunta deixa de ser apenas “esse componente possui uma vulnerabilidade?” e passa a ser “esse componente é confiável, está íntegro, possui vulnerabilidades conhecidas e continua sendo aceitável para o nosso contexto?”

Esse ponto é aprofundado no artigo:

SCA identifica vulnerabilidades. Mas e malware?

Licença e suporte também fazem parte da decisão

A composição pode revelar componentes que:

• Usam licenças incompatíveis com a política da empresa;
• Possuem licença desconhecida;
• Chegaram ao fim de vida (EOL) ou ao fim de suporte (EOS/EOSL);
• Estão abandonados;
• Dependem de versões muito antigas;
• Não possuem caminho claro de atualização.

Uma SBOM operacional não deveria ser tratada somente como entrada para vulnerability scanning.

Ela pode apoiar decisões de segurança, jurídico/licenciamento, arquitetura, continuidade, procurement e gestão de fornecedores.

Onde o VEX entra

O VEX — Vulnerability Exploitability eXchange — existe para representar o status de uma vulnerabilidade no contexto de um produto.

Imagine que a SBOM identifique uma biblioteca associada a uma CVE crítica.

Isso não significa automaticamente que a vulnerabilidade seja explorável no produto final.

O componente pode não executar o código vulnerável, estar configurado de forma que a condição não exista, ter mitigação específica ou estar presente apenas em uma etapa que não chega ao runtime.

Uma declaração VEX pode registrar esse contexto.

O CycloneDX, por exemplo, possui suporte específico para representar exploitability por meio de VEX.

Mas o VEX não deve ser usado como um botão para “ignorar vulnerabilidade”.

Uma afirmação de not_affected deve possuir justificativa e contexto suficientes para sustentar a decisão, além de ser reavaliada quando houver mudanças relevantes no produto, componente ou condição de exploração.

O fornecedor deveria ser capaz de responder perguntas sobre a SBOM

Receber o arquivo não encerra a relação.

Um processo maduro de aquisição pode estabelecer perguntas como:

1. Qual produto e versão a SBOM representa?
2. Como ela foi gerada?
3. Ela cobre dependências transitivas?
4. Existe vínculo com o artefato entregue?
5. Qual é a frequência de atualização?
6. Como o fornecedor comunica novas vulnerabilidades?
7. O fornecedor publica VEX?
8. Como informa uma versão corrigida?
9. Qual é o período de suporte dos componentes críticos?
10. Existe canal de vulnerability disclosure?
11. Como mudanças de composição entre releases são comunicadas?

Essas respostas podem ser incorporadas ao processo de due diligence e gestão do fornecedor.

A SBOM precisa continuar útil depois da compra

Um erro comum é concentrar todo o esforço na entrada do software.

No dia da aquisição:

SBOM → análise → aceite

Depois, o arquivo fica armazenado e ninguém o consulta novamente.

O problema é que o risco muda.

Uma aplicação aprovada hoje pode ser afetada amanhã por nova CVE, nova evidência de exploração, pacote identificado como malicioso, EOL, mudança de licença, alteração de criticidade ou advisory do fornecedor.

Por isso, a relação deveria ser contínua:

1. 01Produtoversão e ownership conhecidos
2. 02SBOMcomposição ligada ao produto
3. 03Intelligencedados atualizados continuamente
4. 04Políticacritérios de risco e exceção
5. 05Responsáveldecisão e resposta

O CRA está acelerando a adoção — mas geração é apenas o começo

Em junho de 2026, a ENISA publicou seu relatório sobre o estado da adoção de SBOMs.

O levantamento apontou o Cyber Resilience Act (CRA) como um dos principais aceleradores das iniciativas de SBOM e de sua integração ao ciclo de desenvolvimento de software (SDLC).

O movimento regulatório contribui para ampliar a adoção e a padronização desses documentos.

Mas a própria evolução do ecossistema já mostra a etapa seguinte.

Em agosto de 2026, a Open Source Security Foundation (OpenSSF) anunciou o BOMHort como projeto Sandbox, voltado à visualização, governança e gerenciamento de SBOMs em escala.

A iniciativa evidencia um desafio que surge à medida que as organizações passam a trabalhar com grandes volumes de SBOMs: não basta gerar ou receber o documento; é preciso conseguir consultar, relacionar, analisar e utilizar essas informações operacionalmente.

Esse movimento sugere uma mudança importante: o desafio está migrando de gerar SBOM para operar SBOM em escala.

Um processo simples para começar

Não é necessário criar uma plataforma complexa no primeiro dia.

Uma organização pode começar com cinco etapas.

1. Receber

Definir formatos aceitos, canal e metadados mínimos.

2. Validar

Confirmar produto, versão, estrutura e qualidade do inventário.

3. Enriquecer

Cruzar a composição com vulnerabilidades, malware, licenças, suporte e outras fontes.

4. Decidir

Aplicar políticas e registrar aceite, correção, bloqueio ou exceção.

5. Monitorar

Reavaliar produtos existentes conforme novos dados surgem.

Checklist de consumo de SBOM

Antes de considerar uma SBOM “tratada”, verifique:

• Produto e versão correspondem à entrega;
• Formato é válido e processável;
• Componentes possuem identificadores úteis;
• Relações entre dependências estão presentes;
• Profundidade de dependências é conhecida;
• Composição foi cruzada com vulnerability intelligence;
• Malware foi considerado separadamente;
• Licenças foram avaliadas;
• EOL/suporte foi avaliado;
• VEX possui justificativa quando utilizado;
• Exceções têm responsável e validade;
• Existe mecanismo de atualização e monitoramento;
• A origem e autenticidade da SBOM foram verificadas, quando aplicável;
• A SBOM possui vínculo verificável com o artefato ou release analisado.

O teste decisivo

Escolha um software de terceiro que já esteja em produção.

Pegue a SBOM entregue pelo fornecedor e tente responder:

Se uma nova vulnerabilidade crítica for publicada amanhã em uma dependência transitiva desse produto, quem será avisado e quanto tempo levará para sabermos se estamos expostos?

Se a resposta for “precisamos abrir o arquivo e investigar manualmente”, a SBOM existe.

Mas ainda não virou governança operacional.

Fontes e referências

• ENISA — SBOM Adoption State of Play 2026
• EUR-Lex — Cyber Resilience Act, Regulation (EU) 2024/2847
• Comissão Europeia — Cyber Resilience Act: Manufacturers
• SPDX — Specifications
• CycloneDX — Vulnerability Exploitability eXchange (VEX)
• OpenSSF — Improving Risk Management Decisions with SBOM Data
• OpenSSF — Introducing BOMHort
• Xmart — Cyber Resilience Act: o que muda para empresas de software?

Sua organização recebe SBOMs, mas consegue transformá-las em decisão?

A Xmart apoia arquitetura, governança, análise e operação de controles de Software Supply Chain e AppSec.

Solicitar avaliação técnicaConhecer soluções Xmart →