SBOM (Software Bill of Materials): O que E e Por Que Sua Empresa Precisa

Introdução: você sabe o que está dentro do seu software?

SBOM (Software Bill of Materials) e o inventário completo de todos os componentes, bibliotecas, dependências e metadados que compõem um software. Pense nele como a lista de ingredientes de um produto alimenticio, só que aplicada a sistemas digitais. Assim como você consulta o rótulo de um alimento para saber se contém gluten ou lactose, o SBOM permite que equipes de segurança, compliance e desenvolvimento saibam exatamente o que está rodando em cada aplicação do ambiente corporativo.

O conceito não é novo, mas a urgência em torno dele e. Até 2021, poucas organizações se preocupavam com a composição interna dos softwares que utilizavam. Então veio o Log4Shell, uma vulnerabilidade crítica na biblioteca Apache Log4j que afetou milhões de sistemas em todo o mundo. A pergunta que paralisou equipes de segurança nos dias que se seguiram foi simples e devastadora: "Quais dos nossos sistemas usam Log4j?" A maioria não conseguiu responder em menos de semanas.

Esse episódio tornou evidente que, sem um SBOM atualizado e acessível, a gestão de vulnerabilidades opera no escuro. Você pode ter o melhor scanner do mercado, mas se não sabe quais componentes existem dentro de cada software, a resposta a incidentes será sempre reativa e lenta.

Neste artigo, vamos explorar o que é SBOM em profundidade, por que ele se tornou um requisito regulatório em mercados como Estados Unidos e União Europeia, o que ele deve conter, como se conecta a gestão de vulnerabilidades e como gera-lo de forma automatizada e contínua com o módulo Inventory da EcoTrust.

---

O que é SBOM: a "lista de ingredientes" do software

Leia também: Inventário de Ativos Agentless: Como Ter Visibilidade Tot...

Um SBOM, Software Bill of Materials, é um documento legivel por máquina que descreve todos os componentes presentes em um software. Ele lista não apenas as bibliotecas que o desenvolvedor adicionou diretamente ao projeto, mas também as dependências transitivas, aquelas que são puxadas automaticamente como requisitos de outras bibliotecas.

Para ilustrar: imagine uma aplicação web em Java que utiliza o framework Spring Boot. O desenvolvedor adicionou Spring Boot como dependência direta. Porém, Spring Boot depende de dezenas de outras bibliotecas, que por sua vez dependem de outras. Uma dessas dependências indiretas pode ser o Log4j. O SBOM mapeia toda essa arvore de componentes, tornando visível o que de outra forma ficaria oculto em camadas de abstração.

O termo "Bill of Materials" vem da industria de manufatura, onde uma BOM lista todos os componentes físicos necessários para montar um produto, parafusos, placas, conectores. No contexto de software, a lógica e identica: listar todos os "ingredientes" digitais que compõem a aplicação final.

Um SBOM robusto permite responder perguntas críticas como:

• Quais versões de cada componente estão em uso?
• Algum componente possui vulnerabilidades conhecidas?
• Existem licenças de código aberto incompativeis com a política da empresa?
• Quais sistemas seriam afetados se uma biblioteca específica fosse comprometida?

Sem essas respostas, a organização está essencialmente confiando cegamente em código que não escreveu e que pode conter falhas graves.

---

Por que SBOM virou essencial: de nice-to-have a obrigatório

Leia também: ITAM para Cibersegurança: Quando o Inventário de TI Vira ...

Três eventos convergiram para transformar o SBOM de um conceito acadêmico em uma exigência prática e regulatória.

O caso Log4Shell (dezembro de 2021)

A vulnerabilidade CVE-2021-44228, batizada de Log4Shell, explorava uma falha de execução remota de código na biblioteca Apache Log4j, amplamente utilizada em aplicações Java. O impacto foi global: estima-se que mais de 35.000 pacotes Java no repositório Maven Central dependiam direta ou indiretamente do Log4j.

O problema não era a existência da vulnerabilidade em si, vulnerabilidades surgem o tempo todo. O problema era que a grande maioria das organizações não sabia onde o Log4j estava presente em seus ambientes. Equipes de segurança passaram semanas vasculhando servidores, containers e aplicações tentando mapear a exposição. Organizações que já mantinham um SBOM atualizado conseguiram responder em horas, não semanas.

