Will the European Cyber Resilience Act kill Open Source Software?

The European Union’s proposed Cyber Resilience Act (CRA) aims to bolster cybersecurity across the continent. However, it has sparked significant concern within the open source software community. Critics argue that the CRA could impose increased legal and financial responsibilities on open source contributors, potentially stifling innovation and damaging the open source ecosystem. Furthermore, the legislation’s vulnerability disclosure requirements could inadvertently expose software vulnerabilities to a larger audience, increasing the risk of malicious exploitation. This article delves into the potential implications of the CRA for open source software and the broader digital landscape in Europe.

The European “Cyber Resilience Act” (CRA) was introduced by the European Commission in September 2022. It aims to impose cybersecurity obligations for digital products and services within the European Union.

The CRA aims to protect consumers and businesses who purchase or use products or software with a digital component. It introduces mandatory cybersecurity requirements for manufacturers and retailers of these products, with this protection extending throughout the product lifecycle.

The proposed Cyber Resilience Act would ensure:

• Harmonized rules when bringing to market products or software with a digital component.
• A framework of cybersecurity requirements governing the planning, design, development, and maintenance of these products, with obligations to be met at each stage of the value chain.
• The obligation to ensure duty of care for the entire lifecycle of these products.

When the proposed regulation comes into effect, software and products connected to the internet will carry the CE marking to indicate that they comply with the new standards.

The European Parliament and Council will now deliberate on the proposed Cyber Resilience Act. Upon entry into force, stakeholders will have 24 months to adapt to the new requirements, except for a more limited grace period of 12 months regarding the reporting obligation imposed on manufacturers.

However, the CRA has raised concerns among open source software actors. The CNLL (National Council of Free Software), which represents more than 300 companies whose business model is based on open source, has stated that the CRA represents an existential threat to the European open source software sector.

The main concerns are:

• The CRA does not take into account the unique needs and perspectives of open source software, particularly as a modern methodology used to create software.
• The open source software community was not sufficiently consulted during the drafting of the CRA, despite the fact that open source software represents more than 70% of the software integrated into digital products in Europe.

The CNLL and other organizations have requested that the text be amended to limit its application to end products (hardware and software) and services, sold in a commercial contractual framework, unequivocally excluding open source software, distributed in source code or binary form, regardless of the entity that carries out its development (individuals, SMEs, startups, large groups…), as long as no commercial contractual relationship exists between the software’s author(s) and its users.

The Cyber Resilience Act (CRA) could have several implications for the open source software sector:

1. Increased legal and financial responsibility: The CRA could make software providers or modifiers, including open source software contributors, legally responsible or co-responsible for the presence of a security issue. This could lead to significant legal and financial risk for open source software actors, who are often not in a position to assume such responsibilities.
2. Deterrent effect on the development of open source software: If the CRA is implemented in its current wording, it could have a deterrent effect on the development and use of open source software in Europe. This could compromise the EU’s objectives in terms of innovation, digital sovereignty, and future prosperity.
3. Lack of consideration for the specificities of open source software: The CRA does not take into account the unique needs and perspectives of open source software, particularly as a modern methodology used to create software. This could lead to inappropriate constraints for open source software actors.
4. Lack of consultation of the open source software community: The open source software community was not sufficiently consulted during the drafting of the CRA, despite the fact that open source software represents more than 70% of the software integrated into digital products in Europe. This could lead to a lack of understanding of the specificities and needs of this community in the legislation.

To mitigate these threats, open source software actors are calling for the CRA to be amended to limit its application to end products and services, sold in a commercial contractual framework, and to unequivocally exclude open source software. They are also calling for better consultation of the open source software community in the drafting of legislation.

The Electronic Frontier Foundation (EFF), an international digital rights advocacy organization, has expressed its concerns about the Cyber Resilience Act (CRA). According to the EFF, the CRA could penalize open source software developers who receive any amount of monetary compensation for their work. Moreover, the CRA would require manufacturers to report actively exploited, unpatched vulnerabilities to regulators, which could expose these vulnerabilities to a larger audience and exacerbate the harms this legislation aims to mitigate.

The EFF points out that the CRA imposes liabilities for commercial activity that brings vulnerable products to market. Although the proposed law exempts not-for-profit open source contributors from what is considered “commercial activity” and thus liability, the exemption defines commercial activity much too broadly. Any open source developer soliciting donations or charging for support services for their software is not exempted and is thus liable for damages if their product inadvertently contains a vulnerability that is then incorporated into a product, even if they themselves did not produce that product.

The EFF joins others in raising this concern and calls on the CRA to further exempt individuals providing open source software from liability, including when they are compensated for their work.

Furthermore, the EFF raises concerns about the CRA’s vulnerability disclosure requirements. Article 11 of the proposed text requires manufacturers to disclose actively exploited vulnerabilities to the European Union Agency for Cybersecurity (ENISA) within 24 hours. However, the EFF argues that this requirement risks exposing these vulnerabilities to a larger audience, which could increase the risk of malicious exploitation of these vulnerabilities.

The EFF calls on European lawmakers to refrain from mandating inflexible deadlines for tackling security issues and to require that detailed reports about vulnerabilities are submitted to ENISA only after vulnerabilities have been fixed. In addition, detailed public disclosure of security fixes should be required.

The EFF also joined partner organization EDRi in calling for a safe harbor for researchers involved in coordinated disclosure practices. This safe harbor should not imply that other forms of disclosure are harmful or malicious. An EU-wide blanket safe harbor will give assurance to security researchers that they will not come under legal threat by doing the right thing.

More recently a blog post from GitHub titled “No cyber resilience without open source sustainability” provides additional insights and concerns about the Cyber Resilience Act (CRA). Here are the key points:

