Software bill of materials (SBOM)

O que é um SBOM?

Um SBOM (Software bill of materials) é um registro estruturado dos componentes de um produto, das relações entre eles e dos metadados que identificam cada um sem ambiguidade. Ele responde a uma única pergunta operacional: se uma falha for anunciada no componente X, nós entregamos X, em qual versão e onde?

Essa pergunta parece trivial até que um prazo obrigue a respondê-la. Uma aplicação moderna é, em sua maior parte, código que outra pessoa escreveu e que sua equipe nunca revisou. Uma estimativa do setor citada na nossa página de análise de caminhos de chamada coloca o uso típico entre 10 % e 20 % do código importado, então a maior parte do que se traz nunca é executada. O SBOM que você gera é, portanto, longo, em grande parte inerte e impossível de guardar na cabeça.

Um SBOM só vale a pena se algo mais o lê. Uma lista de dependências de código aberto parada em um repositório não muda nada. A mesma lista, cruzada com uma fonte de vulnerabilidades e atualizada a cada build, transforma uma divulgação em uma ordem de serviço. Essa atualização é a linha que separa um inventário vivo de um documento de conformidade.

O que um SBOM não é

Quatro coisas são confundidas com frequência suficiente para valer a separação.

A distinção que custa mais caro às equipes é a das duas primeiras. O documento é a saída; o SCA é o motor. Comprar a saída sem o motor deixa você com uma foto que já está errada no commit seguinte.

Por que os SBOM importam agora

Três incidentes transformaram uma caixinha de compras em uma ferramenta de resposta a incidentes e fizeram do inventário de componentes um problema de segurança da cadeia de suprimentos de software. Cada um expôs uma lacuna diferente, e cada lacuna hoje corresponde a um campo do padrão vigente.

Log4Shell: quando ninguém conseguia responder "nós usamos isso?"

Quando o Log4Shell (CVE-2021-44228) foi divulgado em dezembro de 2021, o patch ficou disponível quase de imediato. O gargalo não foi a remediação. Foi a descoberta. O Log4j estava quatro e cinco níveis dentro de ferramentas de build, agentes e servidores de aplicação que ninguém havia pensado como consumidores de logging em Java.

As organizações com um SBOM atualizado o consultaram e em minutos tinham a lista de alvos. O resto passou semanas fazendo grep em repositórios e escrevendo para fornecedores. É por isso que o elemento Coverage de 2026 diz que um SBOM deveria listar cada componente do software avaliado, incluindo as dependências transitivas, sem profundidade mínima. Um inventário que parasse nas dependências diretas teria perdido o Log4j na maioria dos lugares onde ele estava rodando.

SolarWinds: por que os hashes viraram dois campos

O comprometimento da SolarWinds em 2020 funcionou porque o código malicioso chegou por uma atualização oficial e assinada. Nada na lista de dependências parecia errado. O que estava errado é que o artefato entregue já não correspondia ao que o build havia produzido.

Um SBOM gerado em tempo de compilação dá essa linha de base. Se o hash criptográfico de um componente não bate com o valor registrado, o pipeline tem fundamento para rejeitar o build antes da distribuição. A CISA agora lista o valor do hash e o algoritmo do hash como dois campos separados, justamente para que a comparação seja automatizada em vez de conferida a olho. Esse par de campos é o que transforma um SBOM de documento de divulgação em controle.

O comprometimento do npm em 2025: o SBOM como triagem

Em setembro de 2025, um e-mail de phishing contra a conta de um único mantenedor levou a malware publicado em 18 pacotes JavaScript amplamente usados, com cerca de 2,6 bilhões de downloads semanais combinados, entre eles debug, chalk e ansi-styles. A janela de exposição foi de horas. As únicas equipes que conseguiram agir dentro dela foram as que podiam filtrar um SBOM existente por nome de pacote e versão. Nossa análise do incidente descreve esse mesmo movimento dentro da nossa plataforma: abrir a tabela Packages e filtrar por nome de componente.

O SBOM na Fluid Attacks

Geramos o SBOM como subproduto da varredura, não como um exercício à parte. A documentação da Fluid Attacks enuncia o princípio sem rodeios: "SCA tools can automatically generate a comprehensive SBOM, providing a detailed, standardized record of all components and their origins".

O que inventariamos, e a partir de quê

