AI
What the CRA Actually Requires
The CRA is a list of ingredients. Food labels every ingredient; devices must list all software they contain. Manufacturers must keep that software updated, fix vulnerabilities, report vulnerabilities, and notify upstream communities when they find them. Kroah-Hartman framed this as good news for open source developers: companies are legally required to tell maintainers when they find security problems. That is information open source projects rarely receive today.
Who Falls Under the Law and Who Does Not
Hobby projects are out of scope until someone ships them in a product. Once that happens, the code is covered, and developers have no way to prevent it because open source cannot dictate use. The CRA splits responsibility into five groups: developers (individuals), stewards (foundations such as the Linux Foundation, Apache, and Mozilla), manufacturers, integrators, and distributors. Only foundations and companies carry direct obligations. Individual developers and consultants carry none.
What Stewards Must Do
A steward, meaning a legal entity like a foundation, must do exactly two things under the CRA. First, publish a contact point for reporting security bugs. Second, report fixed vulnerabilities. That is the complete obligation. Kroah-Hartman also noted that foundations must report infrastructure breaches, pointing to recent GitHub break-ins as an example. Reports go to a single EU platform or to a country-level CERT. The Linux Foundation will use one specific CERT close to its operations.
Tools That Already Satisfy the CRA
Three practical steps cover most requirements today. Becoming a CNA (CVE Numbering Authority) lets a project assign its own CVEs. Perl and Python already paved this path for open source groups. The OpenSSF best practices badge, which has existed for over a decade, meets and exceeds CRA requirements. The REUSE tool from the Free Software Foundation Europe generates a software bill of materials automatically and audits licenses in a machine-readable format. Only about one-third of CNCF projects currently produce SBOMs; more should.
The Implementation Timeline
The law is in force now but not yet enforced. In June 2025, the EU single reporting platform and assessment bodies go live. In September 2025, manufacturers must start reporting known and fixed vulnerabilities. Open source stewards and developers have one full additional year after that. Kroah-Hartman described watching manufacturers stress-test the system as useful: the open source community gets to observe them work out the problems before its own deadline arrives.
Notable Quotes
the CRA is very simple for us. Don’t worry. Greg Kroah Hartman · ▶ 3:21
Pearl or Python paved the way for us. They allow that open source groups issue and assign their own CVEs. Please do that. I strongly recommend it. Greg Kroah Hartman · ▶ 4:02
if you follow that, you’re covered. You are doing everything you need to do do for the CRA plus some. Greg Kroah Hartman · ▶ 4:18
Us open source stewards and developers don’t have to worry about this for another full year. So, we get to watch them work out the kinks, work out the bugs. Greg Kroah Hartman · ▶ 5:40
Key Takeaways
- Individual developers carry zero direct obligations under the CRA.
- Foundations need only a security contact and a process for reporting fixed vulnerabilities.
- The OpenSSF best practices badge already satisfies all CRA requirements for stewards.
- Becoming a CNA to self-assign CVEs is the single highest-value action a project can take now.
- Open source stewards have until at least September 2026 before enforcement applies to them.
About the Speaker(s)
Greg Kroah Hartman is a Fellow at the Linux Foundation. He maintains the stable Linux kernel release series and serves on the Linux kernel CVE team. He also maintains the USB, TTY, and driver core subsystems in the kernel. He served as an expert committee member for the CRA, representing the open source community alongside representatives from Eclipse and Apache.