Heartbleed in OpenSSL
A flaw in a library that sat inside millions of products. Everywhere the same question: where exactly do we use OpenSSL, in which version, and in which shipped releases?
Cyber Resilience Act · Stage 1
Your SBOMs. Ten years. Searchable.
A vulnerability is being actively exploited. Once you become aware of it, no more than 24 hours remain for the early warning. Will you immediately know which released versions contain the affected component?
Produktakte archives the SBOMs of all your releases and makes them searchable and comparable. So when the next Jackson, Log4j, or XZ advisory hits, you look it up instead of guessing.
Timeline
Twelve years of the same question. And two deadlines that turn it into an obligation.
Amber: the days when thousands of teams had to know where a Library was hiding. Blue: the dates from which the CRA demands a documented answer.
Apache Struts: patch available, usage unknown
The patch was available in March. Six months later, it became known that the flaw had remained open at Equifax. Not out of malice. What was missing was the knowledge of where Struts was even running.
Log4Shell: the weekend of manual work
Half the industry combed through its dependencies by hand because nobody knew where Log4j sat as a transitive dependency. Exactly the case we lived through ourselves.
Spring4Shell: the same exercise, four months later
Anyone who had built a searchable archive after Log4Shell was done in minutes. Everyone else went back to writing mass emails to every team.
XZ Utils: a backdoor, not a bug
Smuggled in over more than two years. Without an SBOM history per release, there is no way to answer which shipped release contained the manipulated version. That is exactly what every customer asks afterwards.
The Cyber Resilience Act is in force
Regulation (EU) 2024/2847 has been in force since 10 December 2024. The obligations take effect in stages. The preparation period was part of the plan, not a gift.
Conformity assessment bodies can be notified
From here on, the infrastructure for conformity assessments is in place. For manufacturers, above all a signal: the timeline is no longer a theory.
Reporting obligation for actively exploited vulnerabilities
Initial report to BSI-CSIRT and ENISA within 24 hours, detailed report after 72 hours, then a final report. This also applies to products that have long been on the market. For that, you need to know within minutes which releases are affected.
Today: the clock is ticking
As of today the reporting obligation takes effect: report actively exploited vulnerabilities to BSI-CSIRT and ENISA within 24 hours. Until then, a reporting process needs to be set up and rehearsed. In 433 days the full application follows. From then on: an SBOM in machine-readable format per release, retained for at least ten years. Integrate SBOM generation into the build now and archive the history per release, and you meet both without a last-minute sprint.
SBOM obligation and ten years of retention
Anyone placing software on the EU market needs an SBOM in machine-readable format as part of the technical documentation. It must be retained for at least ten years, and correspondingly longer for a longer support period.
9 / 10
20112012201320142015201620172018201920202021202220232024202520262027202820292030
Case study
A Friday afternoon, one vulnerability, a hundred microservices
A vulnerability in a widely used programming library becomes public. The company runs over a hundred microservices, many use the library, some directly, some through transitive dependencies, without anyone knowing.
Every developer gets an email. Then another from the security department. Then one from the boss. Each team checks by hand. One requests a blanket exception, “doesn’t affect us directly”, and misses that a feature of an entirely different library pulls in the vulnerable version under the hood.
What it would have taken was a single search: which services contain the library, in which version, in which releases, including the ones still running at customer sites? Who needs to act, and who can keep working in peace?
What Produktakte can do
An archive that answers questions instead of merely storing files.
One library, one search, every hit across all products and releases, including transitive dependencies.
Impact search
118 services · 4,812 SBOMslibrary: com.fasterxml.jackson.core:jackson-databind version: < 2.15.0
payment-api
v4.2.0 – v4.7.1 · 2.14.2 · transitive via spring-boot-starter-web
legacy-portal
v1.3.4 · 2.13.0 · at a customer site, not updated since 2023
billing-worker
v2.9.0 · 2.15.3 · direct dependency
And the memory your scanner does not have
We do not scan ourselves and do not replace your scanner. We stand beside it and remember.
Unlimited history
Every SBOM of every release is retained and retrievable. Your scanner only shows the latest report? Or keeps only the last twenty? We show them all: ten years and longer, as the CRA requires.
Audit mode
The auditor asks, you show. Evidence of being affected — or not — at any point in time, exportable for the report.
Automatic delivery
SBOMs from your CI/CD pipeline land directly in the archive automatically, per build and release, no manual work. Or upload manually if you prefer.
Software alone does not solve a compliance problem
The auditor wants to see more than just a tool: a documented process — who records a vulnerability, who assesses it, by when it gets fixed, and where all of that is written down. We built these processes in an enterprise environment ourselves and had them audited. We pass that on.
Consulting
An assessment of your SBOM and vulnerability processes, with concrete steps toward CRA readiness.
On site or remoteWorkshops
One day with your team: generating SBOMs, managing them, working with them in an incident. Based on your own software, not on slides.
1 day · your codeWebinars
The compact introduction: what does the CRA require, from when, and what does that mean for your products? Good for an overview before you commit budget.
60 minutes · onlineFrom hands-on practice, based in Germany
We are software engineers who know this problem not from whitepapers but from incident calls and audits. We are based in Germany, know the EU regulation and the German interpretation by the BSI, and you can reach us without a ticket system, in your language.
Clear recommendations instead of vague statements and endless consulting.
Philip Marienfeld, Managing Director
Dipl. Inf. (FH)
Bring an SBOM and we will search together.
One meeting, your real data, no slide show. Afterwards you know whether the archive solves your problem.
Request a meetingTell us in two sentences where you stand.
No scripted sales call. We look at where you are and tell you what makes sense next.
Callback
Prefer to talk on the phone? Give us a time window in the form and we will call you back.
Frequently asked questions
Anything not covered here we answer by email, usually the same day.
What is an SBOM and who needs one?
A Software Bill of Materials is the table of contents of your software: every component and dependency with version and origin, machine-readable in CycloneDX or SPDX. Once the CRA fully applies, everyone who places software or products containing software on the EU market needs one — including suppliers.
When does the Cyber Resilience Act apply?
In two stages: from 11 September 2026, the reporting obligations for actively exploited vulnerabilities apply (initial report within 24 hours, detailed report within 72 hours, followed by a final report). From 11 December 2027, the full requirements apply, including an SBOM as part of the technical documentation and a retention period of ten years.
Do I have to publish my SBOM?
No. The SBOM is part of your technical documentation and must be presented to market surveillance authorities on request. The CRA does not require publication. Whether customers demand it contractually is a different question.
Isn't my scanner (Nexus IQ, Dependency-Track, or similar) enough?
For the present, often yes. Scanners assess what is in the build today and usually keep only a limited number of older reports. But the CRA questions are questions about the past: which release contained what, since when, including transitively? We add that memory to your scanner — we do not replace it.
We receive software from contractors. Whose problem is the SBOM?
Yours. And your contractor's. Whoever places the product on the market is liable for the documentation — including the supplied parts. In practice that means: put SBOM delivery into the contract, agree on format and timing, archive what arrives. We help with the wording.
What is an SBOM and who needs one?
A Software Bill of Materials is the table of contents of your software: every component and dependency with version and origin, machine-readable in CycloneDX or SPDX. Once the CRA fully applies, everyone who places software or products containing software on the EU market needs one — including suppliers.
When does the Cyber Resilience Act apply?
In two stages: from 11 September 2026, the reporting obligations for actively exploited vulnerabilities apply (initial report within 24 hours, detailed report within 72 hours, followed by a final report). From 11 December 2027, the full requirements apply, including an SBOM as part of the technical documentation and a retention period of ten years.
Do I have to publish my SBOM?
No. The SBOM is part of your technical documentation and must be presented to market surveillance authorities on request. The CRA does not require publication. Whether customers demand it contractually is a different question.
Isn't my scanner (Nexus IQ, Dependency-Track, or similar) enough?
For the present, often yes. Scanners assess what is in the build today and usually keep only a limited number of older reports. But the CRA questions are questions about the past: which release contained what, since when, including transitively? We add that memory to your scanner — we do not replace it.
We receive software from contractors. Whose problem is the SBOM?
Yours. And your contractor's. Whoever places the product on the market is liable for the documentation — including the supplied parts. In practice that means: put SBOM delivery into the contract, agree on format and timing, archive what arrives. We help with the wording.