A Software Bill of Materials is an ingredients label for software: every package your application contains, with its version and licence. Until recently it was a large-enterprise concern. It is now arriving as a supplier questionnaire in ordinary companies' inboxes.
The reason it is arriving now is not that the idea is new — it is that regulation put a date on it. But the practical problem it solves is much older, and worth stating plainly before the acronyms start.
The problem an SBOM actually solves
When a serious vulnerability is published in a widely-used library, the first question every company is asked — by a customer, an insurer, a board — is the simplest possible one: are we affected?
Most companies cannot answer it quickly — not through carelessness, but because the honest answer requires a list nobody maintains. A modern web application declares perhaps forty dependencies and actually installs several hundred, because those forty bring their own. Nobody chose the extra ones and nobody wrote them down.
An SBOM is that list, generated rather than maintained. With one in hand, "are we affected?" becomes a text search instead of a week of archaeology.
What an SBOM contains
At minimum, every component in your software with the information needed to identify it unambiguously:
- Name and version — and these have to be exact. "Latest" is not a version, and a package name without its ecosystem is ambiguous, because the same name exists on npm and PyPI as different software.
- A unique identifier — usually a package URL such as
pkg:npm/lodash@4.17.21, which encodes ecosystem, name and version in one string that tooling can match reliably. - Licence — what you are legally permitted to do with it.
- Relationships — which component brought in which. This is what turns a flat list into something you can act on.
- Provenance of the document itself — who generated it, when, and with what tool.
That last point sounds bureaucratic and is not. An SBOM with no date is worthless: software changes weekly, so a bill of materials describes a moment, and a document that does not say which moment cannot be checked against anything.
SPDX and CycloneDX: what actually differs
There are two formats in real use. They overlap heavily, and the choice matters less than most comparisons suggest — but they come from different places and are good at different things.
SPDX began as a licence-compliance format and became an ISO standard in its 2.2.1 revision. Its centre of gravity is legal: precise licence expressions, clear statements about what is known and unknown, and the document metadata an auditor cares about. When procurement, a legal team or a regulation asks for "an SBOM" by name, this is usually the one they mean.
CycloneDX came out of OWASP and the security community, and it shows: it has a native place to record vulnerabilities and their analysis alongside the inventory. It has since been standardised as Ecma-424, so "not a standard" is no longer a reason to prefer the other. If the SBOM is going to be consumed by security tooling rather than filed, CycloneDX carries more of what that tooling wants.
The practical answer is to produce both. They are generated from the same underlying scan, so they cannot disagree, and it costs nothing to emit two files instead of one. Then hand over whichever the person asking can read.
The honesty problem: NOASSERTION
Here is the part that separates a useful SBOM from a misleading one.
Sometimes a component's licence cannot be determined — the package metadata is empty, or the licence field contains free text no parser recognises. A tool has two options: guess, or say it does not know. SPDX provides a specific value for the second, NOASSERTION, and it exists precisely because guessing is dangerous.
Downstream tooling treats an SBOM as fact. A guessed licence does not stay a guess: it gets ingested, reported, and eventually relied upon in a decision about whether you may ship. The same applies to versions — a component whose version cannot be established should be recorded as unknown, not given a plausible number, because that number will be matched against vulnerability databases as though it were established truth.
When you evaluate an SBOM tool, this is the thing to test. Point it at a project with a package it cannot fully resolve and see what it writes down. A tool that never says "unknown" is not more capable than one that does; it is less honest.
Who is going to ask you for one
Three groups, in roughly this order:
Your enterprise customers. Large organisations have to manage their own supply chain, and you are part of it. This arrives as a security questionnaire, often with a deadline attached to a contract renewal.
Your insurer. Cyber insurance underwriting has become considerably more specific about what a company can demonstrate.
Regulation. NIS2 already requires supply-chain security from the organisations in scope, and those organisations pass the requirement down to their suppliers — which is how a small software vendor ends up in scope without being named in the directive. The EU's Cyber Resilience Act goes further and phases in bill-of-materials obligations for products with digital elements across 2026 and 2027.
How to produce one
Not by hand. An SBOM written by a person is out of date the day it is written and wrong the day after.
It should be generated from the same resolution step that produces your actual dependency tree, which in practice means reading your lockfiles. A manifest such as pom.xml or a bare requirements.txt states intent rather than outcome, so an SBOM built from one alone will list the packages you chose and none of the ones they pulled in — which is usually the large majority. Why the two counts differ, and what to do about it, is worth reading alongside this.
What is an SBOM in simple terms?
A Software Bill of Materials is a machine-readable list of every package your software contains, with each package's version and licence — an ingredients label for software. Its practical purpose is to let you answer one question quickly: when a vulnerability is published in some widely-used library, are we affected? Without an SBOM that question takes days of investigation; with one it is a search.
What is the difference between SPDX and CycloneDX?
SPDX and CycloneDX describe the same thing and overlap heavily. SPDX began as a licence-compliance format and is now an ISO standard, so it is what procurement, auditors and regulation usually ask for by name. CycloneDX came from OWASP and the security community, has a native place to record vulnerabilities and their analysis alongside the inventory, and is standardised as Ecma-424, so security tooling tends to prefer it. Generating both from the same scan costs nothing and means you can hand over whichever the person asking can read.
Does NIS2 require an SBOM?
NIS2 requires supply-chain security from the organisations in its scope rather than naming the SBOM as a document, but those organisations meet the requirement by asking their own suppliers to account for what their software contains — which is how companies not directly in scope end up needing one. The EU's Cyber Resilience Act is more explicit and phases in bill-of-materials obligations for products with digital elements across 2026 and 2027.
How do I generate an SBOM for my project?
Generate the SBOM from your lockfiles rather than writing it by hand, because a lockfile states exactly what gets installed, including the transitive packages nobody declared. A hand-written SBOM is out of date the day after it is written. If your project has only a manifest such as pom.xml or a plain requirements.txt, the resulting document will be incomplete unless the tool resolves the rest — and it should say so rather than quietly listing fewer components.
Where CodeControl fits
CodeControl generates both formats — SPDX 2.3 and CycloneDX 1.5 — from the same scan of your connected repository, so the two documents agree by construction. An unrecognised licence is emitted as NOASSERTION rather than a guess, and the scan reports which parts of your project it could not read instead of quietly listing fewer components. It also exports a VEX document, which is the half of the story an SBOM does not tell. The technical description covers ecosystem coverage in detail.