O que é SBOM: o Software Bill of Materials explicado

SBOM (software bill of materials) é um inventário, legível por máquina, de tudo o que compõe o seu software: as bibliotecas open source e comerciais, as versões exatas, quem fornece cada uma e como elas dependem umas das outras. A CISA resume bem: um SBOM é "um inventário aninhado, uma lista de ingredientes dos componentes de software".

Parece papelada, e por anos foi tratado assim. Até que alguns incidentes grandes na cadeia de suprimentos tornaram caríssima uma pergunta simples: "Estamos rodando a versão vulnerável dessa biblioteca? Onde?" O SBOM é o arquivo que permite responder isso em minutos, não em semanas. Neste guia você vai ver o que vai dentro de um SBOM, por que os reguladores passaram a pedir, os dois formatos principais (CycloneDX vs SPDX), como gerar um e, tão importante quanto, o que um SBOM não faz.

O que é SBOM, exatamente

Pense no rótulo de uma embalagem de alimento. Ele lista os ingredientes, não diz se cada um faz bem para você. O SBOM faz o mesmo com software. Para cada componente, registra no mínimo nome, versão e um identificador, além das relações entre componentes: sua aplicação depende de um framework web, que depende de uma biblioteca de logging, que depende de outra coisa três níveis abaixo.

Em julho de 2021 a NTIA dos Estados Unidos publicou "The Minimum Elements For a Software Bill of Materials". Os campos básicos desse documento continuam sendo o melhor modelo mental do que um SBOM precisa ter:

• Fornecedor (supplier name): quem criou ou mantém o componente.
• Nome do componente e versão.
• Outros identificadores únicos, como um Package URL (purl) do tipo pkg:npm/[email protected] ou um CPE.
• Relação de dependência: qual componente inclui qual.
• Autor dos dados do SBOM e um timestamp.

Desde então a CISA vem trabalhando em uma atualização desses elementos mínimos, mas a ideia central não mudou: identificar cada componente com precisão suficiente para que uma máquina consiga cruzá-lo com uma base de vulnerabilidades ou uma lista de licenças.

Dependências diretas e transitivas

Seu package.json ou requirements.txt tem, digamos, 30 dependências diretas. O lockfile costuma ter centenas, porque cada uma traz as suas. Um SBOM útil captura a árvore inteira, porque uma vulnerabilidade não quer saber se você importou o pacote de propósito. Veja como fica um único componente em um SBOM CycloneDX em JSON:

{
  "type": "library",
  "name": "log4j-core",
  "version": "2.14.1",
  "purl": "pkg:maven/org.apache.logging.log4j/[email protected]",
  "licenses": [{ "license": { "id": "Apache-2.0" } }]
}

Por que o SBOM importa agora

Ataques à cadeia de suprimentos e o "onde isso nos afeta?"

Quando o Log4Shell (CVE-2021-44228) foi divulgado, em dezembro de 2021, a maioria dos times não teve dificuldade para entender o bug. Teve dificuldade para encontrá-lo. O Log4j muitas vezes era uma dependência transitiva escondida dentro de outra biblioteca, dentro de uma imagem de container, dentro de um serviço que ninguém mexia havia um ano. Quem tinha um inventário atualizado conseguiu pesquisar. O resto rodou grep nos repositórios e pediu para cada time verificar na mão.

Esse é o valor central do SBOM: transforma "estamos afetados?" de uma investigação em uma consulta. A mesma lógica vale para pacotes maliciosos, typosquatting e maintainers comprometidos. Você não consegue reagir a um risco em um componente que nem sabe que distribui. Por isso o SBOM anda junto com software composition analysis em qualquer programa sério de DevSecOps.

Executive Order 14028 nos Estados Unidos

Em 12 de maio de 2021 o governo dos Estados Unidos publicou a Executive Order 14028, "Improving the Nation's Cybersecurity". Um dos objetivos era reforçar a segurança da cadeia de suprimentos de software, e a ordem determinou que a NTIA publicasse os elementos mínimos de um SBOM, o que aconteceu em 12 de julho de 2021. Na prática, o SBOM deixou de ser uma boa prática de nicho e virou algo que compradores federais começaram a pedir aos fornecedores de software.