Nosso Software Composition Analysis lê lockfiles e manifestos em 19 gerenciadores de pacotes suportados, cobrindo JavaScript, Python, Java, Kotlin, Ruby, Swift, PHP, Go, C#, Scala e Dart. A cobertura se move: uma versão de setembro de 2026 acrescentou analisadores determinísticos de lockfiles para Yarn, pnpm e Bun.

Cada entrada é então cruzada com nosso próprio catálogo de vulnerabilidades, não com um espelho do CVE. A fraqueza 448 no nosso banco de dados, "Use of software with malware", cobre o caso em que "one or more dependencies used in the project contains code or components suspected of being compromised by malware or malicious behavior". Essa entrada liga aos requisitos que um auditor vai pedir, que é justamente o que uma fonte crua não entrega.

Como fica na prática

O inventário é associado a um alvo de avaliação, que nossa documentação da plataforma define assim: "A package ToE represents a third-party component on which the application depends".

A exportação em si são dois cliques: "In Packages, click on Export SBOM and follow the prompts". O resultado fica "available in the CycloneDX and SPDX formats".

A seção Packages exporta o inventário em dois formatos padronizados.

Reachability determinística, não probabilística

A maior parte do valor está depois da exportação. Um SBOM diz que há uma versão com falha; não diz se esse código pode rodar. Respondemos isso traçando caminhos de chamada, não pontuando probabilidades. Nossas comparações públicas mostram a diferença frente a dois fornecedores de SCA.

Fonte: comparações públicas da Fluid Attacks contra Snyk e Black Duck, construídas com as informações oficiais de produto de cada fornecedor.

Um veredito probabilístico diz ao desenvolvedor que um achado provavelmente não importa. Um determinístico diz que a função nunca é chamada a partir dos pontos de entrada dele. Só o segundo sobrevive a uma conversa com um auditor. Desde outubro de 2026, esse veredito é também o sétimo critério na nossa configuração de prioridade da organização.

O limite com que esbarramos: o inventário cobre a fatia menor

Aqui está a parte que quase nenhuma página de fornecedor inclui. No nosso benchmark, o universo de 1.201 vulnerabilidades se dividiu com 80 % no código próprio, 13 % no backend, e o restante em dependências e frontend. Tudo o que um SBOM consegue ver vive nesses últimos 7 %, e divide o espaço com o frontend.

Os números de detecção apontam na mesma direção. Nesse conjunto, a ferramenta automatizada que identificou o maior percentual de vulnerabilidades foi nosso próprio scanner, com 22,7 % de recall e 99 % de precisão; a melhor de terceiros chegou a 21,6 % de recall com 72 % de precisão. Um pentester trabalhando o mesmo conjunto encontrou 1.076 das 1.201 vulnerabilidades: 89,6 % de recall com 100 % de precisão. Nenhum inventário fecha essa lacuna, porque as falhas que mais importam costumam estar em lógica de negócio que ninguém importou.

O melhor recall automatizado foi 22,7 %; o pentester alcançou 89,6 %.

Isso é um argumento a favor de gerar o documento, não contra. É um argumento contra confundi-lo com um programa de segurança. As equipes que combinam inventário de componentes com testes manuais cobrem as duas metades; as que compram só a primeira cobrem a metade que era mais fácil de automatizar.

A prática que decide o resto: regerar e bloquear

Um documento gerado uma vez fica errado no merge seguinte. A prática que faz diferença é regerá-lo a cada build e aplicar uma política contra o resultado. Nosso relatório State of Attacks 2026, que cobre 1.119.396 vulnerabilidades reportadas entre 1º de janeiro e 31 de dezembro de 2025, encontrou que os sistemas que usaram nosso CI Gate chegaram a uma taxa de remediação de 72,2 % contra 58 % nos sistemas sem ele. O inventário é a entrada; o portão é o que lhe dá consequências.

Nosso guia para o setor financeiro faz a mesma observação: manter um registro detalhado de cada componente em uso e varrê-lo continuamente.

Mais a fundo: nossa página sobre reachability analysis explica como o rastreamento de caminhos de chamada filtra uma lista de componentes até o que é explorável.

O que vai em um SBOM: os elementos mínimos de 2026

Em julho de 2026, a CISA publicou a versão final de Minimum Elements for a Software Bill of Materials, desenvolvida com a NSA, o FBI e quinze agências de cibersegurança internacionais. Ela substitui a linha de base da NTIA de 2021 e o rascunho de consulta pública de agosto de 2025. Os dados exigidos quase dobraram e agora se dividem em dois grupos.

