control
software bill of materials and component checks
A list of the software components inside what you build or buy, and the habit of checking it against new vulnerabilities. The CRA requires the list from manufacturers. For everyone else it is a practice that makes the supplier and patching rules answerable.
- what it protects
- you can say within a day whether a new flaw is in anything you build or run
- who owns it
- head of engineering, with the head of IT for bought software
- start with
- one product: generate its list in the build, then match it to new reports
what it is
A software bill of materials, or SBOM, is the ingredient list of a piece of software: every component inside it, with its name, version and source. Nearly all software is assembled from other people’s code, including open-source libraries. When a flaw is found in one of them, the list is what lets you say whether you are affected.
Two groups need it. If you build and sell software or connected products in the EU, the Cyber Resilience Act asks you to keep the list in a machine-readable format, and to do due diligence on third-party components. Its main duties apply from 11 December 2027. If you only buy software, no text read for this page requires you to hold a list, and NIS2 does not mention one. NIS2 does ask for supply chain security and for vulnerability handling. Knowing what is inside what you run is the practical way to answer both.
The habit matters more than the file. Generate the list in the build, store it with the release, match it to new vulnerability reports on a schedule, and give each hit an owner and a decision. For bought software, ask the supplier for its list and write the answer into the contract.
basis CRA Annex I Part II; CRA Art. 13(5); NIS2 Art. 21(2)(d); NIS2 Art. 21(2)(e). Holding a list as a buyer, the matching schedule and the owners are practice.
how a component list is made and used
- 1buildthe list is generated from the code that ships
- 2storekept with the release it describes
- 3matchcompared to new vulnerability reports on a schedule
- 4decidea named owner triages each hit and writes the decision
every release starts the list again
basis working practice. No legal text sets this.
an example
Picture a company of 120 people that sells a web application and runs a dozen bought systems.
An engineer typed up a component list for an audit last spring. A new flaw in a widely used library is announced. Nobody can say which products contain it, so three people read code and the answer is still a guess.
Each release builds its own list and stores it with the version. New reports are matched every month and a named engineer decides on each hit. For bought software, the contracts ask the supplier for its list.
An illustration. It is not a real case.
what it has to do for each rule
| rule | where | what the text asks | what the control has to do |
|---|---|---|---|
| CRA | CRA Annex I Part II | A manufacturer keeps a record of the product's components in a software bill of materials, in a commonly used, machine-readable format that covers at least the top-level dependencies. | If you sell software or connected products, produce the list from the build and regenerate it with every release. The main duties apply from 11 December 2027. |
| CRA | CRA Art. 13(5) | Third-party components, including open-source ones, need due diligence. | Decide before a component goes in who checks its source, its maintenance and its known flaws, and keep a note of the check. |
| NIS2 | NIS2 Art. 21(2)(d) | Supply chain security, including relationships with direct suppliers and service providers. | For software you buy, ask the supplier what is inside and how it tells you about flaws. The text does not mention a bill of materials, so asking is a practical way to meet the rule and the law does not demand it. |
| NIS2 | NIS2 Art. 21(2)(e) | Security in acquisition, development and maintenance, including vulnerability handling and disclosure. | Use the component list to find which of your products and systems contain a newly disclosed flaw, and record what you did about it. |
basis CRA Annex I Part II; CRA Art. 13(5); NIS2 Art. 21(2)(d); NIS2 Art. 21(2)(e). The CRA binds manufacturers. NIS2 does not name a bill of materials. What the control has to do is practice.
what to look for when you choose
- Is the list produced by the build itself, so it matches what shipped, or typed up by hand afterwards?
- Does it use a commonly used, machine-readable format, and does it go past the top-level dependencies into what those pull in?
- Does it record the name, version and source of each component, and the licence?
- Can it be matched against newly disclosed vulnerabilities on a schedule, with an alert to a named person?
- Can it tell you within a day which of your products or systems contain a given component?
- For bought software: will the supplier give you its list, and on what terms? Put the answer in the contract.
- Does it keep each release's list, so you can answer about a version shipped two years ago?
- How does it treat components you cannot see into, such as closed binaries and services you call?
basis working practice. No legal text sets this.
three levels, from first step to strong
Each level adds something visible. Stop where the risk you accepted allows.
- start
Pick one product and generate its component list in the build. Name one person who reads the matches.
- solid
Do it for every product you build, keep each release's list, match on a schedule and ask suppliers of key software for theirs.
- strong
Go below the top-level dependencies, record due diligence for every new third-party component and put the list clause into supplier contracts.
basis working practice. No legal text sets this.
where it goes wrong
a list nobody matches
A bill of materials that sits in a folder answers no question. The value comes from matching it to new vulnerability reports and acting on the hits.
top level only
The first layer of dependencies is the minimum the CRA names. Most of the code you run arrives one or two layers down, so go deeper where you can.
a one-off export
A list made once for an audit is out of date at the next release. Generate it in the build, every time.
alerts with no owner
A feed of findings that no one is assigned to read produces a backlog and a false sense of cover. Name an owner and a response rule.
treating the list as a verdict
The list shows that a component is present. It does not show that the flaw can be reached in your product. Triage each hit and write down the decision.
basis working practice. No legal text sets this.
the proof it leaves
| what you can show | who owns it | refresh |
|---|---|---|
| the current component list for each product you build, with the release it belongs to | head of engineering | every release |
| the record of due diligence on new third-party and open-source components | head of engineering | when a component is added |
| match results against new vulnerability reports, with the decision taken on each hit | head of IT or security lead | monthly |
| supplier answers on component lists, and the contract clauses that cover them | head of IT | yearly |
basis practice. The rhythms are your choice.
check it yourself
- Regulation (EU) 2024/2847 (Cyber Resilience Act) (EUR-Lex)
- Directive (EU) 2022/2555 (NIS2) (EUR-Lex)
your next step
Pick the one product you build or depend on most and find out whether anyone can list the components inside it today.