EU's Cyber Resilience Act raises concerns about open source and cybersecurity

The European Union is revising its proposed Cyber Resilience Act (CRA), which aims to strengthen Europe's defenses against cyber attacks and improve product security. The law targets a wide range of products marketed to European consumers, including Internet of Things (IoT) devices, desktop computers and smartphones. It imposes vulnerability disclosure requirements on device manufacturers and distributors, and introduces new cybersecurity incident liability provisions.

The Electronic Frontier Foundation (EFF), a leading nonprofit international legal organization, welcomed the intent of the legislation, but also expressed concern that it raises concerns about open source and cybersecurity: the proposed law would penalize open source developers who receive any additional revenue for their work. It would also require manufacturers to report actively exploited, unpatched vulnerabilities to regulators. This requirement has the potential to expose the circumstances and exploitation of these vulnerabilities to a wider audience, further exacerbating the harm the legislation is intended to mitigate.

1. Threats to open source software

Open source software is the backbone of the modern Internet. The contributions of developers of open source projects such as Linux and Apache are freely used and incorporated into products distributed to billions of people around the world. This can only be achieved through revenue streams that reward developers for their work, including individual donations, foundation grants and sponsorships. This development and funding ecosystem is integral to the operation and security of today's software-driven world.

The CRA imposes liability on commercial activities that bring vulnerable products to market. While Section 10 of the proposed law exempts non-profit open source contributors from liability by exempting "commercial activities," the exemption defines commercial activities too broadly. Any open source developer who solicits donations for their software or charges for support services is not exempt, so they would be liable for damages if their product inadvertently contains a vulnerability and then incorporates it into the product, even if they did not make the product themselves. Often, open source contributors and developers write software and make it available to others out of goodwill and gratitude. If these developers receive even a bounty for their work, it will put them at risk. Small organizations that produce open source code for the public good may subject their entire operation to legal challenges simply because they lack the funds to take the risk. This would force developers and organizations to abandon these projects altogether, damaging the entire open source environment.

In response, the Electronic Frontier Foundation calls on the CRA to further exempt individuals who provide open source software from liability, including when they are paid for their work.

2. Vulnerability disclosure requirements pose a cybersecurity threat

Article 11 of the proposed text requires manufacturers to voluntarily disclose exploited vulnerabilities to the European Union Agency for Cyber Security (ENISA) within 24 hours. ENISA would then be required to forward details of these vulnerabilities to member states' Computer Security Incident Response Teams (CSIRTs) and market surveillance bodies. As a measure of accountability, this requirement would provide an incentive for product manufacturers with poor product security records to actively seek out and mitigate vulnerabilities. Regardless of intent, this requirement is likely to have unintended consequences for manufacturers who prioritize product security. Vulnerabilities that pose a serious security risk to consumers are often treated as closely guarded secrets by these companies until the fix is properly applied and deployed to the end device. These vulnerabilities can take weeks or even months for the proper fixes to be applied.

The short time frame can prevent companies from applying "deep" fixes that correct the root cause of the vulnerability, opting instead for "shallow" fixes that only address the symptoms. Deep fixes take time, and the 24-hour requirement will start a timer on the response and will result in a haphazard patchwork response.

The second impact is that more organizations and people will soon become aware of the vulnerabilities, which will greatly increase the risk that they will be exposed to someone who might want to exploit them maliciously. Government knowledge of a range of software vulnerabilities in manufacturers could create tempting targets for hacking and espionage. Manufacturers concerned about the security outcomes for their customers have little control or insight into the operational security of ENISA or member state agencies that are aware of these vulnerabilities. This reporting requirement increases the risk that vulnerabilities will be added to the offensive arsenal of government intelligence agencies. Manufacturers should not be concerned that reporting flaws in their software will lead to further development of cyber warfare capabilities at their expense.

Another issue is that the reporting requirements do not include public disclosure. In order for consumers to make informed decisions about the products they purchase, security updates should be provided along with details about security vulnerabilities.

Given the significant risks associated with this requirement, the Electronic Frontier Foundation calls on European legislators to refrain from imposing inflexible deadlines for fixing vulnerabilities to address security issues and to release detailed reports on vulnerabilities to ENISA only after they have been fixed. In addition, detailed disclosure of security fix procedures is needed. Stricter requirements may be imposed on companies that are mediocre at product security - but this should be the exception, not the rule.