What your SBOM has to list under the Cyber Resilience Act

The SBOM is the part of the Cyber Resilience Act that sounds like it needs a product to solve it. Most of the tooling built around the term is aimed at large software organisations with a supply chain team.

The obligation underneath it fits in one sentence. If you sell a product with digital elements under your own name, you will have to know what is inside it, and write that down in a machine-readable list.

What the text asks for

Annex I, Part II, point 1. You identify and document the components in your product, including by drawing up a software bill of materials covering at the very least the top-level dependencies.

Two parts of that carry the weight: at the very least, and top-level.

Top-level means your direct dependencies. The packages you chose and wrote into your manifest. Not the 400 things they pull in behind them.

At the very least means that floor can be raised by harmonised standards later, and that nothing stops you going deeper today. Most lockfile-based tooling gives you the full tree anyway, because that is the easy part.

The date is 2027, not this month

Annex I applies from 11 December 2027, under Article 71. So does the rest of the package: technical documentation in Annex VII, the conformity assessment, the EU declaration of conformity in Annex V, the CE marking, the support period. Penalties under Article 64 start on that same date.

What applies now, since 11 September 2026, is Article 14. Early warning within 24 hours of becoming aware of an actively exploited vulnerability, full notification within 72 hours, to the CSIRT designated as coordinator in your member state and to ENISA.

So the SBOM is not yet due. The reason to build one now is that it feeds the thing that is already due.

A plugin author with six direct dependencies

Take a developer selling a paid WordPress plugin. One product, a few hundred licences, no company behind it. Under Article 3(13) they are a manufacturer, because they place a product on the market under their own name in the course of a commercial activity. Article 3(22) covers that last part.

Their composer.json lists six requires. Their composer.lock resolves to 41 packages.

The Annex I floor is those six. The useful list is the 41. When a report lands saying a flaw is being used in the wild, the flaw will sit somewhere in the 41, and the question at 9am will be whether their build shipped the affected version.

That question has an answer in thirty seconds with a lockfile-derived list. Without one, it turns into an afternoon of reading release notes while a 24-hour clock runs.

The list matters because of what you check it against

Article 3(42) defines an actively exploited vulnerability: reliable evidence that a malicious actor exploited it in a system without the owner's authorisation. That definition is narrow on purpose. Most CVEs never meet it.

The public shortlist closest to it is the CISA Known Exploited Vulnerabilities catalogue, around 1,700 entries. Cross-referencing your dependency list against that catalogue is a small job, and it tells you which of your packages are in the category that starts a clock.

I built the free analysis on my site around exactly that loop. You give it a lockfile or a manifest, it produces a CycloneDX 1.5 bill of materials, queries OSV.dev for known vulnerabilities, and flags anything present in the KEV catalogue. It runs in the browser and only package identifiers leave your machine. Twenty lockfile and manifest formats are supported. Gradle is not, and Maven versions set by property or by dependency management are skipped.

If your product is already on the market

Article 69 handles that case. For products placed on the market before 11 December 2027, Article 14 applies, and the remaining obligations apply only in the event of a substantial modification. Recital 39 says security updates and bug fixes are not a substantial modification.

That leaves a fair number of small products in an odd position. Reporting duty now, Annex I later or possibly not at all for that version. Worth knowing which side of the line your product sits on before you plan any work.

What I would do this week

Generate the list once. Commit it to the repository next to the lockfile. Regenerate it on every release, from a script rather than by hand, so it stays true without anyone remembering.

Then read it. Six names take a minute, and that list is what you will want open when someone emails you evidence on a Tuesday morning.

If you are not sure the regulation reaches you at all, start with the scope test before the tooling: https://crakit.eu/scope/

Not legal advice.

This is not legal advice.