SBOM na prática: CycloneDX, SPDX, VEX e o que seus clientes vão pedir

SBOM, sigla em inglês para Software Bill of Materials, é a lista de ingredientes de um software. Assim como um rótulo de alimento diz o que há dentro da embalagem, o SBOM diz quais bibliotecas, em quais versões, de quais fornecedores e com quais licenças compõem uma aplicação.

Por anos, isso foi uma boa prática de nicho. Hoje, é requisito em contratos com bancos, governos e grandes empresas, e passou a ser exigido por lei para produtos com elementos digitais vendidos na União Europeia.

O que um SBOM contém

Um SBOM mínimo, segundo as diretrizes mais usadas no mercado, traz para cada componente:

• Nome do fornecedor
• Nome e versão do componente
• Identificadores únicos, como PURL (pkg:npm/[email protected]) e CPE
• Relação de dependência (quem depende de quem)
• Autor do SBOM e data de geração

SBOMs úteis vão além e incluem licenças, hashes dos artefatos, origem (registro, repositório) e propriedades de build.

CycloneDX ou SPDX?

Os dois formatos são padrões abertos e maduros. A escolha costuma ser ditada por quem vai consumir o SBOM.

Recomendação prática: gere os dois. Ferramentas modernas exportam ambos a partir do mesmo inventário, e você entrega o que o cliente pedir. A TransiTax Security exporta CycloneDX 1.6 e SPDX 2.3 por repositório, por imagem de container e por release.

VEX: a resposta para "vocês estão afetados?"

Todo SBOM atrai a mesma pergunta do cliente: "vi que vocês usam a biblioteca X, que tem a CVE Y. Estão vulneráveis?". Responder por email, CVE por CVE, não escala.

VEX (Vulnerability Exploitability eXchange) é um documento que declara, de forma legível por máquina, o status de cada vulnerabilidade no seu produto:

• Não afetado, com justificativa (por exemplo, o código vulnerável não é alcançável)
• Afetado, com ação recomendada
• Corrigido, com a versão que resolve
• Em investigação

{
  "vulnerability": { "id": "CVE-2025-XXXXX" },
  "analysis": {
    "state": "not_affected",
    "justification": "code_not_reachable",
    "detail": "A função afetada não é chamada por nenhum caminho da aplicação."
  },
  "affects": [{ "ref": "pkg:npm/[email protected]" }]
}

A justificativa "código não alcançável" vem diretamente da análise de alcançabilidade do SCA. É aí que o SBOM deixa de ser burocracia e vira ferramenta de comunicação com clientes.

Quem está exigindo SBOM

• Cyber Resilience Act (União Europeia): o regulamento entrou em vigor em dezembro de 2024. As obrigações de reporte de vulnerabilidades exploradas passam a valer em setembro de 2026, e as obrigações principais, incluindo documentação técnica com SBOM, em dezembro de 2027. Vale para empresas brasileiras que vendem produtos com elementos digitais na Europa.
• Governo dos Estados Unidos: fornecedores de software para o governo federal precisam atestar práticas de desenvolvimento seguro e fornecer SBOM quando solicitado.
• Setor financeiro: bancos e seguradoras incluem SBOM em questionários de due diligence de fornecedores de tecnologia.
• PCI DSS 4.0: o requisito 6.3.2 pede inventário de software sob medida e de componentes de terceiros. Veja PCI DSS.
• Clientes enterprise: cada vez mais pedem SBOM no processo de compra, junto com relatório de pentest.

Como gerar SBOM de forma confiável

1. Gere no build, não à mão. O SBOM deve refletir exatamente o que foi empacotado. Gere a partir dos lockfiles e da imagem final, no CI.
2. Inclua a imagem de container. Pacotes do sistema operacional (apt, apk, rpm) fazem parte do produto. Um SBOM só do package.json está incompleto. Veja imagens de container.
3. Versione junto com o release. Anexe o SBOM como artefato de cada versão publicada, para responder "o que havia na versão 3.2.1?".
4. Assine. Assinatura e atestado de proveniência garantem que o SBOM não foi alterado.
5. Monitore depois de gerar. Um SBOM parado envelhece. Novas CVEs surgem para componentes antigos; o inventário precisa ser cruzado continuamente com bases de vulnerabilidades.

SBOM de fornecedores

O SBOM também funciona no sentido contrário: peça aos seus fornecedores de software. Importando o SBOM deles numa plataforma de SCA, você passa a monitorar as vulnerabilidades dos componentes de terceiros que roda, algo essencial para gestão de risco da cadeia de suprimentos, como pede o controle 5.21 da ISO 27001.