A customer’s procurement team sends a list of questions, and one of them is short: can you provide a software bill of materials? Behind it sits a fair worry. Your product is built partly from code other people wrote, and when a weakness is found in one of those pieces, your customer wants to know whether it is inside what they bought.
This essay explains what the document is, where the request comes from, and what you should be able to answer. It is not legal advice, and nothing here tells you whether your product meets any law. That judgement belongs to you and your advisers.
What a software bill of materials is
It is a list of the parts your software is made of, and how those parts relate to each other. The U.S. National Telecommunications and Information Administration, in The Minimum Elements For a Software Bill of Materials (SBOM), published on 12 July 2021, describes it as “a formal record containing the details and supply chain relationships of various components used in building software.”
Why buyers and regulators ask for one
A buyer asks because a list makes a hard question answerable. When a weakness in a widely used component becomes public, a customer with your list can check it against their own records. A customer without one has to ask you, and wait.
In Europe, the request now has a legal basis for some products. Regulation (EU) 2024/2847, the Cyber Resilience Act, adopted on 23 October 2024, defines a software bill of materials in Article 3 as “a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements.”
Its vulnerability handling requirements in Annex I, Part II begin with point (1), which asks manufacturers to “identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.”
The same Regulation says who sees it. Annex VII, on technical documentation, includes it “where applicable” and “further to a reasoned request from a market surveillance authority”. Annex II, on information for users, asks where it can be accessed only “if the manufacturer decides to make available the software bill of materials to the user”. Under Article 71, Annex I applies from 11 December 2027.
Whether your product falls within the Regulation’s scope is a question for your advisers. Our essay The Cyber Resilience Act, for product leaders covers the scope, the dates and the rest of what the text asks, so we will not repeat it here.
What the minimum elements are
The NTIA report sorts its minimum elements into three areas: data fields, automation support, and practices and processes.
The data fields are the baseline facts recorded for each component:
- Supplier name: who created, defined or identified the component.
- Component name: what the supplier calls it.
- Version of the component: which release of it you use.
- Other unique identifiers: further identifiers that help find the component in other records.
- Dependency relationship: which component includes which.
- Author of SBOM data: who wrote the record.
- Timestamp: when the record was made.
For automation support, the report asks that the record be machine-readable, so that it can be read at scale. It names three formats that meet this: SPDX, CycloneDX and SWID tags.
Under practices and processes, the report covers how often a new record is made (with each new build or release), how deep it goes (at least the top-level components), how to mark what you do not know, how the record is shared and with whom, and how mistakes are accommodated.
What our own builds show
ClickDeeper, our own product, shows how quickly that record goes out of date. ClickDeeper shipped more than a thousand releases in three months. At that pace, a record that is not renewed with every release is out of date by the next one.
The parts change too. In the products we run, newly published versions of third-party packages wait 72 hours before they can ship in a product. New package versions wait before they reach you describes what that gives you.
What you should be able to answer
The request is short, but the honest answer rests on a few things someone in your company should own:
- Whether you can produce one, for the version a given customer runs.
- How deep it goes, and whether you mark the parts you are not sure of.
- Who keeps it current as new versions ship.
- Who may receive it, on what terms, and how a request reaches the right person.
- What you do next when one of the listed components turns out to have a weakness.
The last of these matters most to the customer who asked. A list shows what is inside; what they are really buying is confidence that you will act on it.
Settle these questions once and give each an owner. Then the next procurement list is a matter of looking things up, and you can lift your eyes to where the product is going.
Where we come in
We do not produce software bills of materials, and we do not audit your dependencies. We also do not give legal advice or promise compliance, and we will not tell you when you will be ready. The answers above stay yours to give.
Where we help is with security work on your product, the pieces you pick. We work within the access you grant, and nothing more. The work lands in your own code repository. The code we build for you is yours. You decide what ships. Nothing reaches your users without your approval. It starts with a conversation, with no obligation. Harden security before the questionnaire arrives shows what that work looks like.
