SBOM, supply chain e o novo padrão de confiança em software

Em dezembro de 2021, uma vulnerabilidade em uma biblioteca de log chamada Log4j parou parte da internet. Em março de 2024, uma backdoor plantada na utilidade de compressão xz quase comprometeu, em silêncio, milhões de servidores Linux antes de ser descoberta por acaso. Esses dois incidentes têm em comum uma pergunta que poucas organizações conseguem responder com precisão: "em quais dos meus sistemas isso roda?"

A resposta padrão hoje, no estado da arte, chama-se SBOM — Software Bill of Materials.

O que é uma SBOM

Uma SBOM é, literalmente, a lista de ingredientes de um software: cada biblioteca, cada componente, cada dependência transitiva, com nome, versão, licença e relação com os demais. É o equivalente, no software, da rotulagem nutricional na indústria de alimentos — algo que parece óbvio depois de existir, mas cuja ausência é tudo menos trivial.

Os dois formatos abertos mais usados:

CycloneDX — mantido pela OWASP, foco em segurança e supply chain.
SPDX — padrão ISO/IEC 5962:2021, foco original em conformidade de licenças, hoje cobre segurança também.

Os dois são suficientes; o importante é ter um.

Por que isso virou exigência, não preferência

A pressão regulatória sobre supply chain de software acelerou nos últimos anos:

Estados Unidos — a Executive Order 14028 (2021) tornou SBOM obrigatória para todo software vendido ao governo federal, com diretrizes técnicas detalhadas pelo NIST.
União Europeia — o Cyber Resilience Act (CRA), em vigor a partir de 2027, exige SBOM e gestão de vulnerabilidades para produtos com componentes digitais comercializados no bloco.
Brasil — o tema ainda não tem norma específica federal, mas referências em editais do TCU, Marinha e órgãos do SISP já começam a citar SBOM como evidência aceita para inventário de dependências. É questão de tempo virar exigência mais ampla.

Para empresas que vendem software para o governo (B2G) ou para o exterior (B2B internacional), SBOM já está no caminho crítico — falta só perceber.

O que uma SBOM responde — e o que ela não responde

Ela responde, em segundos:

"A vulnerabilidade X afeta quais dos nossos sistemas?"
"Estamos usando alguma versão da biblioteca Y?"
"Quantos dos nossos produtos têm dependência indireta de Z?"

Ela não responde, sozinha:

"Esta vulnerabilidade é explorável no contexto em que usamos a lib?"
"Esta dependência foi atualizada para a versão segura?"

Ou seja: SBOM é inventário, não avaliação. Para virar gestão de vulnerabilidades de fato, precisa estar conectada a feeds (NVD, OSV, GHSA) e a um processo que decide o que fazer com cada alerta. Sem essa cola, vira documentação que envelhece.

Como começar — sem montar um programa enorme

Quem nunca produziu SBOM costuma achar que precisa de ferramenta cara, equipe nova e processo formalizado. Não precisa. O mínimo viável tem três passos:

Gerar SBOM no pipeline de build — ferramentas abertas como syft, cdxgen e trivy produzem CycloneDX/SPDX em segundos para projetos Node, Python, Go, Java, containers Docker. Acoplado ao CI, vira artefato versionado a cada release.
Comparar contra fontes públicas de vulnerabilidade — grype, osv-scanner e similares cruzam a SBOM contra bancos de CVEs e devolvem o que está exposto. Sem ação humana ainda, só visibilidade.
Triagem documentada — alguém precisa decidir, para cada alerta: corrige, mitiga, aceita risco. Sem essa etapa, o relatório semanal vira ruído. Com ela, vira processo defensável.

Exemplo de geração com syft em um pipeline:

syft scan dir:. -o cyclonedx-json > sbom.json
grype sbom:sbom.json --fail-on high

Duas linhas. O resto é integrar com a ferramenta de CI e decidir o que fazer com o que aparece.

Onde isso encosta na sua operação

Três cenários onde SBOM deixa de ser "boa prática" e vira caminho crítico:

Você vende software para o governo — começou a aparecer "SBOM" em edital. Em dois anos, vai ser exigência padrão.
Você opera software contratado de terceiros — pode (e deve) exigir SBOM da contratada, a cada release. Sem isso, você opera sem saber o que tem.
Você precisa responder rápido a um incidente público — quando o próximo Log4j acontecer, a diferença entre "respondemos em 4 horas" e "demoramos duas semanas para mapear" é ter ou não SBOM versionada.

Como ajudamos

Em projetos típicos, conduzimos:

Implantação de SBOM no pipeline existente (não importa a stack), com saída CycloneDX padronizada.
Plug com gestão de vulnerabilidades — integração com banco público de CVEs, alertas com triagem mínima.
Cláusulas contratuais para exigir SBOM de fornecedores de software, com critério de aceite e periodicidade.

Se a sua organização está preparando edital, renegociando contrato ou simplesmente cansada de não saber o que está rodando, fale com a gente em /contato. Em até dois dias úteis, devolvemos um plano de implantação proporcional ao tamanho do seu parque.

Este post conversa diretamente com Auditabilidade de software contratado: SBOM é uma das evidências mínimas que todo contrato de software relevante deveria exigir.