Syft

Desenvolvido pela Anchore, é uma ferramenta de geração de SBOM que opera por análise estática de artefatos. Seu funcionamento é baseado em “catalogers”, módulos responsáveis por identificar pacotes dentro de diferentes formatos de filesystem ou imagens de container. Arquiteturalmente, o Syft realiza:

1. Extração do sistema de arquivos da imagem (quando aplicável);

2. Identificação de manifestos de pacote (package-lock.json, pom.xml, go.mod, etc.);

3. Correlação com bancos internos de padrões para inferência de versão;

4. Normalização dos componentes para um modelo interno;

5. Serialização para formatos como SPDX ou CycloneDX;

Uma característica técnica relevante é o suporte nativo a PURL. Isso reduz ambiguidades na etapa posterior de correlação com vulnerabilidades.

Exemplo prático com Syft

A geração de SBOM de uma imagem é direta:

$ syft nginx:latest -o cyclonedx-json > sbom.json

Internamente, o Syft baixa a imagem (se necessário), desmonta suas camadas e analisa cada filesystem layer. Ele identifica tanto pacotes do sistema operacional (por exemplo, dpkg ou rpm) quanto dependências de aplicação. O resultado em CycloneDX inclui:

• Componentes;

• Hashes;

• Relações de dependência;

• Metadata do build;

• Tipo do componente (library, application, framework).

Para análise posterior, a SBOM pode ser usada por ferramentas como Grype (também da Anchore) ou Trivy (da Aqua Security), para correlacionar com bancos de CVE. Para apenas visualização, opcões são Sunshine e SBOMPlay. 

SBOM na gestão de vulnerabilidades

É tecnicamente mais eficiente escanear o SBOM da imagem do que a própria imagem OCI/Docker, sobretudo sob a ótica de custo computacional, latência e consumo de I/O. Ao analisar diretamente a imagem (por exemplo, com: $ grype image:1.0), o scanner precisa baixar ou acessar camadas, reconstruir o filesystem e indexar artefatos antes de correlacioná-los com bases de vulnerabilidades. Já no modelo baseado em SBOM, como em: $ grype sbom:path/to/sbom.json, essa etapa de extração é eliminada, pois a enumeração de pacotes e dependências já está previamente materializada em formato estruturado (CycloneDX ou SPDX), reduzindo drasticamente o overhead de processamento. Essa abordagem é aplicável a ferramentas como Grype e Trivy, que suportam ingestão direta de SBOM, e se alinha a estratégias modernas de DevSecOps. Assim, além de otimizar recursos, o escaneamento de SBOM favorece reprodutibilidade, desacoplamento entre build e análise de vulnerabilidades e melhor escalabilidade em ambientes com grande volume de imagens.

Um ponto mais técnico é a análise transitiva: uma vulnerabilidade pode existir em uma dependência indireta que não aparece explicitamente no arquivo principal do projeto. SBOM resolve isso ao modelar o grafo completo de dependências. Em ambientes corporativos, a arquitetura madura envolve:

• Geração de SBOM no pipeline;

• Assinatura digital da SBOM;

• Armazenamento em repositório central;

• Reavaliação contínua contra feeds atualizados;

• Priorização baseada em risco contextual (criticidade do ativo, exposição, exploitabilidade);

Essa abordagem desloca a segurança de um modelo de varredura periódica para um modelo orientado a inventário permanente.

Limitações, escopo e evolução do conceito

Uma confusão recorrente é tratar SBOM como se fosse uma representação completa do software em si. Não é. SBOM descreve componentes incorporados ao artefato, especialmente dependências de terceiros, bibliotecas open source, pacotes do sistema operacional e frameworks. Ela não descreve o código proprietário desenvolvido internamente pela organização, tampouco modela lógica de negócio, fluxos de execução ou vulnerabilidades introduzidas no código autoral. Em termos formais, SBOM é um inventário de third-party composition. A ideia é responder à pergunta:

“Quais blocos externos compõem este software?”

Não responder:

“Este software possui falhas de lógica ou vulnerabilidades no código desenvolvido internamente?”

Esse ponto é crucial porque a gestão de vulnerabilidades baseada em SBOM está focada primariamente em risco herdado via dependências. Vulnerabilidades em código próprio exigem práticas distintas, como SAST, DAST, análise de código manual e threat modeling.

Outra limitação estrutural é que SBOM representa um estado do artefato no momento da geração. Ela não captura comportamento dinâmico, carregamento tardio de bibliotecas, plugins externos ou dependências resolvidas em runtime fora do ambiente analisado. Além disso, SBOM não é um mecanismo de avaliação criptográfica. Ela pode incluir hashes de integridade, mas não atesta por si só a autenticidade ou proveniência do build. Para isso, é necessário combinar com assinatura digital e mecanismos de verificação de supply chain.

Se SBOM representa a composição estática do artefato, a RBOM (Runtime Bill of Materials) descreve os componentes efetivamente carregados e utilizados em execução. Essa distinção é relevante porque nem todo componente presente no build é necessariamente carregado em runtime. Por outro lado, sistemas podem carregar módulos adicionais dinamicamente. Ela reduz o ruído ao identificar o que realmente está ativo em produção, permitindo priorização de vulnerabilidades com base em exposição real.

Criptografia e assinatura de SBOM

Para que SBOM seja confiável em cadeias de suprimento complexas, ela precisa ser protegida contra adulteração. Isso introduz o tema de:

• Assinatura digital de SBOM;

• Vinculação da SBOM ao artefato via hash;

• Armazenamento imutável.

Sem assinatura, SBOM é apenas um documento declarativo. Com a assinatura, passa a integrar um modelo de atestação. Esse é um ponto frequentemente negligenciado: SBOM aumenta a visibilidade, mas somente combinada com garantias de integridade ela fortalece efetivamente a cadeia de confiança.

Conclusão

SBOM deve ser compreendida como um mecanismo estruturado de visibilidade de componentes, não como uma solução universal de segurança. Ela não substitui análise de código-fonte, não corrige falhas de arquitetura e tampouco elimina a necessidade de controles adicionais ao longo do ciclo de vida do software. Seu valor reside na capacidade de modelar a composição do software de forma padronizada, verificável e processável por máquinas, transformando dependências que frequentemente são invisíveis  em dados explícitos e auditáveis. 

Quando integrada a práticas complementares, como assinatura criptográfica para garantir integridade e proveniência, inventários específicos de criptografia (CBOM), análise de componentes efetivamente carregados em execução (RBOM) e motores de priorização baseados em risco contextual, a SBOM deixa de ser apenas documentação e passa a compor uma arquitetura mais ampla de segurança de software baseada em evidências.

Nesse sentido, SBOM representa uma mudança estrutural na forma como tratamos segurança. Em vez de concentrar esforços exclusivamente na inspeção do binário final, passamos a considerar a composição como dado primário de segurança. A visibilidade antecede a detecção. Ferramentas como Syft viabilizam essa prática em escala, integrando a geração de inventário ao próprio pipeline de build. Quando esse inventário é incorporado a um fluxo contínuo de gestão de vulnerabilidades, com reavaliação periódica contra bases atualizadas e critérios de priorização baseados em impacto real, a organização reduz significativamente o tempo de resposta a incidentes, aumenta a precisão na identificação de exposição e fortalece de maneira concreta a segurança da cadeia de suprimentos de software.

Referências

1. https://spdx.dev

2. https://cyclonedx.org

3. https://github.com/anchore/syft

4. https://github.com/anchore/grype