Cyber Resilience Act: A Threat for Open Source and Europe's competitiveness

The proposal for a European Regulation on cybersecurity requirements for products with digital elements, known as Cyber Resilience Act, introduces new requirements, obligations and penalties for software manufacturers, including open source developers: the goal is to improve cybersecurity in Europe. In this article, we analyze some aspects of the Cyber Resilience Act which would make it, as pointed out by many open source stakeholders like the Python Software Foundation, both ineffective and a threat for the open source ecosystem in Europe.

Cyber Resilience Act: the legislation

The proposed Cyber Resilience Act aims at improving the cybersecurity of products with digital elements: safer products will reduce the exposure of Europe to cyberattacks and the enormous costs they cause each year. We are going to see how the proposal approaches cybersecurity by analysing the draft of the Cyber Resilience Act currently available.

The Cyber Resilience Act

• APPLIES to products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.
• DOES NOT APPLY to products already regulated by the following Regulations:
  • 2017/745 : medical devices;
  • 2017/746 : in vitro diagnostic medical devices for human use and accessories for such devices;
  • 1139/2018 : civil aviation safety
  • 2019/2144 : requirements for motor vehicles.

Conformity assessment

The Cyber Resilience Act contains some essential cybersecurity requirements (Annex 1) and mandates an assessment on the conformity of products with digital elements to those requirements. The conformity assessment follows different procedures depending on the type of product, or rather the category of product.

Critical products

The Annex III defines some products as critical considering the impact of potential cybersecurity vulnerabilities, and classify them in 2 categories (I and II), depending on their cybersecurity risk level, higher for category II. The conformity assessment changes depending on the category the product belongs to: for the critical products of category I, the assessment can be carried our directly by the manufacturer; for category II the procedure involves a third party.

Highly critical products

The European Commission may further specify categories of highly critical products, which will require a cybersecurity certificate issued under a European cybersecurity certification scheme adopted as per Regulation (EU) 2019/881.

The definition of a category of products with digital elements as highly critical depends on the related cybersecurity risk level, considering the criteria set out for the critical products listed in Annex III, as well as whether the products in question are:

• used or relied upon by the essential entities of the type referred to in Annex [Annex I] to the Directive [Directive XXX/ XXXX (NIS2)] or will have potential future significance for the activities of these entities; or
• relevant for the resilience of the overall supply chain of products with digital elements against disruptive events.

Obligations of economic operators

The Cyber Resilience Act provides obligations for economic operators, as manufacturers, authorised representatives, importers, distributors. We will see in a while if it is possible to better define these subjects.

Conformity to the essential cybersecurity requirements

The Cyber Resilience Acts mandates that all products with digital elements shall be released on the market only if they meet the essential cybersecurity requirements set out in Annex 1; the manufacturer shall prove that the products meets those requirements by producing the previously mentioned conformity assessment.

Moreover:

The essential requirements and obligations would mandate manufacturers to factor in cybersecurity in the design and development and production of the products with digital elements, exercise due diligence on security aspects when designing and developing their products, be transparent on cybersecurity aspects that need to be made known to customers, ensure security support (updates) in a proportionate way, and comply with vulnerability handling requirements.

Unfinished software

The recital 21 and article 4 provide that "unfinished software" shall be released on the market only for a limited period of time and only for testing purposes, after a risk assessment and making sure that the code complies to the extent possible with the security requirements relating to the properties of products with digital elements.

Vulnerability handling process

According to article 10 the manufacturers shall ensure that, after placing a product on the market, vulnerabilities are handled in conformity with the requirements set out in Annex I, section II. This, for 5 years or for the entire lifetime of the product, whichever is shorter. However, a recent proposal seems to have amended the draft and removed the 5 years limit; therefore, the manufacturer may be responsible for the vulnerability handling process for a longer period of time.

Sanctions

The sanctions are quite hefty:

The non-compliance with the essential cybersecurity requirements laid down in Annex I and the obligations set out in Articles 10 and 11 shall be subject to administrative fines of up to 15 000 000 EUR or, if the offender is an undertaking, up to 2.5 % of the its total worldwide annual turnover for the preceding financial year, whichever is higher.

