CRA Implementation at Greenbone: How We Made the Reporting Obligation Operational

We already explained what requirements the Cyber Resilience Act imposes as of September 11, 2026, in a separate post on the implementation status of the CRA reporting obligation. This post answers the other half of the question: how the implementation was carried out at Greenbone itself.

One clarification up front, because it is decisive for how transferable this is: we did not implement all of these measures from scratch. Much of it was already established practice at Greenbone and, for the CRA, only needed to be documented, sharpened, or turned into a binding process. Anyone facing the same task today will probably find more substance already in-house than expected.

Requirement: A Process for Vulnerabilities and Incidents

The CRA does not ask for a reporting button, but for a resilient process behind it. Alongside our process for handling incidents, we have therefore implemented a Coordinated Vulnerability Disclosure process. It regulates, in detail, what happens once a vulnerability becomes known, including the responsibilities involved. It comes with a checklist that can be worked through step by step. We track security incidents in our own Jira project, so that every case has a ticket with a full history.

The importance of thinking in terms of a process shows up in one place in particular: the 24-hour clock in Article 14 starts running from the moment of becoming aware, and the Commission spelled out exactly what that means in its guidelines on the application of the CRA (C(2026) 5252), adopted in July 2026. The standard is a “sufficient degree of certainty,” referencing recital 31 of Implementing Regulation (EU) 2024/2690 and EDPB Guidelines 9/2022 (paras. 211–214). Without a defined triage step, this point cannot be dated in an actual emergency, and without a date the deadline cannot be demonstrably met. It should be noted that this guideline is explicitly non-binding (para. 8); it is an interpretive aid, not a legal basis.

Two deadlines should be tracked separately in the process, because they run differently: the final report for a vulnerability is due 14 days after the fix is made available, while the one for a severe security incident is due one month after the 72-hour notification (para. 215). Anyone who tracks both clocks in a single field will end up reporting late in one of the two cases.

One point that eases the burden, and is often overlooked in the current debate: vulnerabilities that were already known before September 11, 2026, do not create a retroactive reporting obligation (para. 217). The existing backlog therefore does not need to be reported after the fact.

Requirement: Pass on Vulnerabilities in Third-Party Components

If a flaw in our products originates in a third-party artifact, we notify that artifact’s provider so it gets fixed there. If we implement a fix ourselves, we make it available upstream.

This matches section 9.2.1 of the Commission guidelines on Article 13(6): anyone integrating a third-party component must report vulnerabilities to the party maintaining it, unless that party is already aware, and should share fixes in a machine-readable and license-compatible form wherever possible. Also clarified: the reporting obligation itself applies to actively exploited vulnerabilities in one’s own product, not to every unexploited flaw in a third-party component (para. 218).

Requirement: Reachable Notification for Those Affected

For actively exploited vulnerabilities and severe security incidents that can affect the security of our products, we publish advisories in CSAF format at the well-known path, apart from any exceptions under TLP:WHITE. For severe vulnerabilities that originate in our own code, we request and publish a CVE.

Why machine-readable? Because an advisory that exists only as a web page creates manual work for the recipient. Anyone who wants to know which roles in the CSAF ecosystem carry which obligations can find the breakdown in our post on CSAF 2.0 stakeholders and roles.

Important for setting expectations: the obligation under Article 14(8) to inform users is designed to be risk-based and proportionate, not a blanket obligation to publicly disclose every case (paras. 219–221). What needs to be published depends on the individual case, not on an automatism. Our exception to TLP:WHITE exists precisely for that purpose.

What Only a Scanner Vendor Can Do

For severe vulnerabilities in our products, we additionally build a vulnerability test, so that OPENVAS SCAN detects and reports the vulnerability. This building block is explicitly not meant to be replicated: it assumes you are a vulnerability scanner vendor yourself. For our customers, it means they don’t have to infer whether their own installation is affected from an advisory — they can measure it.

Requirement: Respond, Not Just Report

Depending on the severity of a flaw, we build an emergency release and make it available to customers. After a vulnerability has been handled, a post-mortem analysis follows.

Requirement: Being Reachable for Reports From Outside

So that people who discover a vulnerability can reach us, the Greenbone website has a page on reporting vulnerabilities in products, as well as a security.txt compliant with RFC 9116.

A tip from practice that costs nothing and saves a lot: test your processes, so you don’t only find out during an actual emergency that something doesn’t work the way it was meant to.

What’s still open for us is testing a notification to ENISA. As described in the previous post, the platform doesn’t yet exist in its final form. We can prepare for this point, but we can’t close it out yet.

Requirement: Knowing Your Own Supply Chain

Another part of our preparation for September 11, 2026, is that we generate SBOMs of our products automatically as part of the build process. This is where OPENVAS SECURITY INTELLIGENCE comes in, which we use to scan the SBOMs for vulnerabilities. Thanks to the daily updated meta feed, vulnerabilities in the components we use can be addressed early, so that exploitation in the wild never gets a chance to happen in the first place.

It’s also worth regularly checking your suppliers’ advisories, so you can update to fixed versions early. More and more vendors are publishing their advisories in CSAF format; that’s also the method preferred by the BSI, as laid out in BSI Technical Guideline TR-03191 and in the BSI’s recommendation on the use of CSAF. Here too, it’s worth using OPENVAS SECURITY INTELLIGENCE, which lets you download and analyze CSAF advisories on a regular basis, including access-restricted ones, for example every night or even every hour.

Checklist: Where Do You Stand on the CRA Reporting Obligation?

Self-check: where do you stand?

• A Coordinated Vulnerability Disclosure process with clear responsibilities is in place
• Vulnerabilities in third-party components are passed on to the party maintaining them
• Affected parties are informed via machine-readable advisories (e.g. CSAF)
• There is a defined process for emergency releases and post-mortem analyses
• External parties can easily report vulnerabilities (contact page, security.txt)
• SBOMs are generated automatically and monitored for vulnerabilities

What’s Transferable From This to You

The effort for September 11, 2026, is distributed unevenly. The reporting channels themselves — security.txt, contact page, CSAF path — are manageable in terms of effort. The process behind them, with responsibilities, a checklist and documented triage, takes longer to build and is what decides whether a 24-hour deadline is actually achievable. And the supply chain needs automation, because a manually maintained component list is out of date the moment it’s finished.

For the last two points, our SBOM scanning and supplier advisories come together in OPENVAS SECURITY INTELLIGENCE: one analysis in one place, instead of tracking feeds, spreadsheets and advisory pages separately.

If you want to hold your own implementation up against these points, there are two ways forward from here. Our overview of the Cyber Resilience Act summarizes requirements, deadlines and who’s affected, in case you’d like to work through the topic yourself first. And if one or more points from the checklist above are still open for you — whether that’s the CVD process, machine-readable advisories or automated SBOMs — talk to us directly about it.