Metadados do SBOM

Os metadados descrevem o próprio documento: quem o produziu, com qual ferramenta, em que ponto do ciclo de vida e em qual formato. Os campos novos são uma assinatura do autor, uma versão do documento, o nome e a versão do formato de dados, o nome e a versão da ferramenta, e um contexto de geração. Este último importa: um registro construído a partir do código-fonte em tempo de compilação e outro construído varrendo um binário pronto descrevem coisas diferentes, e agora o consumidor tem direito a saber qual recebeu.

Dados de componentes

Os dados de componentes descrevem os ingredientes: produtor do componente, nome, versão, identificadores, valor do hash, algoritmo do hash, licença e as relações de dependência entre eles. Cada componente deveria carregar ao menos um identificador de software comum, um campo que também pode conter identificadores únicos, hashes de commit e identificadores intrínsecos.

O que mudou frente à linha de base de 2021

A revisão também separa o que é genuinamente desconhecido do que o autor conhece e está retendo, o que permite ao consumidor distinguir uma lacuna de dados de uma decisão comercial. Se você certificou um documento contra a lista de 2021, assuma que ele já não qualifica.

Mesma ideia, produto diferente: ambos declaram o que há dentro.

Formatos de SBOM depois da revisão de 2026

A CISA nomeia dois formatos de dados como os de uso amplo. Um terceiro, o SWID, ficou fora da lista de formatos de SBOM.

As etiquetas SWID, padronizadas como ISO/IEC 19770-2, seguem em uso para gestão de ativos de TI. A CISA as retirou dos formatos de SBOM nomeados em 2026 porque o SWID não é de uso amplo e tem pouquíssimas ferramentas atrás. O guia continua pedindo às organizações que aceitem qualquer formato interoperável e processável por máquina de uso amplo, então o SWID não está proibido: apenas deixou de ser um dos dois que a CISA aponta.

Se você está produzindo o SBOM para um pipeline de segurança, o formato da OWASP foi feito para isso e carrega declarações de explorabilidade de forma nativa. Se o seu motor é a conformidade de licenças, o da Linux Foundation carrega um número ISO, que ainda pesa com alguns compradores. Emitir os dois custa quase nada, e nossa plataforma entrega o SBOM nos dois.

Regulamentações que exigem um SBOM

O SBOM deixou de ser uma recomendação há vários anos.

A Executive Order 14028 é a que mudou o comportamento do mercado. Tornou o SBOM uma condição de compra federal, e a exigência se propagou por cadeias de suprimentos sem nenhuma exposição federal. O EU Cyber Resilience Act, que cobrimos quando foi adotado, foi além ao atrelar multas e retirada do mercado ao descumprimento.

Note o que nenhum deles pede. Eles exigem que você nomeie seus componentes, não que demonstre que esses componentes são sólidos. O CRA nem sequer obriga a divulgá-lo: seu anexo II diz apenas que se o fabricante decidir compartilhar o documento com os usuários, deve indicar onde encontrá-lo. Um SBOM que você consegue produzir mas não consegue respaldar satisfaz um revisor e deixa a exposição intacta, e é por isso que conformidade e segurança da cadeia de suprimentos de software não são o mesmo objetivo.

Como gerar um SBOM com SCA

Gerar é a parte fácil. Escolher um scanner que produza algo confiável, não.

O SCA resolve o grafo de dependências a partir de lockfiles e manifestos, cruza cada componente com dados de vulnerabilidades e emite o SBOM em um formato padrão. Como roda a cada commit, o documento se mantém atual sem que ninguém o mantenha à mão. Nosso post sobre ferramentas DevSecOps descreve a mecânica: enquanto a varredura inventaria as dependências de código aberto do seu software, produzir o SBOM é uma formalidade.

Quatro critérios separam as implementações úteis das que só marcam a caixinha:

• Cobertura de ecossistemas: um scanner que não consegue ler o seu formato de lockfile vai subnotificar em silêncio. Confira a lista de gerenciadores de pacotes contra a sua stack, não contra uma página de marketing.

• Resolução do grafo completo: confirme que a ferramenta percorre todos os níveis. O elemento Coverage da CISA pede isso, e um scanner que só lê manifestos de primeiro nível não consegue produzir um SBOM em conformidade.

