SBOM Explained: Software Bill of Materials, Formats, and Why the CRA Requires One
August 6, 2026 · by Pentevo
SBOM Explained
An SBOM (Software Bill of Materials) is a machine-readable inventory of every component that makes up a piece of software — each dependency, its version, its supplier, and how the components relate to each other. It exists so that when a vulnerability is announced, you can answer one question in minutes rather than weeks: do we ship the affected component, and where?
The analogy that actually holds is a food ingredient label. You don't read it every day. You read it the moment someone announces an allergen recall — and at that point you need it to already exist, be accurate, and cover everything in the box.
Log4Shell in December 2021 is why this became regulation. Thousands of organisations spent weeks manually searching codebases to answer whether they used Log4j. Organisations with an SBOM answered in an afternoon.
What goes in an SBOM
The widely used baseline is the NTIA minimum elements (2021), which most regulators and tools follow:
| Element | Meaning |
|---|---|
| Supplier name | Who produced the component |
| Component name | What it is |
| Version | Which release |
| Other unique identifiers | CPE, PURL, SWID |
| Dependency relationship | What includes what |
| Author of the SBOM data | Who generated this document |
| Timestamp | When it was generated |
Package URL (PURL) — e.g. pkg:npm/lodash@4.17.21 — is the identifier that matters most in practice. It is unambiguous, tool-friendly, and what most vulnerability matching runs on.
The six SBOM types
CISA distinguishes SBOMs by when in the lifecycle they are produced. This matters more than most teams realise, because they answer different questions:
| Type | Produced | Answers |
|---|---|---|
| Design | Before build | What we intend to use |
| Source | From source / manifests | What the code declares |
| Build | During CI build | What actually went in |
| Analyzed | Post-build, by scanning the artifact | What is really in the binary |
| Deployed | From the deployed system | What is installed |
| Runtime | From a running system | What is actually loaded |
Build SBOMs are the practical default. Source SBOMs miss things the build pulls in; analyzed SBOMs are useful for third-party binaries where you have no source.
CycloneDX vs SPDX
Two formats dominate. Both are fine; the choice usually comes down to what your ecosystem already speaks.
| CycloneDX | SPDX | |
|---|---|---|
| Steward | OWASP | Linux Foundation |
| Standardised as | ECMA-424 | ISO/IEC 5962:2021 |
| Origin focus | Security and risk | Licence compliance |
| Formats | JSON, XML, Protobuf | JSON, YAML, RDF, tag-value, spreadsheet |
| VEX support | Native | Via companion documents |
| Beyond software | HBOM, SaaSBOM, ML-BOM, CBOM | Extending |
| Feels like | Security tooling | Legal/compliance tooling |
Practical guidance: if your driver is vulnerability management and regulation, start with CycloneDX — it was designed for it, and its VEX support is native. If your driver is licence compliance, or a customer mandates it, use SPDX. Good tooling converts between them, though conversion is lossy in both directions for format-specific fields.
There is a third, SWID tags (ISO/IEC 19770-2), which appears in asset-management contexts but is rarely the primary choice for new work.
What the Cyber Resilience Act actually requires
This is where most confusion sits, so here is the precise position.
CRA Annex I, Part II (vulnerability handling requirements) obliges manufacturers to identify and document components and vulnerabilities, including by drawing up an SBOM in a commonly used machine-readable format, covering at the very least the top-level dependencies of the product.
Three things follow that people frequently get wrong:
- "At the very least top-level dependencies." The CRA does not mandate a full transitive dependency tree. Top-level is the floor. Going deeper is good practice and often good business — but do not let a vendor tell you the regulation requires full depth when it does not.
- There is no obligation to publish the SBOM. It must exist, be machine-readable, and be available to market surveillance authorities on request. It is not a public disclosure requirement.
- It is not a one-off. It sits inside the vulnerability handling requirements, which run for the entire support period. An SBOM generated once at release and never regenerated does not satisfy the intent.
Dates that matter: CRA Art. 14 reporting obligations apply from 11 September 2026; the full requirements including CE marking apply from 11 December 2027.
Other drivers
| Driver | SBOM position |
|---|---|
| US EO 14028 (2021) | SBOMs required for software sold to US federal agencies |
| NIS2 Art. 21(2)(d)+(e) | Not named, but supply chain security and vulnerability handling effectively require component visibility |
| FDA (medical devices) | SBOM required in premarket submissions for cyber devices |
| Customer contracts | Increasingly requested in enterprise procurement |
How to generate an SBOM
Generation is genuinely easy. Maintenance is the hard part.
| Tool | Best for | Output |
|---|---|---|
| Syft (Anchore) | Containers, filesystems, most ecosystems | CycloneDX, SPDX |
| cdxgen (OWASP) | Very broad language support | CycloneDX |
| Trivy | Already in your pipeline for scanning | CycloneDX, SPDX |
| Microsoft SBOM tool | .NET / Azure builds | SPDX |
| Native package managers | npm sbom, mvn cyclonedx, cargo cyclonedx |
Varies |
# Container image → CycloneDX JSON
syft <image>:<tag> -o cyclonedx-json > sbom.json
# Source tree → SPDX
syft dir:. -o spdx-json > sbom.spdx.json
Then wire it into CI. An SBOM is only useful if it is regenerated on every release and stored alongside the artifact it describes.
# sketch — generate, attach to the release, keep it versioned
- name: Generate SBOM
run: syft $IMAGE -o cyclonedx-json > sbom-${VERSION}.json
- name: Attach to release
uses: actions/upload-artifact@v4
VEX: the piece that makes SBOMs survivable
An SBOM tells you a component is present. It does not tell you whether the vulnerability in that component is actually exploitable in your product. Without something to close that gap, your customers open a ticket for every CVE in every dependency, and your support team drowns.
VEX (Vulnerability Exploitability eXchange) is the answer: a machine-readable statement of status per vulnerability per product.
| Status | Meaning |
|---|---|
not_affected |
The vulnerability is present in a component but not exploitable here — with a stated justification |
affected |
Exploitable; remediation guidance follows |
fixed |
Already remediated in this version |
under_investigation |
Triage in progress |
Implementations: CSAF VEX (OASIS), OpenVEX, and CycloneDX VEX.
In practice: SBOM answers what is in it, VEX answers does it matter. Under the CRA the second question is the one you must answer publicly when you publish information about fixed vulnerabilities.
Common mistakes
- Generating once, at release, and never again. Dependencies change every build. A stale SBOM is worse than none because it produces confident wrong answers.
- Source-only SBOMs for shipped binaries. What the manifest declares and what the build produces are different. Generate at build, or analyze the artifact.
- No VEX. You will be buried in false-positive CVE reports from customers within a quarter.
- Treating the SBOM as a compliance artifact rather than an operational one. If nobody queries it during an incident, it is theatre. Test it: pick a CVE and see how fast you can answer "do we ship this?"
- Assuming full transitive depth is mandatory under the CRA. Top-level is the stated floor.
- Ignoring the non-software parts. For hardware products, consider HBOM and, as post-quantum migration begins, CBOM (cryptographic bill of materials).
FAQ
What does SBOM stand for? Software Bill of Materials — a machine-readable inventory of the components in a piece of software.
Is an SBOM required by law? It is effectively required for products sold into the EU under the Cyber Resilience Act (Annex I Part II), for software sold to US federal agencies under EO 14028, and in FDA premarket submissions for cyber devices.
CycloneDX or SPDX — which should I use? CycloneDX if your driver is security and vulnerability management; SPDX if it is licence compliance or a customer mandates it. Both are widely supported and convertible.
Does the CRA require a full dependency tree? No. It requires at minimum the top-level dependencies. Deeper is good practice, not a stated legal minimum.
Do I have to publish my SBOM? No. It must exist in a machine-readable format and be available to authorities on request. Publication is a commercial decision, not a legal requirement.
How often should an SBOM be regenerated? Every build that produces a shipped artifact, and stored with that artifact.
What is the difference between an SBOM and a VEX document? The SBOM lists components. VEX states whether a given vulnerability in a component is actually exploitable in your product.
Can I generate an SBOM for software I did not write? Yes — an "analyzed" SBOM produced by scanning the binary or container. It is less complete than a build SBOM but works for third-party components.
Next step
→ SBOM Validator & Converter — check your SBOM against CRA Annex I Part II
Related reading:
Frequently asked questions
What does SBOM stand for?
SBOM stands for Software Bill of Materials — a machine-readable inventory of every component in a piece of software, including each dependency, its version, its supplier, and how components relate to each other.
Is an SBOM legally required?
Yes in several jurisdictions. The EU Cyber Resilience Act (Annex I Part II) requires an SBOM for products with digital elements. US Executive Order 14028 requires one for software sold to federal agencies. The FDA requires one in premarket submissions for cyber devices.
CycloneDX or SPDX — which format should I use?
Use CycloneDX if your primary driver is security and vulnerability management; it has native VEX support and was designed for that purpose. Use SPDX if your driver is licence compliance or a customer mandates it. Both formats are widely supported and convertible between each other.
Does the CRA require a full transitive dependency tree in the SBOM?
No. The CRA Annex I Part II states at minimum the top-level dependencies of the product. Full transitive depth is good practice but not the stated legal minimum.
Do I have to publish my SBOM publicly?
No. The CRA requires that the SBOM exists in a machine-readable format and is available to market surveillance authorities on request. There is no obligation to make it publicly available.
What are the minimum required fields in an SBOM?
The NTIA minimum elements are: supplier name, component name, version, other unique identifiers (such as PURL or CPE), dependency relationships, the author of the SBOM data, and a timestamp.
How do I generate an SBOM?
Common tools include Syft (for containers and filesystems), cdxgen (broad language support), Trivy (already used for scanning), and native package manager commands such as npm sbom or cargo cyclonedx. Generate the SBOM at build time and store it alongside the artifact.
What is the difference between an SBOM and a VEX document?
An SBOM lists what components are in a product. A VEX (Vulnerability Exploitability eXchange) document states whether a known vulnerability in one of those components is actually exploitable in your specific product — and why.
Related reading
EU Cyber Resilience Act (CRA) Explained: Who It Affects and What It Requires
The CRA applies to all products with digital elements sold in the EU. Essential requirements, SBOM mandate, 24-hour vulnerability reporting, and the December 2027 deadline.
complianceWhat Is an ISMS? ISO 27001 Information Security Management System Explained
An ISMS is the documented management system ISO 27001 requires. Clauses 4–10, the 93 Annex A controls, the Statement of Applicability, and how it maps to NIS2 Article 21.
complianceNIS2 Explained: Who Is Affected, What You Must Do, and by When
NIS2 in practice — Annex I and II sectors, size thresholds, essential vs important entities, the ten Article 21 measures, the 24/72-hour reporting cascade, and management liability.
complianceKRITIS Explained: Germany's Critical Infrastructure Security Requirements
A practitioner's guide to KRITIS — the legal basis, which sectors and thresholds apply, what §8a BSIG demands, how the KRITIS-Dachgesetz adds physical resilience, and what BSI inspectors look for.
Practice this hands-on
Pentevo Academy turns these concepts into guided lessons, videos and quizzes — free.
Start learning free