Article 53

Who is the economic operator?

The definition of economic operator is given by the article 3, point 17.

‘economic operator’ means the manufacturer, the authorised representative, the importer, the distributor, or any other natural or legal person who is subject to obligations laid down by this Regulation;

Article 3 - Point 17

The definition is quite vague: it doesn't help trying to define who is the economic operator subject to the Regulation by making reference to...anyone who is subject to the Regulation.

Given the broad definition of economic operator, the Regulation applies to anyone who writes and distributes software, as confirmed by the definition of manufacturer:

‘manufacturer’ means any natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under his or her name or trademark, whether for payment or free of charge;

Articolo 3 - point 18

The broad definition of manufacturer is made even broader by the extension of the obligations of the manufacturer to anyone who carries out a substantial modification of the software, for example contributing with his or her own code to a software under development.

Article 16
Other cases in which obligations of manufacturers apply

A natural or legal person, other than the manufacturer, the importer or the distributor, that carries out a substantial modification of the product with digital elements shall be considered a manufacturer for the purposes of this Regulation.

Article 16

Here again, it's not clear when a modification is substantial enough to make its author subject to the Regulation, its obligations and its penalties: this uncertainty is definitely not going to motivate open source developers to join a project.

‘authorised representative’ means any natural or legal person established within the Union who has received a written mandate from a manufacturer to act on his or her behalf in relation to specified tasks;

Article 3 - point 19

‘importer’ means any natural or legal person established in the Union who places on the market a product with digital elements that bears the name or trademark of a natural or legal person established outside the Union;

Article 3 - point 20

‘distributor’ means any natural or legal person in the supply chain, other than the manufacturer or the importer, that makes a product with digital elements available on the Union market without affecting its properties;

Article 3 - point 21

Why the Cyber Resilience Act is a threat for open source

We are now going to see why the legislation proposed by the Cyber Resilience Act is a threat for open source software in Europe and why it may also turn out to be quite ineffective in boosting cybersecurity.

A deterrent for open source developers

So far we have seen that, given the broad definition of "manufacturer", an open source developer who contributes with his or her own code to a software project would be very likely to having to comply with the provisions of the Cyber Resilience Act, even when making no money from his or her contribution.

We have also seen how software manufacturers, and therefore open source developers, would have to meet a variety of requirements, some of which may involve a third party and a certification procedure, according to a scheme that changes depending on the category the product with digital elements falls into.

Considering that an open source project typically receives the contribution of many independent developers, who in many cases participate for free: who would ever want to keep doing that whilst being exposed to a variety of cumbersome requirements and the looming threat of harsh penalties?

Let's make an example.

Among the critical products of category II, listed in Annex III, there are Operating systems for servers, desktops, and mobile devices. Now, among the most successful open source products there is Linux, the famous operating system powering desktops, mostly servers and mobile devices. Linux has been open to the contribute of developers around the world since the beginning, and thanks to the participation of so many people it has become, after years of constant development, such a success and a testament to what open source can do.

According to the Cyber Resilient Act, every Linux developer should produce a conformity assessment, and a third party should be involved, given the inclusion of operating systems among the critical products of category II.

In some cases, there would be still uncertainty on whether or not a developer is subject to the Cyber Resilience Act, as this may depend on whether the code submitted is a substantial modification of the product with digital elements: this would make the contributor a manufacturer according to Article 16 and therefore will have to comply with the regulation. This uncertainty alone would be enough to coinvince many developers not to get involved in open source projects.

Software distribution platforms

Platforms like Github are powerful tools for open source development: they publish and host software, which then gets shared among coders, enabling them to work together and share the development process.

According to the Cyber Resilience Act, these platfoms are distributors, subject to Article 14:

Before making a product with digital elements available on the market, distributors shall verify that:

• the product with digital elements bears the CE marking;
• the manufacturer and the importer have complied with the obligations set out respectively in Articles 10(10), 10(11) and 13(4).

Article 14 - Cyber Resilience Act

