The EU Cyber-Resilience Act's approach to open source must be reconsidered
The draft EU Cyber-Resilience Act (CRA), backed by MEPs in July, is intended to reduce the risk of European citizens experiencing data breaches and malicious attacks on their devices. The CRA aims to achieve this by mandating security best practices across Europe’s tech industry. As part of this, it will enforce minimum security standards for end-user tech products sold across the EU, such as IoT devices, desktop computers, and smartphones.
To realise its goals, the CRA also needs to apply these standards to the software and hardware that make up the supply chains behind end-user products. However, along with commercial solutions within the software supply chain, the CRA is looking to apply these strict security standards to non-commercial open source projects and communities. This could place tens of thousands of volunteers at risk of legal action and do significant harm to the continent’s tech sector. The legislators behind the CRA need to urgently revisit how they treat open source software.
Why the CRA poses problems for open source
The CRA aims to place legal obligations on organizations to ensure the products and services they sell to the public are sufficiently secure. This requires organizations to ensure their products meet set standards for reporting, documentation, risk assessments, and post-release security patching and monitoring. Organizations that fail to do this risk liability for security incidents down the line, along with fines for noncompliance.
To work in practice, the CRA must also extend this regime to the software supply chain -- the vendors and developers who distribute software reused in end-user products. All software that ships in the EU must be self-certified by developers as being secured according to the CRA’s standards. This is where the main problem arises, as a large part of the software supply chain consists of open source software (OSS). In fact, up to 97 percent of all applications are believed to include OSS code. As the CRA currently stands, communities that maintain OSS projects must apply the same security standards to their work as the companies that sell commercial solutions. Worryingly, they could be legally liable for any downstream security incidents that arise due to issues with their code.
OSS communities are non-commercial and arise from volunteer contributions, so very few have the resources to ensure their code is fit to be self-certified under the CRA. This opens the risk of European OSS contributors and communities either ceasing operations or being subject to legal action that they do not have the finances to deal with. Since OSS software is the powerhouse of the technology industry at large, owing to its ubiquitous use, this could inflict a major blow to Europe’s entire technology ecosystem.
How to make the CRA compatible with OSS
The CRA’s goal is admirable: basic security assurances on the software and devices we interact with daily. And it’s still possible to deliver on this goal while ensuring that OSS projects and communities can continue to innovate.
The source of the problem is that in its current draft, the CRA treats OSS as being interchangeable with commercial alternatives. This doesn’t reflect the reality on the ground -- OSS, free to use, is rarely offered as a complete solution. It is simply a building block or component in a wider offering. The CRA should therefore treat OSS code as a public good, like clean air or radio bands.
Instead of policing OSS projects and communities, the CRA should place responsibility for security on the commercial entities using this code in the products and services they provide to their customers. With this step, the responsibility is placed on commercial entities to ensure they understand the risks and harden the security of the products they release. To this end, organizations should be expected to demonstrate three key capabilities to keep their OSS components secure:
- Runtime vulnerability analysis -- Continuously monitoring to detect any vulnerabilities in a product and its components as soon as they are introduced -- across both custom-built and open source code. Security and development teams need the ability to instantly understand the potential impact of any detected vulnerability and have the insight needed to resolve it quickly, before the integrity of their applications and data has been compromised.
- Application hardening -- Auditing products for exposure to key security threats that target critical vulnerabilities, such as SQL and command injections, using established industry threat lists such as the Open Worldwide Application Security Project (OWASP). Organizations also need the ability to detect when these attacks are being executed and block them before they can do any damage.
- Security automation -- Establishing automated workflows to detect, remediate, and resolve security incidents or vulnerabilities -- in OSS components and beyond. This helps to speed up resolution times and reduce the exposure of products and services to critical vulnerabilities.
How the CRA could turbo-charge European open source
If these standards were included in the CRA, the act could ultimately become a significant boon to OSS development. Rather than discouraging OSS participation, the CRA’s enforcement of responsible OSS use could drive liable organizations to invest in mapping, recognizing, and hardening the OSS components they use in their products.
This increased commercial investment would inevitably trickle into the broader OSS ecosystem, and ultimately mean more overall resources dedicated towards maintaining and updating projects. The benefits of this could be tremendous, dramatically increasing the pace of software innovation across the EU. Best of all, these requirements would guarantee a more secure OSS ecosystem in Europe and beyond. That means better delivery of the CRA’s primary goal: more secure tech products and services for European citizens.
Image credit: Yuryz/Dreamstime.com
Alois Reitbauer is Chief Product Officer & Head of Open Source, Dynatrace.