If you develop software that could eventually end up in a commercial product distributed in the EU, you need to be paying attention to the Cyber Resilience Act (CRA). That’s even true if you’re developing open source software.
The CRA is an effort by the European Union (EU) to tackle a longstanding issue: software, hardware, and products containing them are often shipped with serious security flaws. Many of these products aren’t developed to be secure. Vulnerabilities that are found are often left unfixed. The purpose of the CRA is to change this situation by introducing mandatory cybersecurity requirements for products made available in the EU.
This will impact open source software (OSS). In a few cases OSS will be required to directly comply with the CRA. In most cases OSS isn’t required to directly implement the CRA requirements, but if the OSS is used as part of a commercial product, the users of the OSS will be required to implement the CRA. In addition, some OSS has an organization supporting it (aka an “OSS Steward”) and the CRA has some requirements on OSS stewards.
So What Is the CRA, Really?
The CRA is an EU regulation (a law not a suggestion) that will require many organizations to take security more seriously. The CRA’s scope is broad; it applies to almost any “product with digital elements” distributed in the EU, including software, if its purpose or foreseeable use has a data connection. The CRA doesn’t apply to pure websites or online services, but if they exist to support a product, then the CRA does apply.
The CRA requires manufacturers of commercial “products with digital elements” (including software developers) to take many actions, for example:
- Design, develop & produce the product to meet “essential cybersecurity requirements” as identified in the CRA
- Assess cybersecurity risks and apply that information throughout the product lifecycle
- Exercise due diligence when integrating third party components, including OSS
- Create technical documentation and assess CRA conformity
- Perform vulnerability reporting & handling, typically for at least 5 years
- Address and remediate vulnerabilities without delay
- Notify a “designated CSIRT” and ENISA of any actively exploited vulnerability or severe incident within 24 hours
The CRA definition of “commercial” is somewhat broad. Any intention to monetize a product makes it commercial. This includes charging a price, charging for services beyond costs, requiring personal data (beyond certain limited purposes), or accepting donations exceeding costs. If the OSS is “commercial” under the CRA definition, then whoever releases that OSS as a product is considered a “manufacturer” under the CRA.
Some organizations aren’t considered manufacturers but they do provide sustained support for some OSS projects. The CRA terms these organizations “OSS stewards” and imposes a few requirements on them.
The CRA takes a risk-based approach. Some products, such as operating systems, have stricter rules. But even “default” class products must meet essential cybersecurity and vulnerability handling requirements.
All of these rules matter because failing to comply can lead to steep penalties.
What This Means for OSS Developers
In most cases, the CRA doesn’t directly apply to a typical OSS project or its developers. The CRA does not apply to contributors to another’s OSS project – if it applies at all, it’s to the receiving project. If the OSS is not part of commercial activity, it’s not considered a product and then the CRA generally doesn’t apply. Many common activities of an OSS project are considered non-commercial, including receiving financial support or donations without intent for profit, receiving contributions, making releases, and being hosted on an open repository.
So you can just put some OSS on GitHub, GitLab, or elsewhere and completely ignore the CRA, right? No.If that OSS code ends up in a product that’s sold or distributed in the EU, then whoever ships that product is required to comply with the CRA. They are required to perform due diligence on the components they include, including OSS components. They’re required to report component vulnerabilities they find to the component maintainer, including OSS projects. That means organizations will start asking more from OSS maintainers: clearer documentation, disclosed vulnerabilities, perhaps even changes to development workflows. Expect increased scrutiny and requests—maybe even “demands”—from downstream users to “CRA-proof” your code. The Open Source Security Foundation (OpenSSF) has created a Global Cyber Policy Working Group to help developers and projects get ahead of legal requirements, including the CRA. They also maintain a page specifically about the CRA to support the OSS community in understanding its implications.
Many people work hard to develop awesome OSS, including making it secure, and that’s great. However, it’s inappropriate to make demands on OSS maintainers you don’t pay. As Thomas Depierre noted in “I am not a supplier”, “I am not providing you something that you bought from me… I put something online because I wanted to… You want me to work a certain way, I am more than happy to do it. But to do that… you are going to have to start to pay me. A fair price that we can negotiate.” I’ve suggested distinguishing between sources and vendors to distinguish “offering for free” from “paid support”.This means that organizations that need an OSS project to change something will often need to be willing to develop contributions itself to resolve a problem, or pay someone to address it. This also means that developers of OSS will increasingly need to understand the CRA, since increasingly many of these changes will be made to comply with the CRA. If you want to get smart about the CRA and gain insight into compliance, then check out our free express learning course about the CRA. In a few cases, an organization may choose to switch to use a completely different component in a product. Yet in many cases we think it’s better to work with existing OSS projects, as long as all parties honestly try to work together.
Finally, the CRA has a reasonable list of expectations for how to design software to be secure, and what to do when a vulnerability is found. Even if an OSS project is not legally required to meet the CRA, the CRA expresses some widespread societal expectations on what it means for software to be secure. It’s wise to take advantage of that. Again, most OSS project maintainers want the OSS they develop to be secure.
For almost all OSS developers there’s no need to panic. However, it is important to learn about this new law. It may directly affect you, it will directly affect your users, and it can provide some helpful guidance. We urge you to learn more, such as by taking this free course on the CRA. Software is now being regulated like almost any other product. You can try to ignore it, but it’s better to be prepared for it.