TDF position on EU’s proposed Cyber Resilience Act

THE DOCUMENT FOUNDATION
Summary of Issues of the Cyber Resilience Act (in the current status)

Introduction

The Cyber Resilience Act (CRA) sets out a number of cybersecurity and vulnerability management requirements for manufacturers (Annex I) and will require products to be accompanied by information and instructions for users (Annex II). Software vendors will also be required to conduct a risk assessment and produce technical documentation (Annex V) to demonstrate compliance.
Currently, the text implies that if a developer or supplier derives commercial benefit from OSS, it would be subject to the Cyber Resilience Act. It even implies, in relation to the distribution of software, that open source producers or developers could be held liable if their open source projects are used commercially.

If the Cyber Resilience Act becomes EU law without clarification, the impact on several European-based open source projects, such as products based on LibreOffice technology, could have devastating (unintended) consequences.

The Commission recognises that not all products in our society are equally dependent. The Cyber Resilience Act therefore distinguishes between products and critical products, reflecting the level of cybersecurity risk associated with these products. On the other hand, the CRA ignores the security risks associated with files created by the software covered by the act itself, which can have even more devastating consequences (according to security expert Kaspersky Labs, in 2018, 70% of all malware worldwide was carried by documents created by the most widely used office suite).

Software developers must declare compliance with the requirements of the Cyber Resilience Act and therefore take responsibility for compliance in one of three ways. They can either:

1. perform a self-assessment, or
2. apply for a product examination by an auditor and then set up checks and balances for their development processes, or
3. apply for an assessment of their quality system by an auditor.

These options come with a growing administrative/compliance burden.

The Cyber Resilience Act attempts to exempt open source software from its provisions. But there’s some problematic language about how the CRA draws the line between commercial and non-commercial use of OSS, which could affect all products based on LibreOffice technology and many other products based on open source software.

This is the text of the Open Source Software exception:

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.

While the Cyber Resilience Act does not define commercial activity, the EU Blue Guide to the implementation of EU product legislation does:

Commercial activity is understood as providing goods in a business related context. Non-profit organisations may be considered as carrying out commercial activities if they operate in such a context. This can only be appreciated on a case by case basis taking into account the regularity of the supplies, the characteristics of the product, the intentions of the supplier, etc. In principle, occasional supplies by charities or hobbyists should not be considered as taking place in a business related context.

For the purposes of the Cyber Resilience Act, there is a real risk that software based on LibreOffice technology will be considered to be made in the course of a commercial activity, and thus subject to the legislation, based on the following:

1. Products based on LibreOffice technology are developed by the majority of full-time employees of ecosystem companies or by individuals who make a living from consulting services related to their project work.
2. Products based on LibreOffice Technology are goods in a business-related context because they are intended to provide software that can be used immediately by businesses or employees in their daily work.
3. The Document Foundation has never missed a LibreOffice release in 12 years.
4. Products based on LibreOffice technology are high quality software that matches the quality of commercial products.

So the features of a product based on LibreOffice technology are equivalent to those of commercial products.

Charging for support also makes open source a commercial activity. The Document Foundation does not charge for support, but it certifies professionals who are supposed to charge companies for consulting and support, and encourages companies to adopt professionally supported software.

Having said all this, it is important to remind the reader that The Document Foundation provides software free of charge, on a non-profit basis, and under OSI-approved open source licences that permit further use, study, modification and redistribution, whereas ecosystem companies provide commercial software with service level agreements.

Impact Assessment

CE Markings for Software Products

Basically, the core of the proposed legislation is to extend the CE marking regime to all software products distributed in Europe. Our understanding is that this process will be applied to open source software that is made available under open source licences and distributed free of charge.

We are deeply concerned that the Cyber Resilience Act could fundamentally alter the social contract that underpins the entire open source ecosystem: open source software that is provided free of charge, that can be modified and redistributed free of charge, but without warranty or liability to the authors, contributors, or open source distributors.

Legally changing this arrangement through legislation is likely to have unintended consequences for Europe’s innovation economy.

Without a clearer exemption for open source, in order to comply with the legislation, The Document Foundation will need to develop, document and implement policies and procedures for each project to ensure that they comply with the requirements of the Cyber Resilience Act, including:

• All development and post-release security requirements specified in Annex I, including the provision of notification and update mechanisms.
• All the requirements for user documentation set out in Annex II.
• All of the product technical documentation set forth in Annex V, including … complete information on the design and development of the product… including, where applicable, drawings and schemes and/or a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing
• For each release, prepare the documentation required by Annex V, including … an assessment of the cybersecurity risks against which the product with digital elements is designed, developed, produced, delivered and maintained…
• Determine for each product whether it meets the definition of product with digital elements, critical product with digital elements or highly critical product with digital elements
• For each product which is a product with digital elements, establish, complete and document a CE mark self assessment process
• For each critical product with digital elements or highly critical product with digital elements engage with an external CE auditing body and complete the additional processes required to get the CE mark approval
• For each individual release, document that the CE marking process has been followed (as described above), that an EU Declaration of Conformity has been written and signed by an officer of the Foundation, that the CE mark has been affixed, and that the technical documentation and EU Declaration of Conformity will be made available for at least 10 years after the release.