• Inteligência de vulnerabilidades: uma lista de componentes não é uma lista de riscos. Pergunte contra o que o cruzamento é feito e se o veredito de explorabilidade é determinístico ou inferido.

• Bloqueio no pipeline: gerar sem um portão de política produz um documento que ninguém lê. Nossa documentação de análise de cadeia de suprimentos cobre como o resultado se conecta a políticas que quebram o build.

A saída alimenta depois todo o resto: nossos Static Application Security Testing (SAST) e Dynamic Application Security Testing (DAST) cobrem o código que o SBOM não enxerga, e a gestão de vulnerabilidades baseada em risco em uma única plataforma é onde os achados são priorizados. Nossos planos Essential e Advanced geram o documento; o plano Advanced soma pentesters à metade que a automação não alcança.

A fraqueza 448 liga uma dependência comprometida aos requisitos 155, 262 e 330.

Conclusões

Um SBOM é um inventário, e um inventário serve tanto quanto as perguntas que você consegue fazer a ele. Os elementos mínimos de 2026 elevaram a régua do que conta como um SBOM válido: cada dependência aninhada, um identificador de software comum por componente, um hash dividido em valor e algoritmo, um autor assinado, e dois formatos de uso amplo em vez de três.

Atender a essa régua é o mínimo para vender software ao governo federal dos EUA ou ao mercado europeu. Um SBOM não é uma estratégia de segurança. Nosso benchmark coloca 93 % das vulnerabilidades reais fora da camada de dependências que um SBOM descreve, e o melhor recall automatizado em 22,7 % contra os 89,6 % de um pentester. Gere o SBOM, regere-o a cada build, bloqueie o pipeline com ele, e depois vá testar a parte que ele não alcança. Os três primeiros passos são uma decisão de ferramentas. O quarto decide a sua exposição real.

Perguntas frequentes

SBOM e SCA são a mesma coisa?

Não. A análise de composição de software é o processo; o SBOM é uma das suas saídas. A varredura resolve o grafo de dependências e cruza os componentes com dados de vulnerabilidades. Ele é o documento padronizado que essa varredura produz. Dá para ter um sem rodar o outro, mas um arquivo gerado uma vez e nunca atualizado deixa de refletir o seu software em questão de dias.

Um SBOM precisa listar as dependências transitivas?

Sim, segundo o elemento Coverage da CISA de 2026. O guia diz que um inventário deveria incluir todos os componentes do software avaliado, incluindo as dependências transitivas, e afirma sem rodeios que não há profundidade mínima. Isso substitui a linha de base de 2021, que cobria só dependências de primeiro nível. O raciocínio vem de incidentes como o Log4Shell, em que a biblioteca vulnerável quase nunca era uma dependência direta.

Com que frequência um SBOM deve ser atualizado?

A cada build. As dependências mudam a cada merge, e um inventário desatualizado dá uma falsa garantia. Regerá-lo também não basta sozinho: nos dados do nosso State of Attacks 2026, os sistemas com um portão de CI chegaram a 72,2 % de remediação contra 58 % dos que não o tinham.

Um SBOM encontra vulnerabilidades de dia zero?

Não, e não é esse o propósito. Ele diz o que você tem, não o que há de errado com isso. Seu valor aparece no momento em que uma falha é divulgada: você o consulta, encontra cada build afetado e começa a remediar enquanto outros ainda estão procurando. O tempo de descoberta é a variável que ele muda.

O que é VEX e como se relaciona com os SBOM?

O VEX declara se uma vulnerabilidade conhecida é de fato explorável em um dado produto. Um SBOM pode mostrar que você entrega uma biblioteca com falha; o documento complementar pode declarar que aquela função nunca é alcançável a partir dos seus pontos de entrada. Juntos, reduzem a fila de remediação ao que realmente precisa de trabalho.

A Fluid Attacks gera SBOM, e em quais formatos?

Sim, em CycloneDX e SPDX, a partir da seção Packages da nossa plataforma. Nosso SCA resolve dependências em 19 gerenciadores de pacotes, cruza cada componente com nosso próprio catálogo de fraquezas e determina a explorabilidade de forma determinística em 14 linguagens. Os planos Essential e Advanced incluem a geração e a exportação.

Saiba o que você entrega e até onde isso chega

Nossos scanners inventariam suas dependências a cada commit e nossos pentesters testam o código que esse inventário nunca descreve. Teste grátis · Fale conosco