Can you say what is inside your product?

What the EU's cybersecurity agency found

ENISA's SME survey on the Cyber Resilience Act (June 2026; 194 organisations, 31 countries) found high awareness but low readiness, with a software bill of materials in use at about 35% of respondents.[Report]

Two numbers describe most product companies in 2026. About 66% of the companies surveyed had heard of the Cyber Resilience Act. Only about 35% could produce a list of the software inside their own product.

ENISA's June 2026 SME survey found threat modelling and incident response to be the weakest areas, and company size the most consistent predictor of maturity.[Findings] In ENISA's June 2026 SME survey, financial support was the most-requested help, cited by 142 respondents.[Findings]

Awareness is not the problem. The problem is that the first concrete thing the law depends on is missing at most companies, and everything else stands on it.

Why that list comes first

Manufacturers must identify and document the components of the product, including a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies.[Annex I, Part II, point 1]

Read it as a dependency rather than as paperwork.

• Reporting needs it. The duty to report attacks is already live. Manufacturers' reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026.[Art. 71(2); Art. 14] You cannot know that a component you ship is under attack unless you know that you ship it — and a hand-kept list will not tell you the version.
• Fixing things needs it. Matching that list against vulnerability data is how "somebody published a security bug" becomes "it affects release 3.2, in the network code, fixed in 3.2.1".
• Your paperwork needs it. The list is part of what an authority can ask for, per release, for as long as you support the product.
• Your customers will ask for it. Importers, distributors and large buyers are writing supplier questionnaires right now, and "send us your component list" is the first line on most of them.

A company without one cannot report reliably, cannot fix things systematically and cannot assemble its paperwork. That is why this gap is the one to close first.

Why it is usually missing

Three reasons come up in every conversation.

It looks like a document. People hear "bill of materials" and reach for a spreadsheet. A spreadsheet is out of date within a release and nobody updates it. This has to be something your build produces.

Nobody owns it. It falls between engineering, security and quality, and each assumes another has it. Give it to whoever owns the build.

The format looks complicated. The standard formats are verbose. You do not read them; tools do. Producing one is a single step in your build.

An afternoon per technology

For each technology the pattern is the same: run a generator against what you actually ship, produce the standard file, sign it, keep it with the release, and send it to whatever matches it against vulnerability data.

Python. Generate from the resolved environment or the lock file after the build, not from the requirements list, so indirect dependencies and exact versions are captured.

Node. Generate from the lock file and the installed packages of the production build; leave out development-only ones unless you ship them.

Java and .NET. Generate from the build tool's own dependency resolution, at the module that produces the thing you ship.

Docker. Generate from the final image. It captures the operating system packages too, and that is usually where the surprises are.

Whatever you use: generate on every release, sign the file so a reader can tell it has not been altered, keep it with the release, and make the build fail if the generation fails. A release whose list is silently missing is a hole in your evidence that nobody notices until an authority or a customer does.

What to do with it

The law's minimum is the components you depend on directly. Go deeper if your generator can: the extra depth is free and the matching is better. Then two things make the file useful.

1. Match it. Send each list to a tool that checks it against vulnerability databases and against the lists of weaknesses attackers are using, and have a person look at new matches every working day.
2. Keep it. Store each release's list with its checksum next to the release, so you can answer "what was in version 3.2" for as long as you support it.

Five ways it goes wrong

• Generating from your source files instead of the built product, and shipping something different from what the list says.
• Generating once, by hand, for a questionnaire, and never again.
• Skipping the container image, where most operating-system weaknesses live.
• Producing the list and never matching it against anything.
• Publishing it by accident. You do not have to publish it; you have to have it and produce it on request. Decide on purpose.

The checklist

• Every shipped product has a generator in the build, producing the list on every release.
• It runs against the built product or image, not the source files.
• The list is signed and stored with the release, with its checksum.
• The build fails if the list is not produced.
• Each list is matched against vulnerability data that includes the under-attack lists.
• Somebody looks at new matches every working day and knows who decides what to do.
• The decision on whether to publish the list is written down.

If you want help

None of this needs us: the generators are free and the pattern above is the whole trick. If you would rather it was done and handed over, the first thing our sprint produces is one change proposed against your own build — a signed component list, a check that stops a bad build, and a published address for security reports — which your engineers review and merge. Getting the matching in step 1 above running is a separate fixed-price job: we choose a tool with you, set it up in an account you own, point the alerts at your own people and hand over the keys. We do not watch it for you afterwards. If you would rather see the gaps before deciding anything, our gap review runs the same tools over your code and maps what it finds to the law's requirements. Either way you end up running it, not us.

Book a scoping call