Esse episódio se tornou o caso mais citado para justificar investimentos em SBOM e é a referência que todo CISO deveria usar ao apresentar o tema para a diretoria.

Executive Order 14028 dos Estados Unidos (maio de 2021)

Meses antes do Log4Shell, o governo norte-americano já havia publicado a Ordem Executiva 14028, que estabeleceu requisitos de segurança para a cadeia de fornecimento de software vendido ao governo federal. Entre as exigências, fornecedores de software passaram a ser obrigados a fornecer um SBOM como parte do processo de aquisição.

A EO 14028 definiu que o SBOM deve ser gerado em formatos padronizados, atualizado a cada release e acessível tanto por humanos quanto por máquinas. Essa exigência criou um efeito cascata: mesmo empresas que não vendem diretamente para o governo americano passaram a receber demandas de SBOM de seus próprios clientes corporativos.

EU Cyber Resilience Act (2024)

A União Europeia seguiu na mesma direção com o Cyber Resilience Act (CRA), que estabelece requisitos de cibersegurança para produtos digitais comercializados no mercado europeu. O CRA exige que fabricantes e distribuidores de software mantenham documentação da composição de seus produtos, na prática, um SBOM.

Para empresas brasileiras que exportam software ou serviços digitais para a Europa, a conformidade com o CRA não é opcional. E mesmo para organizações que operam apenas no mercado interno, essas regulações internacionais sinalizam a direção inevitável: transparência sobre a composição de software será o padrão, não a exceção.

---

O que um SBOM contém: anatomia de um inventário de composição

A NTIA (National Telecommúnications and Information Administration) dos Estados Unidos definiu os elementos mínimos que um SBOM deve conter. Esses campos formam a base para qualquer implementação seria:

Além desses campos mínimos, SBOMs maduros também incluem:

• Dependências transitivas completas: não apenas a primeira camada, mas toda a arvore de dependências, que pode ter dezenas de níveis de profundidade.
• Informações de vulnerabilidade correlacionadas: mapeamento automático entre componentes listados e CVEs conhecidas, utilizando bases como NVD, OSV e bancos de dados de advisories dos próprios ecossistemas (npm, PyPI, Maven).
• Status de suporte: indicação se o componente ainda recebe atualizações de segurança ou se atingiu end-of-life.
• Proveniencia: informação sobre de onde o componente foi obtido (repositório oficial, mirror, fork).

A profundidade do SBOM importa. Um SBOM superficial que lista apenas dependências diretas perde o componente mais crítico, aquele que está enterrado três níveis abaixo na arvore de dependências e que ninguém sabia que existia até aparecer um CVE com score 10.0.

---

SBOM e gestão de vulnerabilidades: a conexão crítica

O SBOM, por si só, é um inventário. Ele não corrige vulnerabilidades nem prioriza riscos. Seu valor real se materializa quando é integrado ao fluxo de gestão de vulnerabilidades, funcionando como a base de dados que alimenta todas as etapas seguintes.

A lógica e direta:

1. Inventário (SBOM): identifica todos os componentes presentes em cada ativo do ambiente.
2. Correlação: cruza os componentes listados no SBOM com bases de vulnerabilidades conhecidas (NVD, EPSS, advisories de fornecedores).
3. Priorização: aplica contexto de risco, criticidade do ativo, exposição na internet, explorabilidade da vulnerabilidade, para ordenar as ações de remediação.
4. Remediação: direciona patches, atualizações ou mitigações para os componentes vulneráveis identificados.
5. Validação: verifica se a remediação foi efetiva e atualiza o SBOM.

Sem o passo 1, os passos 2 a 5 operam com cobertura incompleta. Esse é o problema fundamental que o SBOM resolve: ele elimina o ponto cego entre "sabemos que existe uma vulnerabilidade no Log4j" e "sabemos quais dos nossos 500 servidores tem Log4j instalado".

Na plataforma EcoTrust, essa conexão e nativa. O módulo Inventory gera o SBOM automaticamente durante a varredura agentless, coletando a lista completa de softwares instalados, bibliotecas e pacotes em cada host. Esse inventário alimenta diretamente o módulo VulScan, que correlaciona os componentes com vulnerabilidades conhecidas e aplica priorização baseada em risco real. O resultado é um fluxo contínuo que vai do inventário a ação, sem etapas manuais ou integração de ferramentas desconectadas.