Cyber Resilience Act da União Europeia

O Cyber Resilience Act (CRA) entrou em vigor em 10 de dezembro de 2024. As obrigações de notificação de vulnerabilidades ativamente exploradas valem desde 11 de setembro de 2026, e as obrigações principais a partir de 11 de dezembro de 2027. O Anexo I, Parte II, exige que os fabricantes identifiquem e documentem os componentes dos seus produtos, inclusive elaborando um SBOM em formato de uso comum e legível por máquina, cobrindo pelo menos as dependências de primeiro nível. Se você vende software ou produtos conectados na UE, o SBOM está virando parte do produto, e não um extra.

Formatos de SBOM: CycloneDX vs SPDX

Dois formatos abertos dominam. Ambos são legíveis por máquina, ambos têm bom suporte, e para a maioria dos times a escolha importa menos do que gerar o SBOM. Mesmo assim, eles vêm de lugares diferentes.

SPDX

O SPDX (Software Package Data Exchange) é um projeto open source hospedado na Linux Foundation. Nasceu para compliance de licenças, e por isso traz a SPDX License List e a sintaxe de expressões de licença que hoje quase todo o ecossistema usa (MIT, Apache-2.0, GPL-3.0-or-later). A especificação é reconhecida como ISO/IEC 5962:2021. O SPDX 3.0, lançado em abril de 2024, adicionou perfis de Security, Build, Dataset e AI.

CycloneDX

O CycloneDX é conduzido pela OWASP Foundation e pelo comitê técnico TC54 da Ecma International, e é padronizado como ECMA-424. Foi desenhado com segurança como caso de uso principal. Além de SBOM, cobre SaaSBOM, CBOM (criptografia), HBOM (hardware), AI/ML-BOM e VEX (Vulnerability Exploitability eXchange), que serve para declarar se uma vulnerabilidade conhecida afeta ou não o seu produto.

Regra prática: se quem consome é o jurídico ou compras, o SPDX encaixa naturalmente. Se quem consome é um pipeline de gestão de vulnerabilidades, o CycloneDX costuma encaixar melhor. Se um cliente ou regulador pedir um formato específico, use esse. Ferramentas como o Syft geram os dois a partir do mesmo scan.

Como gerar um SBOM

Syft

O Syft, da Anchore, é um CLI que gera SBOMs a partir de imagens de container, filesystems e arquivos compactados, com suporte a dezenas de ecossistemas (npm, PyPI, Maven, Go, Cargo, Alpine, Debian, RPM e outros):

# SBOM de um diretório de código, em CycloneDX JSON
syft ./meu-projeto -o cyclonedx-json=./bom.cdx.json

# SBOM de uma imagem, nos dois formatos ao mesmo tempo
syft minha-app:1.4.2 -o spdx-json=./sbom.spdx.json -o cyclonedx-json=./bom.cdx.json

cdxgen

O cdxgen é um projeto da OWASP Foundation que gera BOMs CycloneDX a partir de caminhos locais, repositórios git, purls e imagens de container, e também exporta SPDX 3.0.1 em JSON-LD:

cdxgen -o bom.json .

Export do dependency graph do GitHub

Se o seu código está no GitHub, dá para exportar o dependency graph atual de um repositório como arquivo SPDX 2.3: abra o repositório, vá em Insights, depois Dependency graph, e clique em Export SBOM. Também existe um endpoint da REST API para o mesmo export, útil para automatizar. Lembre que ele reflete o que o dependency graph sabe a partir dos seus manifests e lockfiles, não o que acaba dentro do container que você constrói.

SBOM do código vs SBOM do build

Onde você gera o SBOM muda o que ele contém. Um SBOM de código, montado a partir dos lockfiles, mostra o que a sua aplicação declara. Um SBOM de build ou de imagem, montado a partir do artefato final, inclui também os pacotes do sistema operacional da imagem base e tudo o que for copiado durante o build. Para um serviço em produção, o SBOM da imagem fica mais perto da realidade. A boa prática é gerar no CI a cada release e guardar junto do artefato, para que cada versão entregue tenha o seu inventário.

Como usar um SBOM

Cruzamento com vulnerabilidades (CVE e OSV)

