Software supply chain
SBOM: what a software bill of materials is and how to make one
An SBOM, or software bill of materials, is a formal, machine-readable record of the components in a piece of software and how they relate to each other. The Cyber Resilience Act requires manufacturers to draw one up, covering at least the top-level dependencies, in a commonly used format such as CycloneDX or SPDX.
Free plan, no card required.
What is an SBOM?
Think of it as the ingredient list of a product. For each component it records a name, a version and, ideally, a unique identifier such as a package URL, together with the supplier and the relationships between components: which library pulls in which. The CRA defines it as a formal record containing details and supply chain relationships of the components included in the software elements of a product.
An SBOM does not say whether a component is vulnerable. It is the inventory that makes that question answerable, today and every time a new vulnerability is published.
Is an SBOM mandatory?
For manufacturers of products in scope of the Cyber Resilience Act, yes. Annex I Part II requires them to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used and machine-readable format covering at the very least the top-level dependencies. The SBOM belongs in the technical documentation and must be given to a market surveillance authority that asks for it with reasons; the Regulation does not require publishing it.
The Commission may specify the format and elements by implementing act. Until then, CycloneDX and SPDX are the formats most tools produce and accept.
CycloneDX vs SPDX
Both are open standards and both are widely supported. The choice usually depends on the tools your customers and suppliers already use; many teams keep both.
| CycloneDX | SPDX | |
|---|---|---|
| Maintained by | OWASP and Ecma International (ECMA-424) | The Linux Foundation; published as ISO/IEC 5962:2021 |
| Origins | Application security and supply-chain risk | Licence compliance |
| Serialisations | JSON, XML, Protocol Buffers | JSON, tag-value, RDF, YAML and others |
| Vulnerability data | Built-in VEX support | Separate VEX documents are common |
How to generate an SBOM
The most accurate SBOM is produced from what you actually ship. For source code that means the lockfiles and manifests your build resolves; for firmware and container images it means the files inside the image, because build-time tools can miss packages added later in the pipeline.
- Generate it in the build pipeline, for every release, not by hand.
- Scan the final artefact as well as the source: firmware images and container images included.
- Record exact versions and package URLs, not version ranges.
- Keep the SBOM of every version still supported; you will need it when a new vulnerability appears.
- Re-check stored SBOMs against new vulnerability data instead of rebuilding old releases.
What to do with an SBOM once you have it
An SBOM earns its keep when a new vulnerability is published. With an inventory per release, the question "which of our products ship this component?" takes minutes instead of days. That speed matters under Article 14 of the CRA, where an actively exploited vulnerability starts a 24-hour reporting clock.
Pair it with VEX (Vulnerability Exploitability eXchange) statements to record which listed vulnerabilities do not affect the product and why, so customers and authorities see the decision as well as the inventory.
Available in KROMSE today
KROMSE produces and reads SBOMs today.
- Every scan of a repository, container image or Linux-based firmware image produces a CycloneDX JSON and an SPDX JSON SBOM to download.
- Upload CycloneDX (JSON 1.2 to 1.7, or XML) or SPDX 2.2 and 2.3 (JSON or tag-value) SBOMs, plus Yocto and Buildroot build manifests; each upload is checked against OSV.dev automatically.
- Push SBOMs from CI with a workspace API token; snippets exist for GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, Bitbucket Pipelines, Yocto, Buildroot, Zephyr and ESP-IDF.
- VEX export in CycloneDX 1.6 VEX and OpenVEX, with each imported VEX statement accepted by a person.
- On paid plans, the latest SBOM of each product is re-checked against OSV every six hours.
Coming next
On the roadmap, not available yet. Dates are targets, not promises; this page changes the day a capability is live.
- Coming · Q1 2027Hardware parts. KROMSE will match the hardware parts in your product against published hardware advisories.
- Coming · Q1 2027AI agent and model security. KROMSE will produce an AI bill of materials, review the tools and permissions your agents can use, and detect unsafe model files.
Frequently asked questions
What does SBOM stand for?
Software bill of materials: a formal, machine-readable list of the components in a piece of software, with their versions, suppliers and relationships. It works like an ingredient list and is the starting point for finding out whether a product contains a vulnerable component.
Does the Cyber Resilience Act require an SBOM?
Yes. Annex I Part II requires manufacturers of products with digital elements to draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. It is part of the technical documentation and is provided to market surveillance authorities on reasoned request.
Which SBOM format should I use?
CycloneDX and SPDX are both commonly used, machine-readable and widely supported. Choose the one your customers and tools expect, or produce both. Consistency across releases matters more than the choice of format.
Do I have to publish my SBOM?
The CRA does not require manufacturers to make the SBOM public. It must be part of the technical documentation and be given to a market surveillance authority that asks for it. Many companies share SBOMs with customers under contract.
Can I create an SBOM for firmware?
Yes. For Linux-based firmware the reliable approach is to unpack the image and list the packages and binaries inside it, rather than rely only on build files. KROMSE does this for Linux-based firmware images today; bare-metal and RTOS images are on the roadmap.