Much has been written about the potentially damaging effects of the draft EU Cyber Resilience Act (CRA) on the open source ecosystem (BitKom, Eclipse Foundation, VDA, OSBA, Linux Foundation - this post is based on a draft of the CRA from September 15, 2022). In this post, we are going to look at the CRA from a different perspective: As a part of the EU cybersecurity strategy, the higher-order goal of the CRA is the further development and strengthening of the integrated EU single market. Since open source software is the foundation of nearly every modern digital product, influencing how the open source ecosystem operates will be felt by the European businesses and citizens. Will the CRA be conducive to EU ICT policy goals?
The cyber security of digital products is generally in bad shape. The evidence is clear that security vulnerabilities cause real damage to citizens and businesses: Ransomware exploits vulnerabilities to freeze organizations out of using their own systems. Supply chain vulnerabilities inject faulty or hacked components into potentially a multitude of products. Discontinued security and maintenance updates, for example lacking software updates for mobile phones, also cause unnecessary pollution and higher cost for consumers by making these products obsolete earlier than necessary. Generally, consumers have little transparency over the security of their devices. Few come with proper software bills of material (SBOMs). Even the FOSS disclosure required by most open source licenses is spotty at times. The open source community has identified these problems early on and, for example, acted by establishing the Core Infrastructure Initiative, which later evolved into the Open Source Security Foundation (OpenSSF).
With the proposed Cyber Resilience Act, the European Commission takes a regulatory approach to improving cyber security of digital products and enabling consumers to make better informed choices when selecting and using digital products. The CRA is a key element of the EU’s cybersecurity strategy. Making cybersecurity an EU priority has been welcomed by a multitude of stakeholders, including the Linux Foundation and Linux Foundation Europe. How the CRA intends to raise the level of cybersecurity, however, continues to raise major concerns.
The main objectives of the CRA are to reduce vulnerabilities in digital products, to ensure cybersecurity is maintained throughout a product’s life cycle and to enable users to make informed decisions when selecting and operating them. It does that by creating conditions that apply to any networked product placed in the EU market, whether provided by an EU business or one outside (a “horizontal” legislation). Products that do not comply with the CRA will be barred from EU market access.
The CRA distinguishes between non-critical products, like smart home lamps, and critical products. Critical products are split into classes I and II, with class II (routers, firewall or crypto processors, for example) being subjected to the strictest cyber security requirements. Key foundational open source technologies like operating systems for servers, desktops and mobile devices, hypervisors or container runtimes are explicitly included in class II of the critical products (this concern is addressed in amendments proposed by the European Council).
What the CRA does not mention, however, is the difference between developing such technologies upstream in a collaborative fashion and introducing them into the market. This difference is essential to the functioning of today’s ICT sector where digital products build upon reusable, general purpose open source technologies. As an example, the open source collaborative process provides everyone in the world access to highly secure software components that have been battle tested for decades. Not many companies in the world could build a secure TCP/IP or SSL network implementation on their own, but open source collaboration provides anyone with these building blocks from which to create new products and solutions.
Another concern is that the CRA does not limit the foreseeable use of the product (open source software in the CRA context) to the scope intended by the manufacturer. This results in making upstream open source communities responsible for vulnerabilities even in the most unexpected use cases. A distributor of open source software could demand bug fixes from the upstream community for issues that only occur in their specific environment and may not even be reproducible upstream. It will, in fact, not be possible to make software available in the EU "as is" and under a free license, without being responsible for downstream cybersecurity issues. This runs counter to the core essence of the open source development model.
Every consumer product starts as component products that traverse the supply chain in a process of further and further integration. Technically, the process begins with raw materials being dug from the ground and electrical energy provided from a power source like a grid or solar panel. For products with digital elements, the relevant steps begin with the assembly of the lowest level modules from general-purpose software and hardware components. These are the raw materials equivalents of the ICT ecosystem, generic software libraries and basic electrical components. General-purpose components are suitable to potentially many applications, but not yet integrated for any specific foreseeable use. Consumer-ready products in contrast are made for a concrete application, where the manufacturer promises fitness for the purpose that the consumer pays for. The integration process can be traced along the supply chain as the intermediate products get more and more refined until they are consumer-ready for the intended purpose.
Software as such, whether in source code or executable form, does not fully describe a digital product. Going back to Turing, to examine the behavior of a digital product, we need to know the software, the hardware environment and the current configuration of the system. This is particularly important in the context of cyber security: A vulnerability does only materialize when a software flaw is exposed by the configuration of a specific executing system. The concrete system is necessary to reproduce the problem. The bugfix for the vulnerability can only be verified on the concrete system. In practice, the hardware environment is often not available to the upstream software development community. One reason for this is the pervasive use of open source components across an overwhelming number of use cases from trivial devices to satellites. Another reason is the protection of intellectual property: A downstream manufacturer does not need to disclose their hardware designs to be able to use upstream software. This approach is common to graphics chips or mobile device makers.
The decision to use or not use an upstream open source component is made by the product makers along the supply chain. As they design their systems, the manufacturers ensure that their product meets the quality and regulatory requirements, including cyber security, for the foreseeable use by the next customer in the supply chain. The manufacturer of the final product guarantees that the product is safe to use by the consumer and fulfills its purpose. This end-to-end responsibility is supported by contractual agreements of the consumer product manufacturers with their suppliers that manage the guarantees and liabilities for the intermediate products. The consumer can rest assured that the product maker guarantees the system as a whole and is often unaware of the components that make up the system.
Upstream open source communities release general-purpose software under licenses that allow use, modification and redistribution by anybody, for any purpose, but with no warranty of any kind. This puts these communities at a special place in the software supply chain: As the providers of the most generic, reusable components, using the software does not require downstream manufacturers to engage with the upstream communities at all. “Pulling” software from open source projects is a one-sided transaction by downstream users. Upstream communities for the most part do not fully know the users of their software. Sometimes this concept is obscured by businesses both releasing open source software and providing commercial services around it. The litmus test, however, is simple: If a consumer can use, modify and redistribute the software without engaging with the business, these two activities are separate and disjunct. This is true for all accepted open source licenses. The services are a commercial activity, while the upstream contributions become part of the pool of available open source software (the “global open source commons”). Open source contributors can be anywhere in the world and their contributions are integrated upstream.
In the current draft, the CRA ignores these realities. It treats all development and distribution of digital products the same. It does not distinguish between products sold in the EU market and the release of software under an open source license. Instead it defines an exclusion for open source software “developed or supplied outside of the course of commercial activity” as to not hamper innovation or research. Unfortunately, this is completely off the mark: The vast majority of open source software is developed in the course of commercial activity by developers in their day jobs. The same business or developer may work on products or provide commercial services while making contributions to open source. It is the nature of the activity that matters, not the person who performs it. The CRA also does not take the intended use foreseen by the manufacturer into account when defining responsibilities for cyber security. This means that the provider of any software module, open source or not, may become responsible for vulnerabilities when the software is used to control a nuclear power plant, even if the software was made for toys.
This artificial disconnect between making product decisions such as consuming open source to bring a product into the market and their consequences (the cyber security capabilities of these) is unique to the CRA. This is a drastic deviation from otherwise established norms in the EU single market and elsewhere in the world. It will pervert incentives for manufacturers, who will try to offload cyber security to their suppliers and upstream communities. It will also impair the ability of the communities to make software available in the EU while keeping their open source development model alive.
The open source development model has many variations and how open source code flows is not easy for someone on the outside to understand.
There are two inherent assumptions in the CRA model that present issues:
If the CRA goes into effect without these concerns being addressed, it will impose costs to both open source use and contributions that are primarily born by European businesses and communities. Businesses outside of the EU will have to comply with the CRA when their products are introduced into the EU single market. By comparison, all stages of the supply chain of EU-based businesses have to implement EU regulations. This competitive disadvantage will discourage commercial open source contributions from within the EU. The additional obligations will demotivate individual contributors and maintainers. Small communities and single-maintainer projects, the hotbeds for EU based software innovation, may quit Europe altogether. This will starve the creative potential that fuels European startup formation. It will primarily disadvantage small and medium size enterprises (SMEs) that rely on fast-paced open source innovation to disrupt large incumbents who have the financial and administrative capabilities to handle the additional obligations. The CRA draft even acknowledges that by calling for an EU SME support fund. But even a massive support fund cannot counteract the inability of innovators to get started in the EU because of regulated access to open source software the rest of the world is free to rapidly innovate with and compete using. In sum, the Cyber Resilience Act imposes an impediment on open source innovation that will primarily be born by EU SMEs and stunt the EU’s digital product innovation capabilities.
The recent study on the economic impact of open source in Europe highlights that European software innovation is largely driven by SMEs and open source communities. Most “big-tech” software businesses are headquartered outside the EU. One potentially disastrous outcome of the CRA may be that open source communities refuse to make software available in the EU. Open source software would then be available in Europe only through commercial intermediaries. Most of the businesses predestined to assume this role - primarily Linux distributors and makers of device development kits - are not based in the EU. While such behavior (release software under a free license and leave distribution to downstream) is clearly in line with the open source development model it means the EU CRA cost might even be paid to big tech outside the EU.
With this, the CRA risks running counter to how the EU plans to embrace open source to support its strategic goals. The EU open source strategy, for example, states that “open source is independent from companies and countries” and underlines that open source impacts the digital autonomy of Europe. The EU invests heavily into initiatives like Next Generation Internet, Gaia-X or SovereignEdge that develop or depend heavily on open source technologies to gain digital sovereignty and evolve essential internet technologies. It should not undermine digital sovereignty by pulling the rug out from under its own open source community.
The policy goals of the CRA are supported by many stakeholders. The problem with the CRA is not what it aims to achieve, but how. Concerns with the individual obligations imposed by the CRA can be addressed through moderation and refining. For example, the obligation for manufacturers to report actively exploited vulnerabilities (CRA article 11) raises concerns that this information may be abused or disclosure enforced before a fix is ready. Such concerns can be addressed by processes that ensure confidentiality and issue mitigation. The concern that development platform providers may become responsible for vulnerabilities in the software they host for others can be addressed through clarification (and is, in fact, addressed for example in the proposed EU council amendments). While these concerns should be taken seriously, they don’t break the CRA.
Two major issues, however, must be addressed to make the CRA work:
First, the responsibilities and obligations must be aligned with the structure of the supply chain. Every manufacturer must be responsible for the cyber security of the intended use of their product, not less, but also not more. Customers who wish to use a product for a more complex use case will have to find a manufacturer willing to support that contractually, and compensate them for it. The last manufacturer between a consumer and a digital product is the company making decisions about the intended use, the ability to support the product for an appropriate period, and which software should go into the product. They are in the best position to decide whether open source is appropriate for the purpose. They are in the best position to also plan product support and security updates, collaborating with their contractual partners in a supply chain, and reviewing decisions at any point in that supply chain about the appropriate use of open source.
Second, releasing open source software should never result in obligations towards potentially unknown and anonymous users. Instead, the CRA must return to the explicit notion of a commercial entity intentionally placing a product on the market and bearing the corresponding responsibilities. This would remove the need for blurry exceptions for research, governments, defense and “non-commercial” open source development, and instead bind all commercial actors to be compliant with the CRA. In this picture, releasing open source software in an upstream project would not count as making a product available to the EU market, since it comes with no promise of usefulness and there is no supply chain transaction between the developers and the users.
Addressing these two breaking issues with the CRA will bring it more in line with the related EU regulations like the Product Liability Directive. It will also address many of the concerns raised by European industry and open source community stakeholders.
The Linux Foundation Europe will continue to support the EU in improving the CRA and cyber resilience in the EU single market in general. We hope that there still is the opportunity to make this important piece of legislation work. We ask all stakeholders to get engaged in the process and make themselves heard. For policy makers, the important takeaway is that in its current form, the CRA may do more harm than good and make the European ICT businesses less competitive. To stay up to date with recent CRA developments or support Linux Foundation Europe’s engagement, sign up to our Cyber Resilience Act web page.