Dentro do ciclo CTEM (Continuous Threat Exposure Management), o SBOM corresponde a fase de escopo e descoberta, a fundação sobre a qual todas as demais fases se constroem.

---

Formatos de SBOM: SPDX vs CycloneDX

Dois formatos dominam o mercado de SBOM, ambos reconhecidos como padrões pela comunidade internacional:

SPDX (Software Package Data Exchange)

Criado pela Linux Foundation, o SPDX é um padrão ISO (ISO/IEC 5962:2021) focado originalmente em conformidade de licenças de software open source. Com o tempo, evoluiu para cobrir também informações de segurança é composição.

Pontos fortes do SPDX:

• Padrão ISO reconhecido internacionalmente, o que fácilita adoção em ambientes regulados.
• Forte em mapeamento de licenças, com uma lista padronizada de identificadores (SPDX License List).
• Suporte a múltiplos formatos de saida: JSON, XML, RDF, YAML, tag-value.
• Adotado como formato de referência pela NTIA e pelo governo dos EUA.

Limitações:

• Específicação mais extensa e verbosa, o que pode dificultar a geração é o consumo por ferramentas mais simples.
• Históricamente mais voltado a compliance de licenças do que a segurança.

CycloneDX

Criado pela OWASP, o CycloneDX foi projetado desde o início com foco em segurança é gestão de vulnerabilidades. É o formato preferido por equipes de AppSec e DevSecOps.

Pontos fortes do CycloneDX:

• Estrutura enxuta e pragmática, otimizada para integração em pipelines CI/CD.
• Suporte nativo a VEX (Vulnerability Exploitability eXchange), que permite indicar se uma vulnerabilidade em um componente e realmente explorável no contexto da aplicação.
• Campos específicos para informações de segurança: advisories, ratings, análises de impacto.
• Formatos JSON e XML com schemas bem documentados.

Limitações:

• Não é um padrão ISO (embora esteja em processo de padronização via Ecma International).
• Menos adotado em contextos regulatórios governamentais tradicionais.

Qual escolher?

Na prática, a escolha entre SPDX e CycloneDX depende do contexto:

Muitas organizações maduras geram SBOMs em ambos os formatos, já que ferramentas de conversão entre eles estão amplamente disponíveis. O mais importante não é o formato escolhido, mas a consistência é a frequência com que o SBOM e gerado e atualizado.

---

Como gerar SBOM de forma automatizada e contínua

Um SBOM só tem valor se estiver atualizado. Um inventário de composição gerado uma vez e esquecido em um repositório e pouco melhor do que não ter SBOM algum. A cada deploy, a cada atualização de dependência, a cada novo servidor provisionado, o SBOM precisa refletir o estado real do ambiente.

Existem três abordagens principais para geração de SBOM:

1. Análise de código-fonte (source code analysis)

Ferramentas como Syft, Trivy e cdxgen analisam os arquivos de manifesto do projeto (package.json, pom.xml, requirements.txt, go.mod) e geram o SBOM a partir das dependências declaradas. Essa abordagem é ideal para integrar no pipeline CI/CD e captura o SBOM no momento do build.

Limitação: só cobre o que está declarado no manifesto. Dependências instaladas manualmente, binarios embarcados ou componentes adicionados fora do gerenciador de pacotes ficam fora do radar.

2. Análise de artefatos binarios (binary analysis)

Ferramentas que inspecionam o artefato compilado, container image, pacote JAR, binário executável, para identificar componentes presentes no software final. Essa abordagem captura o que realmente está no artefato, não apenas o que foi declarado.

Limitação: maior complexidade e tempo de processamento. Nem sempre consegue identificar versões exatas de componentes compilados estáticamente.

3. Inventário agentless em runtime

Essa abordagem consulta os sistemas em produção para identificar o que está efetivamente instalado e rodando. Em vez de analisar o código-fonte ou o artefato, ela examina o ambiente real: quais pacotes estão instalados no sistema operacional, quais bibliotecas estão carregadas, quais versões estão ativas.

O módulo Inventory da EcoTrust utiliza essa abordagem. Através de varredura agentless via WMI (Windows) e SSH (Linux/macOS), o agente de IA conecta-se aos hosts, coleta a lista completa de softwares instalados, bibliotecas e pacotes, e gera o SBOM automaticamente. Se um host tiver Log4j em alguma dependência, mesmo que enterrada em camadas de abstração, o agente encontra.