1. Regulation of Open Source Projects Receiving Donations: The CRA could potentially introduce a burdensome compliance regime and penalties for open source projects that accept donations. This could undermine the sustainability of these projects by reducing the resources available to maintainers.
2. Regulation of Open Source Projects with Corporate Developers: The CRA could regulate open source projects unless they have “a fully decentralised development model.” Any project where a corporate employee has commit rights would need to comply with CRA obligations. This could discourage companies from allowing their employees to contribute to open source projects, leading to a less innovative and less secure software ecosystem.
3. Potential Break of Coordinated Vulnerability Disclosure: The CRA could disrupt coordinated vulnerability disclosure by requiring any software developer to report to ENISA all actively exploited vulnerabilities within a timeline measured in hours after discovering them. This could lead to wide disclosure of unpatched vulnerabilities, making the open source ecosystem more perilous.

The blog post also mentions that the ITRE Committee in the EU Parliament will hold a vote on the CRA on July 19. If there are no objections, this highly technical text may become the final Parliament position. The final CRA will subsequently be negotiated among the Parliament, Council, and Commission. The Council text better reflects how open source software is built and maintained today, and the final negotiations could yield an effective CRA even if the final Parliament version is flawed.

Conclusion

The Cyber Resilience Act (CRA) represents a significant step in Europe’s efforts to enhance cybersecurity. However, its potential implications for the open source software community have raised serious concerns. Critics argue that the legislation, in its current form, could impose undue burdens on open source contributors and inadvertently increase the risk of software vulnerabilities being exploited.

New insights from GitHub’s blog post highlight additional concerns. The CRA could potentially introduce a burdensome compliance regime and penalties for open source projects that accept donations, thereby undermining the sustainability of these projects. It could also regulate open source projects unless they have “a fully decentralised development model,” potentially discouraging companies from allowing their employees to contribute to open source projects. Furthermore, the CRA could disrupt coordinated vulnerability disclosure by requiring any software developer to report to ENISA all actively exploited vulnerabilities within a timeline measured in hours after discovering them.

As the European Parliament and Council deliberate on the proposed CRA, it is crucial that these concerns are taken into account. The open source software community plays a vital role in the digital landscape, and any legislation that affects it should be carefully considered to ensure it supports, rather than hinders, this important sector.

The ITRE Committee in the EU Parliament will hold a vote on the CRA on July 19. If there are no objections, this highly technical text may become the final Parliament position. The final CRA will subsequently be negotiated among the Parliament, Council, and Commission. The Council text better reflects how open source software is built and maintained today, and the final negotiations could yield an effective CRA even if the final Parliament version is flawed.

As the timeline for the CRA’s implementation unfolds, it is essential for all stakeholders, particularly those who maintain an open source project, to consider how the regulation may impact them and the people who rely on their software. It is also crucial for these stakeholders to voice their concerns and opinions to their elected officials ahead of the crucial July 19 vote.

Expected timeline

The European Parliament’s ITRE Committee is set to vote on the proposed Cyber Resilience Act (CRA) on July 19. If there are no objections, this highly technical text may become the final Parliament position. The final CRA will subsequently be negotiated among the Parliament, Council, and Commission. The Council text better reflects how open source software is built and maintained today, and the final negotiations could yield an effective CRA even if the final Parliament version is flawed.

Once the regulation comes into effect, stakeholders will have 24 months to adapt to the new requirements, with a more limited grace period of 12 months regarding the reporting obligation imposed on manufacturers. The exact dates of the vote and application of the law will be determined in the coming months. It is crucial for all stakeholders, particularly those who maintain an open source project, to consider how the regulation may impact them and the people who rely on their software. It is also crucial for these stakeholders to voice their concerns and opinions to their elected officials ahead of the crucial July 19 vote.will be determined in the coming months.

What can we do?

1. Contact Your MEPs: Reach out to your Members of the European Parliament (MEPs) to express your concerns about the CRA. Share your expertise and explain how the proposed legislation could impact you, your project, and the broader open source community. The first step is to identify who your MEPs are. You can find a list of all MEPs on the official website of the European Parliament. You can search by your country and then by your region to find the MEPs who represent you.
2. Join or Form Advocacy Groups: Join existing advocacy groups that are working to influence the CRA, or consider forming a new group if none exist that represent your specific concerns. These groups can provide a platform for collective action and can amplify individual voices.
3. Publicize Your Concerns: Use your platforms, such as blogs, social media, and community forums, to publicize your concerns about the CRA. The more people are aware of the issues, the more pressure can be put on lawmakers to address them.
4. Engage with the Media: Reach out to journalists and media outlets to share your story. Media coverage can be a powerful tool for raising awareness and putting pressure on lawmakers.
5. Collaborate with Other Stakeholders: Reach out to other stakeholders in the open source community, such as other developers, users, and even businesses that rely on your software. By working together, you can present a united front and have a stronger influence on the legislation.

Links

1. Cyber Resilience Act | Shaping Europe’s digital future — European Union
2. 52022PC0454 — EN — EUR-Lex — European Union
3. European Cyber Resilience Act (CRA)
4. Cyber Resilience Act text, Preamble 1 to 10 (15.9.2022)
5. Cyber Resilience Act — Wikipedia
6. EU Council releases Cyber Resilience Act compromise text
7. NIS2 and the Cyber Resilience Act (CRA): What You Need to Know
8. https://github.blog/2023-07-12-no-cyber-resilience-without-open-source-sustainability/

AI-augmented Gaël Duval. July 14th 2023.

More about /e/OS: https://e.foundation — More about Murena products & services: https://murena.com

Follow me on @gael_duval on Twitter, @gael@mastodon.social on Mastodon.