Syft

Developed by Anchore, it is a tool for generating SBOM that operates through static analysis of artifacts. Its operation is based on "catalogers", modules responsible for identifying packages within different formats of filesystem or container images. Architecturally, Syft performs:

1. Extraction of the image's filesystem (when applicable);

2. Identification of package manifests (package-lock.json, pom.xml, go.mod, etc.);

3. Correlation with internal databases of patterns for version inference;

4. Normalization of components to an internal model;

5. Serialization to formats such as SPDX or CycloneDX;

A relevant technical characteristic is native support for PURL. This reduces ambiguities in the subsequent correlation step with vulnerabilities.

Practical example with Syft

The generation of 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 (for example, dpkg or rpm) and application dependencies. The result in CycloneDX includes:

• Components;

• Hashes;

• Dependency relationships;

• Build metadata;

• Type of component (library, application, framework).

For further 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 purposes, options include Sunshine and SBOMPlay. 

SBOM in vulnerability management

It is technically more efficient to scan the SBOM of the image than the image itself (OCI/Docker), especially from the perspective 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, reconstruct the filesystem and index artifacts before correlating them with vulnerability databases. 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 pre-materialized in a structured format (CycloneDX or SPDX), drastically reducing processing overhead. This approach is applicable to tools like Grype and Trivy, which support direct ingestion of SBOM, and aligns with modern DevSecOps strategies. Thus, in addition to optimizing resources, scanning SBOM favors 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 main project file. SBOM resolves this by modeling the full dependency graph. In corporate environments, mature architecture involves:

• Generating SBOM in the pipeline;

• Digital signature of the SBOM;

• Storage in a central repository;

• Continuous reevaluation against updated feeds;

• Prioritization based on contextual risk (asset criticality, exposure, exploitability);

This approach shifts security from a periodic scanning model to a model oriented toward permanent inventory.

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 embedded components in 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 authored code. Formally, SBOM is an inventory of third-party composition. The idea is to answer the question:

"What external 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 vulnerability management based on SBOM is primarily focused on inherited risk via dependencies. Vulnerabilities in proprietary code require different practices, such as SAST, DAST, manual code analysis, 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, late loading of libraries, external plugins, or dependencies resolved at runtime outside the analyzed environment. Additionally, SBOM is not a mechanism for cryptographic assessment. It may include integrity hashes, but does not itself attest to the authenticity or provenance of the build. For that, it is necessary to combine it with digital signature and supply chain verification mechanisms.

If SBOM represents the static composition of the artifact, RBOM (Runtime Bill of Materials) describes the components effectively loaded and used at runtime. This distinction is relevant because not every component present in the build is necessarily loaded at runtime. On the other hand, systems may dynamically load additional modules. It reduces noise by identifying what is actually active in production, allowing prioritization of vulnerabilities based on real exposure.

Cryptography and SBOM signing

For SBOM to be trustworthy in complex supply chains, it needs to be protected against tampering. This introduces the topic of:

• Digital signature of SBOM;

• Linking the SBOM to the artifact via hash;

• Immutable storage.

Without a signature, SBOM is just a declarative document. With the signature, it integrates into a model of attestation. This is a point often overlooked: SBOM increases visibility, but only combined with guarantees of integrity does it effectively strengthen the chain of trust.

Conclusion

SBOM should be understood as a structured mechanism for visibility of components, 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 the ability to model the composition of software in a standardized, verifiable, and machine-processable way, turning dependencies that are often invisible  into explicit and auditable data. 

When integrated with complementary practices, such as cryptographic signing to ensure integrity and provenance, specific inventories for cryptography (CBOM), analysis of components effectively loaded at runtime (RBOM), and prioritization engines based on contextual risk, SBOM moves from mere documentation to being part of a broader architecture of evidence-based software security.

In this sense, SBOM represents a structural shift in how we treat security. Instead of concentrating efforts solely 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 flow of vulnerability management, with periodic reevaluation against updated databases and prioritization criteria based on real impact, the organization significantly reduces the time to respond to incidents, increases accuracy in identifying exposure, and concretely strengthens the security of the software supply chain.

References

1. https://spdx.dev

2. https://cyclonedx.org

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

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