O SBOM fica útil quando você cruza com dados de vulnerabilidades. Duas opções open source leem arquivos SBOM diretamente:

# Grype: escanear um SBOM existente
grype sbom:./bom.cdx.json

# OSV-Scanner: cruzar um SBOM com a base OSV
osv-scanner scan source -L ./sbom.spdx.json

O OSV-Scanner reconhece SBOMs pelo nome do arquivo, então siga as convenções (*.spdx.json, bom.json, *.cdx.json). Como você guardou um SBOM por release, dá para reescanear versões antigas quando surge um CVE novo, sem recompilar nada. Esse é o ganho de trocar investigação por consulta.

Licenças

Cada componente pode ter um identificador de licença SPDX. Times jurídicos usam isso para encontrar licenças copyleft dentro de um produto proprietário, componentes sem licença ou termos que conflitam com a forma como você distribui o software.

Pedidos de clientes e reguladores

Cada vez mais questionários de segurança pedem SBOM, e o CRA vai exigir um como parte da documentação técnica. Junto com declarações VEX, o SBOM permite dizer a um cliente "sim, esse CVE está em um componente que distribuímos, mas a função vulnerável não é alcançável no nosso produto" de forma estruturada, em vez de uma troca interminável de e-mails.

Limites de um SBOM

• É uma foto. Um SBOM descreve um build em um momento. Todo dia saem CVEs novos contra componentes que ontem estavam limpos, então o valor está em cruzar de novo, não no arquivo em si.
• É tão bom quanto o gerador. Código vendorizado, trechos copiados, binários linkados estaticamente e passos de build customizados escapam fácil. Duas ferramentas podem gerar SBOMs diferentes para o mesmo projeto.
• Não diz nada sobre explorabilidade. Listar uma versão vulnerável não significa que o seu código chama a função vulnerável. Sem análise de alcançabilidade ou VEX, o time se afoga em achados que não importam.
• Não cobre o seu próprio código. Injeções, controle de acesso quebrado e o resto do OWASP Top 10 estão no código que você escreveu, e para isso você precisa de AI SAST ou outra análise estática (veja SAST e DAST).
• Não cobre segredos nem configuração. Uma API key vazada ou um workflow de CI com permissões demais nunca vão aparecer em um bill of materials. Isso é trabalho das ferramentas de detecção de segredos, como um secret scanner que também olhe o histórico do git, e das verificações de configuração.

Onde o Nurbak entra

Para deixar o escopo claro: o Nurbak não gera nem exporta arquivos SBOM. Se você precisa de um SBOM para um cliente ou para a documentação do CRA, use Syft, cdxgen ou o export do GitHub descritos acima.

O que o Nurbak faz é a parte que muitos times queriam do SBOM desde o começo: você conecta o GitHub, escaneia um repositório, e ele lê os lockfiles, cruza cada dependência com as vulnerabilidades conhecidas do OSV e reporta os pacotes vulneráveis junto com a versão corrigida para a qual atualizar. No mesmo scan, o próprio modelo de IA self-hosted do Nurbak analisa o seu código em busca de vulnerabilidades exploráveis com arquivo e linha (a análise não envia o seu código para a OpenAI nem para a Anthropic), aponta misconfigs de GitHub Actions, Docker, Terraform e Kubernetes e detecta segredos no código atual e no histórico do git, tudo resumido em um score de 0 a 100. O scan gratuito mostra completos os 3 achados mais importantes. Veja como funciona a parte de dependências na página de software composition analysis, ou rode o GitHub security scanner completo.

Resumindo

O SBOM é a lista de ingredientes do seu software. Ele não deixa o produto seguro sozinho, mas torna respondível em minutos a pergunta mais comum da cadeia de suprimentos, e a regulação dos dois lados do Atlântico está transformando o SBOM em expectativa mínima. Gere um por release no CI, escolha CycloneDX ou SPDX conforme quem vai consumir, cruze com dados de vulnerabilidades de forma contínua e lembre que o seu próprio código, os seus segredos e a sua configuração precisam das próprias verificações.

Leituras relacionadas

• Ferramentas de detecção de segredos: TruffleHog vs Gitleaks vs GitGuardian vs GitHub
• O que é DevSecOps
• SAST e DAST
• OWASP Top 10 2025