Vantagens dessa abordagem:

• Captura o estado real do ambiente de produção, não apenas o que foi planejado.
• Não depende de integração com pipelines de desenvolvimento.
• Cobre todo o parque, incluindo softwares legados, sistemas de terceiros e aplicações que não passam por CI/CD.
• O SBOM gerado alimenta automaticamente as etapas seguintes de VulScan e priorização de vulnerabilidades.

A melhor prática e combinar as três abordagens: SBOM no build (pipeline), SBOM no artefato (container registry) e SBOM em runtime (inventário agentless). Cobertura completa, do desenvolvimento a produção.

---

FAQ: perguntas frequentes sobre SBOM

SBOM é obrigatório no Brasil?

Atualmente, não existe legislação brasileira que exija SBOM de forma explícita. Porém, organizações que fornecem software para o governo dos Estados Unidos já precisam cumprir os requisitos da EO 14028, e empresas que comercializam produtos digitais na União Europeia precisarao se adequar ao Cyber Resilience Act. Além disso, frameworks como ISO 27001 e regulações setoriais do BACEN e da LGPD incentivam práticas de gestão de ativos e transparência que o SBOM atende diretamente.

Qual a diferença entre SBOM e SCA (Software Composition Analysis)?

SBOM é o artefato, o documento que lista os componentes de um software. SCA é o processo, a prática de analisar a composição de software para identificar vulnerabilidades, licenças problematicas e riscos. Em outras palavras, o SBOM é o "o que temos" e o SCA e o "o que isso significa para nossa segurança". Os dois são complementares: o SBOM alimenta as ferramentas de SCA com os dados necessários para a análise.

Com que frequência o SBOM deve ser atualizado?

O ideal e que o SBOM seja gerado automaticamente a cada evento relevante: novo deploy, atualização de dependências, provisionamento de servidor. Em ambientes maduros, a geração de SBOM e integrada ao pipeline CI/CD (para aplicações) e ao ciclo de inventário agentless (para o ambiente de produção). A recomendação mínima é uma atualização semanal, mas organizações com alta frequência de deploys devem gerar SBOMs com a mesma cadência.

SBOM só serve para software open source?

Não. Embora o SBOM seja frequentemente associado a componentes open source, que representam mais de 80% do código em aplicações modernas, segundo relatórios da Synopsys, ele também deve documentar componentes proprietários, SDKs de terceiros, bibliotecas comerciais e qualquer artefato de software presente no ambiente. A transparência deve ser completa, independentemente da origem do componente.

Como o SBOM ajuda na resposta a incidentes?

Quando uma nova vulnerabilidade crítica e divulgada, como foi o caso do Log4Shell, o SBOM permite que a equipe de segurança responda imediatamente a pergunta "estamos afetados?". Em vez de iniciar uma busca manual por todos os servidores e aplicações, a equipe consulta o SBOM centralizado e em minutos identifica todos os ativos que contém o componente vulnerável. Isso reduz o tempo de resposta de semanas para horas e permite priorizar a remediação nos sistemas mais críticos primeiro.

---

Para aprofundamento, consulte a referência oficial: CISA — Software Bill of Materials (SBOM).

Conclusão: SBOM é o alicerce da segurança moderna de software

O SBOM não é uma tendência passageira nem uma exigência burocratica. É a resposta pragmática a uma realidade incontornavel: software moderno e construido sobre camadas de componentes que ninguém controla individualmente. Sem visibilidade sobre essa composição, toda estratégia de segurança tem um ponto cego fundamental.

A boa noticia é que gerar e manter SBOMs atualizados não precisa ser um projeto manual e oneroso. Com o módulo Inventory da EcoTrust, o SBOM e gerado automaticamente durante o inventário agentless, cobrindo todo o parque de ativos sem instalar nada nos endpoints. Esse inventário alimenta diretamente o VulScan para correlação com vulnerabilidades e priorização baseada em risco real, dentro de um ciclo CTEM contínuo e orientado por IA agêntica.

A pergunta que sua organização precisa responder não é "devemos adotar SBOM?", mas "quanto tempo levaremos para saber se estamos expostos quando a próxima vulnerabilidade crítica for divulgada?"

Conheça o módulo Inventory da EcoTrust e veja como gerar SBOMs automaticamente para todo o seu ambiente