The discussion about SBOM (Software Bill of Materials) has gone from being a peripheral topic in security to becoming a central part of modern software engineering.
Security Researcher
Heitor Gouvêa
A discussão sobre SBOM (Software Bill of Materials) deixou de ser um tema periférico em segurança para se tornar parte central da engenharia moderna de software. A crescente complexidade dos sistemas, compostos majoritariamente por dependências open source e artefatos de terceiros, tornou inviável manter a segurança sem visibilidade estrutural. SBOM surge justamente como essa camada de visibilidade formalizada.
O que é SBOM
SBOM não é apenas uma lista de dependências. Tecnicamente, trata-se de um documento estruturado que descreve a composição de um artefato de software, incluindo metadados suficientes para identificação inequívoca de cada componente. Isso envolve nome, versão, licença, fornecedor, hashes criptográficos, relações de dependência e, idealmente, identificadores padronizados como PURL (Package URL) ou CPE.
Os dois formatos predominantes são SPDX [1] e CycloneDX [2]. O primeiro nasceu no contexto de compliance de licenças, enquanto o segundo foi projetado com foco mais explícito em segurança de aplicações. Ambos evoluíram para suportar modelagem complexa de dependências, relações hierárquicas, assinaturas digitais e extensões para dados de vulnerabilidade. Em termos formais, um arquivo SBOM é um grafo direcionado de componentes, onde nós representam pacotes e arestas representam relações de dependência. Essa modelagem permite raciocínio automatizado sobre impacto, herança de risco e análise transitiva.
Porque SBOM é estrutural para segurança
A principal razão pela qual SBOM se tornou crítico está na assimetria entre consumo e controle. Organizações consomem milhares de dependências sem governança. Quando ocorre um incidente como Log4Shell, a pergunta relevante não é “temos um scanner?”, mas sim “sabemos exatamente onde essa biblioteca está sendo usada?”. Sem SBOM, a resposta depende de buscas e inspeções manuais ou reconstrução tardia do build. Com SBOM, a organização possui um inventário verificável que pode ser cruzado com bases de vulnerabilidade.
No contexto de gestão de vulnerabilidades baseada em componentes, SBOM é a camada de dados primária. O processo moderno não parte mais da varredura isolada, mas da correlação entre inventário estruturado e inteligência de vulnerabilidade (NVD, OSV, GHSA). Isso reduz ruído, melhora rastreabilidade e permite reprocessamento contínuo sem necessidade de novo scan completo do artefato.
Em ambientes maduros, SBOM é gerada no momento do build e armazenada como artefato versionado. A cada atualização em bases de vulnerabilidade, o inventário pode ser reavaliado sem recompilar o software. Esse modelo é significativamente mais eficiente e alinhado com práticas de DevSecOps.
SBOM como elemento de segurança da cadeia de suprimentos
No contexto de software supply chain security, SBOM cumpre papel semelhante ao de um manifesto criptográfico. Ela fornece rastreabilidade sobre o que foi efetivamente incluído no build. Quando combinada com assinatura digital (por exemplo, usando cosign) e frameworks como SLSA (em outras publicações futuras iremos escrever sobre o assunto), SBOM contribui para garantir integridade e proveniência. É importante compreender que SBOM não é scanner de vulnerabilidade. Ela não identifica falhas por si só. Ela fornece o inventário necessário para que scanners e motores de risco operem com precisão.
Ferramentas para geração de SBOM
Diversas ferramentas implementam geração de SBOM com diferentes estratégias de análise. Aqui no Quor, utilizamos majoritariamente o Syft, mas além dele, destacam-se:
Trivy, da Aqua Security, que combina geração de SBOM e scanning de vulnerabilidades;
CycloneDX CLI, mantido pela OWASP;
SPDX tools, associados à Linux Foundation;
tern, focado em análise de containers;
cdxgen, voltado para múltiplos ecossistemas de aplicação.
Cada ferramenta possui trade-offs em termos de profundidade de análise, suporte a ecossistemas, integração com CI/CD e modelo de dados. Para este artigo, o foco será o Syft por sua robustez técnica, arquitetura modular e ampla adoção em ambientes cloud-native.
Syft
Developed by Anchore, it is an SBOM generation tool that operates through static analysis of artifacts. Its operation is based on "catalogers", modules responsible for identifying packages within different filesystem formats or container images. Architecturally, Syft performs:
Extraction of the image filesystem (when applicable);
Identification of package manifests (package-lock.json, pom.xml, go.mod, etc.);
Correlation with internal pattern databases for version inference;
Normalization of components into an internal model;
Serialization into formats such as SPDX or CycloneDX;
A relevant technical feature is native support for PURL. This reduces ambiguity in the subsequent stage of correlating with vulnerabilities.
Practical example with Syft
Generating an SBOM from an image is straightforward:
$ syft nginx:latest -o cyclonedx-json > sbom.json
Internally, Syft downloads the image (if necessary), unpacks its layers, and analyzes each filesystem layer. It identifies both operating system packages (such as dpkg or rpm) and application dependencies. The CycloneDX output includes:
Components;
Hashes;
Dependency relationships;
Build metadata;
Component type (library, application, framework).
For subsequent analysis, the SBOM can be used by tools like Grype (also from Anchore) or Trivy (from Aqua Security), to correlate with CVE databases. For visualization only, options include Sunshine and SBOMPlay.
SBOM in vulnerability management
It is technically more efficient to scan the image's SBOM than the OCI/Docker image itself, especially from the standpoint of computational cost, latency, and I/O consumption. When analyzing the image directly (for example, with: $ grype image:1.0), the scanner needs to download or access layers, rebuild the filesystem, and index artifacts before correlating them with vulnerability databases. In contrast, in the SBOM-based model, as in: $ grype sbom:path/to/sbom.json, this extraction step is eliminated, as the enumeration of packages and dependencies is already materialized beforehand in a structured format (CycloneDX or SPDX), drastically reducing processing overhead. This approach is applicable to tools like Grype and Trivy, which support direct SBOM ingestion, and aligns with modern DevSecOps strategies. Thus, in addition to optimizing resources, SBOM scanning promotes reproducibility, decoupling between build and vulnerability analysis, and better scalability in environments with a large volume of images.
A more technical point is transitive analysis: a vulnerability may exist in an indirect dependency that does not explicitly appear in the project's main file. SBOM resolves this by modeling the complete dependency graph. In corporate environments, a mature architecture involves:
Generating SBOM within the pipeline;
Digital signing of the SBOM;
Storage in a central repository;
Continuous reassessment against updated feeds;
Prioritization based on contextual risk (asset criticality, exposure, exploitability);
This approach shifts security from a periodic scanning model to a permanent inventory-driven model.
Limitations, scope, and evolution of the concept
A recurring confusion is treating SBOM as if it were a complete representation of the software itself. It is not. SBOM describes components incorporated into the artifact, especially third-party dependencies, open-source libraries, operating system packages, and frameworks. It does not describe proprietary code developed internally by the organization, nor does it model business logic, execution flows, or vulnerabilities introduced in the custom code. In formal terms, SBOM is an inventory of third-party composition. The idea is to answer the question:
“Which external building blocks make up this software?”
Not to answer:
“Does this software have logic flaws or vulnerabilities in the internally developed code?”
This point is crucial because SBOM-based vulnerability management is primarily focused on inherited risk via dependencies. Vulnerabilities in proprietary code require distinct practices, such as SAST, DAST, manual code review, and threat modeling.
Another structural limitation is that SBOM represents a state of the artifact at the time of generation. It does not capture dynamic behavior, lazy-loading of libraries, external plugins, or dependencies resolved at runtime outside the analyzed environment. Furthermore, SBOM is not a cryptographic evaluation mechanism. It can include integrity hashes, but it does not, on its own, attest to the authenticity or provenance of the build. For that, it must be combined with digital signatures and supply chain verification mechanisms.
If SBOM represents the static composition of the artifact, RBOM (Runtime Bill of Materials) describes the components actually loaded and used during execution. This distinction is relevant because not every component present in the build is necessarily loaded at runtime. On the other hand, systems can load additional modules dynamically. It reduces noise by identifying what is actually active in production, allowing for vulnerability prioritization based on real exposure.
Cryptography and signing of SBOM
For SBOM to be trustworthy in complex supply chains, it must be protected against tampering. This introduces the topic of:
Digital signing of the SBOM;
Linking the SBOM to the artifact via hash;
Immutable storage.
Without a signature, an SBOM is just a declarative document. With a signature, it becomes part of an attestation model. This is a frequently overlooked point: SBOM increases visibility, but only when combined with integrity guarantees does it effectively strengthen the chain of trust.
Conclusion
SBOM should be understood as a structured mechanism for component visibility, not as a universal security solution. It does not replace source-code analysis, does not fix architectural flaws, and does not eliminate the need for additional controls throughout the software lifecycle. Its value lies in its ability to model software composition in a standardized, verifiable, and machine-readable format, transforming dependencies that are often invisible into explicit, auditable data.
When integrated with complementary practices, such as cryptographic signing to ensure integrity and provenance, cryptography-specific inventories (CBOM), analysis of components actually loaded at runtime (RBOM), and contextual risk-based prioritization engines, the SBOM ceases to be just documentation and becomes part of a broader, evidence-based software security architecture.
In this sense, SBOM represents a structural change in how we treat security. Instead of focusing efforts exclusively on inspecting the final binary, we begin to consider composition as primary security data. Visibility precedes detection. Tools like Syft enable this practice at scale, integrating inventory generation into the build pipeline itself. When this inventory is incorporated into a continuous vulnerability management workflow, with periodic reassessment against updated databases and prioritization criteria based on real impact, the organization significantly reduces incident response time, increases accuracy in identifying exposure, and concretely strengthens the security of the software supply chain.
References
Operating Kubernetes in production for more than 13 years. With Quor, this experience extends to software supply chain security as well.
GET UP
© Getup · 2026
