We Speak Supply Chain: SBOM, CBOM, HBOM
We Speak Supply Chain: SBOM, CBOM, HBOM
The Cyber Resilience Act mentions the software bill of materials once, in a single line of Annex I, and a good deal of the industry has read that line as the whole of the obligation. It is not. It is the minimum viable version of a much larger requirement, which is that you know what is in your product and can say, quickly, whether a given vulnerability touches it.
That requirement does not stop at software packages because it follows the vulnerability wherever it lives.
What the regulation actually says
Annex I, Part II(1) requires the manufacturer to identify and document the vulnerabilities and components contained in the product. It says this includes: […] drawing up a software bill of materials in a commonly used machine-readable format covering at the very least the top-level dependencies of the product[…].
Three things in that sentence are worth pulling out, because each of them is regularly misread.
Machine-readable is not a suggestion. SPDX or CycloneDX are the formats most likely to satisfy any future implementing act under Article 13(24), but the CRA itself has not yet named a specific format. A PDF listing your libraries is not an SBOM, it is a document about an SBOM. Your customer has to merge yours into theirs, and they cannot merge a PDF.
Top-level dependencies is a floor. It is what the regulation (as currently written) will accept as a bare minimum. It is not what a vulnerability in a transitive dependency cares about, and it is not what your customers are going to ask for. Log4Shell was not a top-level dependency for almost anyone who was hit by it.
The SBOM does not have to be published. This surprises people, so it is worth being exact. The SBOM belongs in your technical documentation under Annex VII, which is produced for market surveillance authorities on request. The regulation does not oblige you to hand it to the public or to your users.
That last point is where suppliers get comfortable, and that is a risk. Not being obliged to publish is not the same as not being asked. Your commercial customers carry Article 13(5) due diligence on the components they integrate, and they cannot discharge it against a component they cannot see inside. So they will ask, and they will ask in the contract rather than in the regulation. This also applies to you, on the components you sourced from your own suppliers.
Why the software list is not the whole list
The obligation, restated plainly, is to be able to answer one question under time pressure: does this vulnerability affect our product?
Now consider three vulnerabilities.
The first is in a Rust crate you depend on. An SBOM answers it.
The second is in a cryptographic primitive. Not a library bug, but the algorithm or the parameter choice itself, now considered broken or below state of the art. Your SBOM tells you that you ship a TLS library. It does not tell you which cipher suites you negotiate, which key lengths you generate, which signature scheme protects your update artefacts, or where in the product each of those is used. So it does not answer the question.
The third is in the firmware of a controller on your board, three suppliers upstream, shipped to you as part of a module. Your SBOM does not know that component exists. It is not software you compiled.
Two of those three vulnerabilities are invisible to the artefact the regulation names. Both of them are still yours.
CBOM, because state of the art has a date on it
Annex I requires you to protect confidentiality and integrity using state-of-the-art mechanisms. That phrase is doing the heavy lifting, because what qualifies keeps moving, and right now it is moving fast in one direction. The European Union Agency for Cybersecurity (ENISA) publishes its Agreed Cryptographic Mechanisms document on a regular cycle, which is why it is worth following: it tells you where the bar sits today. The CRA benchmark itself will be pinned down by harmonised standards and that same ENISA guidance.
The EU has a coordinated roadmap for migrating to post-quantum cryptography. The direction of travel is that high risk use cases should be transitioned by around 2030, with broader migration targeted for the middle of the decade after. Whatever the final dates, the practical implication is fixed. Over the support period of a product you ship in 2028, the cryptography in it will go from acceptable to deprecated.
A cryptographic bill of materials is the inventory that makes that migration possible. Algorithms, key sizes, protocol versions, certificate chains, where each is implemented, and which component owns it. CycloneDX has supported cryptographic assets for a while now, so this is not exotic tooling.
The reason to do it is simple. You cannot migrate what you cannot find. A crypto-agility programme that begins with a six month discovery exercise is a programme that begins six months late, and every integrator downstream of you is waiting on the answer before they can start their own.
HBOM, because a product with digital elements is often a physical thing
The CRA covers hardware. Products with digital elements include the device, not just the code on it, and Article 13(5) due diligence applies to every third party component you integrate, silicon included.
A hardware bill of materials records what is actually on the board. Components, part numbers, revisions, provenance, and critically the firmware each one carries and the version of it. That last association is the one that does the work, because firmware is where hardware and software vulnerability management meet, and it is routinely tracked by neither team.
If you build hardware and your vulnerability handling process only looks at the software you wrote, there is a gap in your product where a whole class of CVE lives. Your customers, particularly in industrial, medical and automotive, already know this. They have been asking for HBOMs for other reasons for years, and the CRA gives them a new one.
Your bill of materials is a fragment of somebody else’s
This is the part that matters most if you are a supplier. Your bill of materials is never the whole picture. It is a fragment of a larger one that your customer is assembling, and the job is to make your fragment fit.
Your customer does not want your SBOM as a document. They want it as an input. They are assembling a bill of materials for a product that contains your component, and yours has to compose into theirs. That means machine-readable, correctly versioned, complete enough to be useful, and delivered as part of the release rather than as a favour when someone remembers to ask.
An SBOM that arrives four weeks after the request, as a spreadsheet, describing a version they are not running, is worse than useless. It creates work and delivers nothing. It is also, from a procurement point of view, a very clear signal about what the rest of the relationship is going to feel like.
The twenty four hour test
The real test of a bill of materials is not a regulator’s audit but a Friday-afternoon vulnerability disclosure with a 24-hour reporting clock running.
A serious vulnerability is disclosed on a Friday afternoon. It is being exploited. Your customer has 24 hours to send an early warning under Article 14, and their first question is whether they are affected. Their second question is whether it came from you.
If your bills of materials are generated automatically, per release, and locked to the version, they can answer both questions in minutes and so can you. If they are maintained by hand, they will be answering on Monday, and the answer will be wrong.
That gap is the entire argument. Everything above is just details about how to close it.
What good looks like
- Generate the SBOM in the build, not afterwards. If a human touches it, it is already stale.
- Go past top-level dependencies. The regulation accepts the floor. Your customers and your incident response will not.
- Build a cryptographic inventory now, while post-quantum migration is still a planning problem rather than an emergency.
- If you ship hardware, record components and their firmware versions together. There is one problem.
- Version-lock all of it and retain it. A bill of materials that is not bound to a specific build cannot answer a question about that build.
- Ship it with the release, in a format your customer can consume without human intervention.
We speak supply chain
Comply.Land works on the CRA where it is actually written, in the harmonised standards, the essential requirements and the technical documentation. We know what a bill of materials has to contain to survive contact with a market surveillance authority, and what it has to look like to be usable by the customer who integrates your product.
We can help you get the generation into your pipeline, the retention into your infrastructure, and the delivery into your contracts.
Talk to us about your bill of materials
Note: CBOM and HBOM are industry terms, not CRA-defined obligations. They represent the practical scope of what the CRA’s state-of-the-art cryptography and hardware component requirements imply but the regulation itself names only the SBOM.
General information on Regulation (EU) 2024/2847, not legal advice. Article and Annex references are to the Cyber Resilience Act as published. Post-quantum migration timelines reflect EU policy direction and are subject to change.