Note that we estimate that The Document Foundation’s projects release at least a dozen versions in any given year. It is not clear to us what the cost in time, resources and money would be to implement these external review processes. We assume that they would be substantial.

Article 4 (3)

Member States shall not prevent the making available of unfinished software which does not comply with this Regulation provided that the software is only made available for a limited period required for testing purposes and that a visible sign clearly indicates that it does not comply with this Regulation and will not be available on the market for purposes other than testing.

Projects based on LibreOffice technology make integration, nightly, weekly and milestone builds available under their open source licences indefinitely. The intent is to provide community testing and traceability. These binaries are marked as such, but the terms under which they are provided do not require that they be used for testing purposes only.

It is not clear how this requirement could be implemented by any open source project using modern CI/CD infrastructure and operating under the principle of transparency.

Even if the binaries are marked as for testing only, the open source licences under which they are provided permit uses other than testing. In addition, it is common practice to provide interim builds for extended periods of time to allow testers access to previous builds for problem identification and resolution.

Discontinuing this practice would be very disruptive. And any solution based on making intermediate builds available under non-open source licences would be impossible for projects based on the LibreOffice technology, as TDF does not own the copyright and obtaining the consent of all contributors would be impractical.

In summary, compliance with the proposed requirements of the Cyber Resilience Act would be a significant blow to open source development best practices.

Article 5 (1) and Section 1 of Annex I

(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks

This would probably ask for the development and enforcement of written policies that require each project to assess its level of cybersecurity risk and to implement processes to ensure that the level of risk and justification for the development processes adopted are determined.

(k) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates and the notification of available updates to users

With few exceptions, products based on LibreOffice technology do not require registration and do not provide a mechanism for notifying all users that an update is either available or required. Implementing these requirements would require a whole new infrastructure to be mandated across all projects.

Article 5 (2)

In general, The Document Foundation can deal with many of the requirements, as it has a security team and TDF is also a CVE numbering authority. However, there are two notable elements in the requirements.

(1) identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product

This would impose a legal requirement to produce SBOMs for all projects based on the LibreOffice technology, which would be a very significant effort, and would also require active monitoring of all dependencies for known vulnerabilities.

(3) apply effective and regular tests and reviews of the security of the product with digital elements

These would require a significant change to our community’s development processes to mandate a whole class of testing that is not currently mandated for our projects. This is a very significant effort, both to implement and to maintain.

Section 2 of Annex I “Vulnerability Handling Requirements”

(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks
(2) Products with digital elements shall be delivered without any known exploitable vulnerabilities
(3) On the basis of the risk assessment referred to in Article 10 (2) and where applicable, products with digital elements shall:
(a) be delivered with a secure by default configuration, including the possibility to reset the product to its original state
(b) ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems
(c) protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms
(d) protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against manipulation or modification not authorised by the user, as well as report on corruptions
(e) process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended use of the product (minimisation of data)
(f) protect the availability of essential functions, including the resilience against and mitigation of denial of service attacks
(g) minimise their own negative impact on the availability of services provided by other devices or networks
(h) be designed, developed and produced to limit attack surfaces, including external interfaces
(i) be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques
(j) provide security related information by recording and/or monitoring relevant internal activity, including the access to or modification of data, services or functions
These would require a significant change to our community’s release processes to require certifications that there are no known vulnerabilities and to meet the many requirements listed.
(k) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates and the notification of available updates to users

Several products based on LibreOffice technology do not require any kind of user registration and do not provide a mechanism for notifying all users that an update is either available or required. Implementing these requirements would require a whole new infrastructure to be mandated.

Recommendation and Conclusion

We propose that all open source development and distribution activities should be excluded from the scope of the Cyber Resilience Act, without exception. This is the simplest solution to the problems previously described in the document.

In order to encourage open source developers and distributors to continue their activities, we believe it is important that the Regulation provides comfort and certainty to these organisations that their activities are exempt from the obligations of the Regulation. Although it is the aim of Recital 10 to clearly establish this exemption, we believe that including the FOSS exemption in the body of the Regulation itself would establish the exemption with greater clarity and certainty.

As an alternative, we suggest clarifying the interpretation of “commercial activity” in a way that is more appropriate to the context of open source software. This would recognise that not all efforts to generate recurring revenue (such as paid “technical support services”) should be characterised as “commercial activity”.

Even without the commercial activity qualifier, the wording of Recital 10 would still require companies that primarily monetise open source software, for example by charging for products incorporating such software, to comply with the Regulation, but would no longer cover organisations that make FOSS available to the developer community.