Therefore, software distribution platforms would be responsible for the code they host, having to check whether their users are bound by the Regulation, and if they are, make sure that they meet all the requirements. That's hard to imagine how such platforms could even comply with all of this, given the service they provide and the way they function. That wouldn't be a surprise to see these platforms leaving Europe and denying access to users from Europe rather than complying.

Incompatibility with open source licenses

The responsibilities provided by the Cyber Resilience Act for software developers are incompatible with open source licenses: these are designed to motivate people to participate, rather than scare them off. According to the Gpl license, version 3 (GplV3), the code is provided "as is, without warranty of any kind".

The responsibility for the quality of a product with digital elements may lie on who re-utilizes a software, making a profit from it, rather than on who donates it: that would be not only unfair, but it would also deter anyone from contributing to an open source project, especially for free.

Isn't there an exception for open source developers?

The recital 10 "tries" to introduce an exception for open source, which on one hand it's not enough, on the other should be clarified in an article, instead of being confined to a recital.

In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation. This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable.

Recital 10 - Cyber Resilience Act

The reason why that is not enough can be found in the definition given of commercial activity:

In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services, by providing a software platform through which the manufacturer monetises other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.

Recital 10 - Cyber Resilience Act

The commercial activity defined by the recital 10 is precisely the business model of many companies developing open source products: the software is provided for free and the company makes profits by selling other services, like technical assistance, courses, or even merchandising.

The Python Software Foundation on the Cyber Resilience Act

Therefore, the proposed exception for open source is ineffective, as pointed out by the Python Software Foundation: The EU's proposed CRA law may have unintended consequences for the Python Ecosystem

"Under the current language, the PSF could potentially be financially liable for any product that includes Python code, while never having received any monetary gain from any of these products. The risk of huge potential costs would make it impossible in practice for us to continue to provide Python and PyPI to the European public."

In short: if these are the conditions, we will no longer provide access to our repositories with Python code to users in Europe.

No more beta versions?

As we have seen, Cyber Resilience Act restricts the distribution of unfinished software, which amounts to limiting the possibility of releasing software for testing purposes. This too, like other provisions of the Regulation, gets in the way of the process by which software is developed, improved and made safer from a cybersecurity point of view: by having a software tested by as many users as possible and gathering their feedback, developers learn about bugs and vulnerabilities and then fix them.

The user is made aware that the software is released for testing purposes, which is the case for alpha or beta versions, and this normally is enough for people not to use it in production, meaning in working environments where it's crucial to deploy reliable and mature software.

Furthermore, by talking about "unfinished software" the Regulation appears unfit starting from the wording: when can it be said that a software is complete? Normally, the development is constant throughout the product lifetime, with updates fixing bugs or adding new features. The idea of something complete and therefore safe to release doesn't fit the software industry, as bugs and vulnerability are always possible and maintenance is crucial.

Conclusions

In conclusion, we now sum up the reasons why the Cyber Resilience Act is a danger for open source in Europe, for Europe's competitiveness and why it may fall short of its cybersecurity goals.

1 - Eccessive compliance costs: the compliance effort would be manageable only by big corporations, and too heavy for anyone else. The risk is to make it impossible for independent developers to work together on a project, which is what normally happens with many open source products, some of which are quite successful and crucial for cybersecurity.

2 - Loss of competitiveness: Europe's ability to produce open source software would be limited, resulting in a big advantage for non european competitors, particularly big companies: they would have no problems meeting the requirements and then offer on the European market the software that is no longer possible to produce in Europe.

3 - Less cybersecurity: to make life harder for developers would mean to end up with less cybersecurity. As we said, open source is crucial for cybersecurity, and so the work of those who contribute, for example fixing a vulnerability, maintaining a software and keeping it safe to use. Many do that for free and would deserve recognition and resources for keeping up the crucial work they do: the Cyber Resilience Act seems to be going in the opposite direction.

---

About the author

Vincenzo Lalli

Founder of Avvocloud.net

Avvocloud is an Italian network of lawyers passionate about law, innovation and technology.
Feel free to reach out for any info: send a message.

Thanks for reading!

---