No cyber resilience without open source sustainability

Have your say to protect open source in the EU

Together with the open source software community, GitHub has been working to support EU policymakers to craft the Cyber Resilience Act (CRA). The CRA seeks to improve the cybersecurity of digital products (including the 96 percent that contain open source) in the EU by imposing strict requirements for vendors supplying products in the single market, backed by fines of up to €15 million or 2.5% of global revenue. This goal is welcome: security is too often an afterthought when shipping a product. But as written it threatens open source without bolstering resilience.

Even though the CRA, as part of a long-standing line of EU ‘open’ strategy, has an exemption for open source software developed or supplied outside the course of a commercial activity, challenges in defining the scope have been the focus of considerable community activity. Three serious problems remain with the Parliament text set for the industry (‘ITRE’) committee vote on July 19. These three problems are set out below. Absent dissent, this may become the final position without further deliberation or a full Parliament plenary vote. We encourage you to share your thoughts with your elected officials today.

Problem 1: The CRA regulates open source projects receiving donations

Open source sustainability is a problem: maintainers of popular software projects are often overwhelmed by issues and pull requests to the point of burnout. Donations have emerged as one solution, and are regularly provided by governments, foundations, companies, and individuals. Yet, as excerpts of recent drafts of the CRA (Recital 10b quoted below) indicate, it could threaten to undermine sustainability by potentially introducing a burdensome compliance regime and potential penalties if a maintainer decides to accept donations. The result will be less resources flowing to already under resourced maintainers.

Problem 2: The CRA regulates open source projects with corporate developers

Open source projects are often multi-stakeholder: they receive contributions from developers building as individuals, volunteering in foundations, and working for companies, large and small. The current text (Recitals 10 and 10a) would regulate open source projects unless they have “a fully decentralised development model.” Any project where a corporate employee has commit rights would need to comply with CRA obligations. This turns the win-wins of open source on its head. Projects may ban maintainers or even contributors from companies, and companies may ban their employees from contributing to open source at all. The result will be a less innovative and less secure software ecosystem.

Problem 3: The CRA breaks coordinated vulnerability disclosure

The CRA seeks to fix a common problem: an upstream open source project issues a security fix, but a product using the open source project doesn’t upgrade quickly. But the current Parliament text (Article 11) risks breaking coordinated vulnerability disclosure by requiring any software developer (‘manufacturer’) to report to ENISA all actively exploited vulnerabilities within a timeline measured in hours after discovering them. In the case of unpatched vulnerabilities, such an approach cuts against well established policies that limit disclosures to only those able to contribute to fixing the security vulnerability. Wide disclosure of unpatched vulnerabilities does not make the open source ecosystem more resilient—it makes it more perilous.

What happens from here

The ITRE Committee in EU Parliament will hold a vote on July 19. Barring objections, this highly technical text may become the final Parliament position. The final CRA will subsequently be negotiated among the Parliament, Council, and Commission. The Council text better reflects how open source software is built and maintained today, and the final negotiations could yield an effective CRA even if the final Parliament version is flawed.

Your action today can make a difference. Particularly if you maintain an open source project, consider how the regulation may impact you and the people who rely on your software. Please contact your MEP to share your expertise and express your opinion of the crucial July 19 vote.

Parliament ITRE Committee draft on open source

Recital (10) Only free and open-source software made available on the market in the course of a commercial activity should be covered by this Regulation. Whether a free and open-source product has been made available as part of a commercial activity should be assessed on a product-by-product basis, looking at both the development model and the supply phase of the free and open-source product with digital elements.

Recital (10a) For example, a fully decentralised development model, where no single commercial entity exercises control over what is accepted into the project’s code base, should be taken as an indication that the product has been developed in a non-commercial setting. On the other hand, where free and open source software is developed by a single organisation or an asymmetric community, where a single organisation is generating revenues from related use in business relationships, this should be considered to be a commercial activity. Similarly, where the main contributors to free and open-source projects are developers employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature.

Recital (10b) With regards to the supply phase, in the context of free and open-source 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, when this does not serve only the recuperation of actual costs, 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. Accepting donations without the intention of making a profit should not count as a commercial activity, unless such donations are made by commercial entities and are recurring in nature.

Recital (10c) Developers contributing individually to free and open-source projects should not be subject to obligations pursuant to this Regulation.

Recital (10d) The sole act of hosting free and open-source software on open repositories does not in itself constitute making available on the market of a product with digital elements. As such, most package managers, code hosting and collaboration platforms should not be considered as distributors under the meaning of this Regulation.

Recital (10e) In order to ensure the products are designed, developed and produced in line with essential requirements foreseen in Section 1 of Annex I, manufacturers should exercise due diligence when integrating components sourced from third parties, including in the case of free and open-source software that has not been made available on the market. The appropriate level of due diligence depends on the nature and the level of risk of the component and may include one or more of the following actions: checking if the component already carries the CE mark, checking security up-dates history, verifying if it is free from vulnerabilities registered in the European vulnerability database or other public databases, or carrying out additional security tests.

Where, in the exercise of due diligence, the manufacturer of the product identifies a vulnerability in a component, including in a free and open-source component, it should inform the developer of the component, address and remedy the vulnerability, and where applicable, provide the developer with the applied security fix. Once the manufacturer has placed the product on the market, it should be responsible for ensuring that vulnerabilities are handled throughout the support period, including for the free and open-source components integrated into the product with digital elements.

Article 2(3a) This Regulation applies to free and open-source software only when made available on the market in the course of a commercial activity.

Parliament ITRE Committee draft on vulnerability disclosure

Article 3(39) ‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner;

Article 11(1) The manufacturer shall notify to ENISA any actively exploited vulnerability in the product with digital elements in accordance with paragraph 1a of this Article. ENISA shall, without undue delay, unless for justified cybersecurity risk-related grounds, forward the notification to the CSIRT designated for the purposes of coordinated vulnerability disclosure in accordance with Article 12 of Directive (EU) 2022/2555 of Member States concerned upon receipt and inform the market surveillance authority about the notified vulnerability. Where a notified vulnerability has no corrective or mitigating measures available, ENISA shall ensure that information about the notified vulnerability is shared in line with strict security protocols and on a need-to-know-basis.

Article 11(1a) Notifications as referred to in paragraph 1 shall be subject to the following procedure:
(a) an early warning, without undue delay and in any event within 24 hours of the manufacturer becoming aware of the existence of an actively exploited vulnerability, including whether any known corrective or recommended risk mitigating measure is available;

(b) a vulnerability notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability, which, where applicable, updates the general information referred to in point (a), including any corrective or mitigating measures taken and indicates an assessment of extent of the vulnerability, including its severity and impact;

(c) a final report, within one month after the submission of the vulnerability notification under point (b) or when a corrective or mitigating measure is available, including at least the following:

(i) a description of the vulnerability, including its severity and impact;

(ii) where available, information concerning any actor that has exploited or that is exploiting the vulnerability;

(iii) details about the security update or other corrective measures that have been made available to remedy the vulnerability.

Article 11(1b) After a security update is made available or another form of corrective or mitigating measures is put in place, ENISA shall add the notified vulnerability pursuant to paragraph 1 to the European vulnerability database referred to in Article 12 of Directive (EU) 2022/2555.

Article 11(2)(2e) Manufacturers that qualify as micro, small or medium sized enterprises shall be exempted from paragraphs 1a(a) and 2b(a).

Written by

Mike Linksvayer

@mlinksva

Head of Developer Policy