The Cyber Resilience Act was introduced by the European Parliament in September 2022. Its purpose is to establish cybersecurity requirements for devices and software marketed in the EU. Everybody who places digital products in the EU market will be responsible for additional obligations around reporting and compliance, such as fixing discovered vulnerabilities, providing software updates, and auditing and certifying the products.
The Act shifts much of the security burden onto those who develop software, as opposed to the users of software. This can be justified by two assumptions: first, software developers know best how to mitigate vulnerabilities and distribute patches; and second, it’s easier to mitigate vulnerabilities at the source than requiring users to do so.
But as an open source developer, are you covered by the CRA? And what obligations does the CRA place on you? The rest of this post can help you figure that out.
Mirko BoehmStep 1: Are you covered by the CRA?
At its core, the CRA puts its obligations on software manufacturers: those who publish code that is available in the EU. This base category essentially covers anyone who publishes software on the Internet, open source or not, regardless of whether you’re in the EU or not – as you would likely have EU users.
Next, you can follow this checklist to see if the CRA affects you. If you are an...
- Individual developer of OSS: You are probably excluded by the CRA requirements, even if you occasionally accept donations. But if you regularly charge or accept recurring donations from commercial entities (for example, if you do open source consulting), you’ll likely be covered by the CRA.
- Nonprofit foundation developing open source: You will likely need to comply with the CRA requirements. However, there are some potential amendments to the CRA, that if passed, might exclude certain open source projects that have a “fully decentralized development model” — i.e., not controlled by a single company or entity.
- Private company developing, commercializing or supporting open source software: You will very likely be covered under the CRA.
Finally, note that while the above list involves common actors in the open source community, the CRA also similarly applies if you are developing closed source software. For example, if you are a private company developing closed source software, you will likely be covered under the CRA as well.
Step 2: What obligations does the CRA require?
The obligations of the CRA depend on the criticality of the software project. Certain categories of software (both open source and closed source) are classified as “Critical” and further classified into “Class 1” or “Class 2.” Software that is “Critical” has greater requirements under the CRA, adding to the base requirements imposed on “non-critical” software. Here is an overview of which software falls under which category:
Category | Description | Examples |
Non-critical products | Everything else | Python, React (open source) |
Critical Class 1 | Includes web browsers; password managers; VPNs; network management systems; firewalls; identity management systems (full list in Annex III) | Firefox, OpenVPN, Bitwarden, VNC clients (open source) Google Chrome, Cisco AnyConnect Secure Mobility Client (closed source) |
Critical Class 2 | Includes desktop and mobile operating systems; Container runtime systems; Public key infrastructure and digital certificate issuers; Hardware Security Models (full list in Annex III) | Android, Linux, Docker, Kubernetes, OpenSSL, certbot (open source) Microsoft Windows (closed source) |
Next, let’s take a look at the CRA’s obligations. The CRA imposes four major categories of obligations on developers: risk assessments, documentation, conformity assessments, and vulnerability reporting. Below is a selected list of obligations (note the increased set of obligations for “critical” products):
Obligation | Details |
Risk Assessment | The developer must perform a cybersecurity risk assessment that ensures the following about the product (full list in Annex I):
The risk assessment also covers the following vulnerability handling requirements (full list in Annex I):
|
Documentation | The product documentation must have the following (full list in Annex V):
|
Conformity Assessment | For non-critical products, the developer can perform a conformity assessment themselves by ensuring and attesting that their product meets all the requirements. They should affix “CE” to their products to signal that it’s been met (see Annex VI). For Critical Class 1 and Class 2 products, the assessment must be done by a “notified body” – i.e. an independent auditor certified by the EU. The notified body will examine the developer’s submission to ensure the software conforms to the requirements. |
Vulnerability Reporting | Within 24 hours of being aware of an actively exploited vulnerability, the developer must notify the vulnerability to the European Union Agency for Cybersecurity (ENISA). |
Step 3: How do I comply with these obligations?
If you determine that your project is subject to the CRA, you will need to comply with it. As described above, you must perform a risk assessment that ensures certain cybersecurity requirements; publish extensive documentation that includes an EU Declaration of Conformity and an SBOM; perform a conformity assessment; and continuously maintain an active vulnerability reporting process.
We hope that some of these requirements will be made easier using automated tooling. For example, just like SBOMs can be generated from GitHub repositories, perhaps additional developer tooling can facilitate vulnerability reporting, security updates, categorizing software as Critical / Class 1 / Class 2, and publishing the documentation required by the CRA. But not all requirements are automatable and may require a substantial amount of ongoing work to comply.
The problem, and what’s next for the open source software community
If you think the above requirements are onerous, you may have a point. The root of the problem is this: the assumptions the CRA makes about software manufacturers do not necessarily hold for open source software developers. Open source software developers, whether individual developers or nonprofit foundations, may not in fact know who all is using their software, particularly because it is freely distributed. Thus, obligations such as vulnerability remediation and providing security patches to downstream users may simply not be feasible for developers who offer software for free, unless they abandon the open source development model.
Let’s take an analogy: OSS is like a timer component that could be put into devices as wide as a car, a virtual server, or a nuclear reactor. A developer of a component that counts time and sends an alert doesn’t know all the use cases for how it’s used, as opposed to whoever decides to put it into a smartphone, a car, or a nuclear reactor. Perhaps it would be better to put requirements on those who use software as opposed to those who develop and share it for free.
And indeed, various members of the open source software community, such as individual developers and open source foundations, have expressed concerns around the obligations the CRA puts on developers of open source software (e.g. 1, 2, 3, 4). To its credit, the Act recognizes the difficulty of applying to OSS projects and tries to make an exemption for open source software in Annex 10, by exempting not-for-profit open source contributors who don’t engage in “commercial activity.” However, this term has been cause for some concern. Maintainers or nonprofit foundations who regularly accept fees or donations may still be subject to the act’s requirements.
The Act's stance on donations, even from non-commercial sources, could inadvertently discourage larger contributions. And an organization that develops open source may be disincentivized to release projects as OSS or contribute to OSS in the first place. After all, the CRA would just increase the legal risk of open sourcing a project, incentivizing companies to keep more software proprietary and closed.
What can we do about it?
While the Cyber Resilience Act is still in a draft phase, it will likely be finalized soon. We hope the EU takes into account the feedback from the open source software developer community. It is a good idea to invest in better tooling, standards, and vulnerability remediation and dependency identification procedures. But we should explore ways to achieve these goals without putting additional burdens on the open source community and individual developers.
This is a critical time for open source — as we change the incentives and responsibilities around software security, we should make sure these changes don’t come at the expense of the open source software development model. After all, open source software has both created incredible communities of collaborative development and public digital infrastructure we all rely on. Go to https://linuxfoundation.eu/cyber-resilience-act to see how you can get involved and make sure your voice is heard!
