The EU is in the middle of the amendments process for its proposed Cyber Resilience Act (CRA), a law intended to bolster Europe’s defenses against cyber-attacks and improve product security. This law targets a broad swath of products brought to market intended for European consumers, including Internet of Things (IoT) devices, desktop computers, and smartphones. It places requirements on device manufacturers and distributors with regards to vulnerability disclosure, and introduces new liability regulations for cybersecurity incidents.
EFF welcomes the intention of the legislation, but the proposed law will penalize open source developers who receive any amount of monetary compensation for their work. It will also require manufacturers to report actively exploited, unpatched vulnerabilities to regulators. This requirement risks exposing the knowledge and exploitation of those vulnerabilities to a larger audience, furthering the harms this legislation is intended to mitigate.
Threats to Open Source Software
Open source software serves as the backbone of the modern internet. Contributions from developers working on open source projects such as Linux and Apache, to name just two, are freely used and incorporated into products distributed to billions of people worldwide. This is only possible through revenue streams which reward developers for their work, including individual donations, foundation grants, and sponsorships. This ecosystem of development and funding is an integral part of the functioning and securing of today’s software-driven world.
The CRA imposes liabilities for commercial activity which bring vulnerable products to market. Though recital 10 of 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 thus liable for damages if their product inadvertently contains a vulnerability which is then incorporated into a product, even if they themselves did not produce that product. Typically, open source contributors and developers write software and make it available as an act of good-will and gratitude to others who have done the same. This would pose a risk to such developers if they receive even a tip for their work. Smaller organizations which produce open source code to the public benefit may have their entire operation legally challenged simply for lacking funds to cover their risks. This will push developers and organizations to abandon these projects altogether, damaging open source as a whole.
We join others in raising this concern and call on the CRA to further exempt individuals providing open source software from liability, including when they are compensated for their work.
Vulnerability Disclosure Requirements Pose a Cybersecurity Threat
Article 11 of the proposed text requires manufacturers to disclose actively exploited vulnerabilities to the European Union Agency for Cybersecurity (ENISA) within 24 hours. ENISA would then be required to forward fine details of these vulnerabilities on to the Member States’ Computer Security Incident Response Teams (CSIRTs) and market surveillance authorities. Intended as a measure for accountability, this requirement incentivizes product manufacturers with a lackluster record on product security to actively pursue and mitigate vulnerabilities. However well intended, this requirement will likely result in unintended consequences for manufacturers who prioritize their product security. Vulnerabilities that have serious security implications for consumers are often treated by these companies as well-guarded secrets until fixes are properly applied and deployed to end devices. These vulnerabilities can take weeks or even months to apply a proper fix.
The short time-frame will disincentivize companies from applying “deep” fixes which correct the root cause of the vulnerability in favor of “shallow” fixes which only address the symptoms. Deep fixes take time, and the 24-hour requirement starts the timer on response and will result in sloppy patchwork responses.
The second effect will be that a larger set of agencies and people will be made aware of the vulnerability quickly, which will greatly expand the risk of exposure of these vulnerabilities to those who may want to use them maliciously. Government knowledge of a range of software vulnerabilities from manufacturers could create juicy targets for hacking and espionage. Manufacturers concerned about the security outcomes for their customers will have little control or insight into the operational security of ENISA or the member-state agencies with knowledge of these vulnerabilities. This reporting requirement increases the risk that the vulnerability will be added to the offensive arsenal of government intelligence agencies. Manufacturers should not have to worry that reporting flaws in their software will result in furthering cyber-warfare capabilities at their expense.
An additional concern is that the reporting requirement does not include public disclosure. For consumers to make informed decisions about their purchases, details about security vulnerabilities should be provided along with security updates.
Given the substantial risks that this requirement poses, we call on European lawmakers to abstain from mandating inflexible deadlines for tackling security issues and that detailed reports about vulnerabilities are issued to ENISA only after vulnerabilities have been fixed. In addition, detailed public disclosure of security fixes should be required. For companies that have shown a lackluster record on product security, more stringent requirements may be imposed—but this should be the exception, not the rule.
Further Protections for Security Researchers
Good-faith security research—which can include disclosure of vulnerabilities to manufacturers—strengthens product security and instills confidence in consumers. We join our 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.
Start With a Good First Step
The Cyber Resilience Act is intended to strengthen cybersecurity for all Europeans. However, without adopting changes to the proposed text, we fear aspects of the act will have the opposite effect. We call on the European Commission to take the concerns of the open source community and security professionals seriously and amend the proposal to address these serious concerns.