Three standard formats: SPDX (ISO/IEC 5962, more common for legal/licensing), CycloneDX (OWASP, more security-oriented) and SWID (ISO/IEC 19770-2, more common for asset management). In practice, CycloneDX dominates defensive use.
What SBOM is
SBOM (Software Bill of Materials) is the formal, machine-readable inventory of all components and dependencies that make up a software product: open source libraries, third-party packages, frameworks, versions, licenses and, in fuller versions, also signatures, hashes and suppliers. It's the equivalent of the ingredients list of a product, applied to software. The most widely used standard formats are SPDX and CycloneDX.
Why it matters
When a vulnerability like Log4Shell is published, an organization without SBOM takes days or weeks to know where the affected component is. With a well-maintained SBOM, the response is minutes. The European Cyber Resilience Act (CRA) effectively mandates SBOM for digital products placed on the EU market starting in 2027. US Executive Order 14028 has required it from government suppliers since 2022. NIS2 and DORA both require software supply chain traceability, and SBOM is the technical artifact that materializes that traceability. For anyone selling software to public administration, regulated sectors or large corporations, presenting SBOM is already a procurement requirement.
Key points
Generating SBOM is not manual: it integrates into the CI/CD pipeline with tools like Syft, CycloneDX-CLI, Trivy or the native SBOM features of several DevOps platforms. SBOM is generated each build and signed for integrity.
Having an SBOM doesn't protect; using an SBOM does. The real value comes from cross-referencing it with vulnerability feeds (NVD, GitHub Advisory, OSV) to know instantly which builds are affected by a new CVE.
SBOM + vulnerability management + CVE tracking is the combo that gives real supply chain visibility. Without SBOM, third-party vulnerability management is opaque.
Example: response to a critical CVE with SBOM
A critical CVE is published for a widely used XML parsing library. Without SBOM, the security team queries development, opens tickets in each product, reviews each microservice's manifest and, in a mid-size organization, takes 5-10 days to know real exposure. With well-implemented SBOM, an automated query against the SBOM repository cross-references the vulnerable version against all published builds and returns in seconds: three affected products, two specific versions, one as a transitive (not direct) dependency. The team prioritizes, updates and ships patches in hours, not weeks. Under NIS2 and DORA, that response time is a material difference.
Common mistakes
- Generating an SBOM once and storing it. SBOM must be a living artifact, generated on every build, versioned and queryable. If not maintained, it stops reflecting reality quickly.
- Limiting it to direct dependencies. Most actively exploited vulnerabilities today reach through transitive dependencies (dependencies of dependencies). A useful SBOM includes the full tree.
- Not signing or verifying SBOM. If an attacker can modify the SBOM, they can hide malicious components. SBOM is signed with sigstore or equivalent and verified on consumption.
- Confusing SBOM with SCA. SCA (Software Composition Analysis) analyzes vulnerabilities in the code. SBOM is the inventory. SCA typically consumes SBOM as input.
Related terms
Related services
This concept may relate to services such as:
Frequently asked questions
Is SBOM mandatory in the EU?
The Cyber Resilience Act (Regulation (EU) 2024/2847) effectively mandates SBOM for products with digital elements placed on the EU market, with deadlines extending to 2027. NIS2 and DORA also require software supply chain traceability, and SBOM is the natural tool to materialize it.
Which SBOM format should my organization choose?
CycloneDX is more oriented to security use cases and is the most widely used today in vulnerability management. SPDX covers licensing and legal aspects better. If your priority is security and supply chain risk, start with CycloneDX.
Does SBOM make sense if we don't build software?
Yes, as a consumer. Your organization can require SBOM from suppliers as part of supply chain due diligence. It lets you know what components run in purchased or outsourced software and cross-reference them with newly published vulnerabilities.