No cyber resilience without open source sustainability

Give your opinion on protecting open source in the EU

GitHub works with the open source software community to working to support EU policy makers develop Cyber ​​Resilience Act (CRA). The CRA seeks to improve the cybersecurity of digital products (including 96% open source) within the EU by imposing stringent requirements on vendors supplying products in the single market. This carries a fine of up to 15 million euros or 2.5% of his worldwide. Earnings. This goal is welcome. Security is often an afterthought when shipping products. But as written, it threatens open source without enhancing its resilience.

As part of the EU’s long-standing ‘open’ strategy, the CRA exempts open source software developed or provided outside the course of commercial activity, but there are challenges in defining the scope. is becoming focus Pretty community activities. He has three major issues remaining in the parliamentary document set for vote by the industry (“ITRE”) committee on July 19. These three issues are discussed below. In the absence of objections, this may become the final opinion without further deliberation or full vote in the plenary session.Highly recommended Share your thoughts with your elected representatives today.

Issue 1: CRA regulates open source projects that receive donations

Open source sustainability is a problem. Maintainers of popular software projects often become overwhelmed with issues and pull requests and become burned out. Donations have emerged as one of the solutions and are offered regularly. government, foundation, both companies and individuals. However, as a recent draft excerpt of the CRA (Recital 10b quoted below) shows that if a maintainer chooses to accept donations, it can undermine sustainability by potentially introducing onerous compliance regimes and potential penalties. As a result, less resources flow to maintainers who have already reserved resources.

Issue 2: CRA regulates open source projects with corporate developers

Open source projects are often multi-stakeholder. Donations come from developers working as individuals, volunteering for foundations, and working for companies large and small. the current text (Recital 10 and 10a) will regulate open source projects unless they have a “fully decentralized development model”. Projects in which company employees have the right to commit must comply with the CRA’s obligations. This reverses the interests of both sides of open source. Projects may ban maintainers and contributors from companies, and companies may prohibit employees from contributing to open source at all. The result is a less innovative and less secure software ecosystem.

Issue 3: CRA defeats coordinated vulnerability disclosure

CRA aims to solve a common problem where an upstream open source project publishes security fixes, but products using that open source project are not upgraded immediately. However, current parliamentary documents (Article 11) promotes coordinated vulnerability disclosure by requiring software developers (“manufacturers”) to report all actively exploited vulnerabilities to ENISA within hours of discovery. Risk of breaking. In the case of unpatched vulnerabilities, such an approach would go against established policies that limit disclosure to only those that can contribute to remediation of security vulnerabilities. Widespread disclosure of unpatched vulnerabilities doesn’t make the open source ecosystem more resilient, it just makes it more dangerous.

what happens from here

The ITRE Committee of the EU Parliament will hold a vote on 19 July. Absent any objections, this highly technical text could be Congress’s final opinion. The final her CRA will then be negotiated between Congress, Council and Commissions. The Council’s document better reflects how open source software is built and maintained today, and even if the Council’s final version was flawed, the final negotiations would have resulted in an effective CRA. may be obtained.

Your actions today can make a difference. Especially if you maintain an open source project, consider how its regulations affect you and the people who rely on that software.please Contact MEP Share your expertise and voice your opinion on the all-important July 19th poll.

Congressional ITRE Committee Draft on Open Source

Commentary (10) Only free and open source software made available on the market in the course of commercial activity is subject to this rule. Whether free and open source products are being made available as part of commercial activity should be evaluated on a product-by-product basis, looking at both the development model and supply stage of free and open source products using digital technology. . element.

Commentary (10a) For example, a fully decentralized development model in which no single commercial entity controls what is accepted into a project’s code base indicates that the product was developed in a non-commercial environment. should be regarded as a thing. On the other hand, if free and open source software is developed by a single organization or asymmetric community and the single organization derives revenue from related use in a business relationship, this should be considered a commercial activity. Similarly, if the primary contributors to a free open source project are developers employed by commercial entities, and such developers or employers have control over what changes are accepted in the code base, then the project are generally commercial in nature.

Commentary (10b) With respect to the supply phase, in the context of free and open source software, commercial activity may be characterized not only by charging a price for a product, but also by charging a price for technical support services. This means that the manufacturer uses personal data for reasons other than by providing a software platform for monetizing other services, or for the sole purpose of improving the security, compatibility, or interoperability of the software. is not intended solely to recover actual costs. Accepting donations for non-commercial purposes should not be considered a commercial activity unless such donations are made by a commercial entity and are repetitive in nature.

Explanation (10c) Developers who personally contribute to free, open source projects should not have any obligations under this rule.

Announcement (10d) The sole act of hosting free and open source software on an open repository does not constitute making a product with digital elements available on the market. Therefore, most package managers, code hosting, and collaboration platforms should not be considered distributors within the meaning of this rule.

Description (10e) In order to ensure that the Products are designed, developed and manufactured in accordance with the essential requirements foreseen in Section 1 of Annex I, the Manufacturer shall obtain from third parties, including in the case of free and open Due diligence should be carried out when integrating supplied components. – Source Software not made commercially available. The appropriate level of due diligence depends on the nature of the component and the level of risk, and may be one or more of checking if the component is already CE marked, checking security update history, checking if it is CE marked. may include the actions of Have no vulnerabilities registered in the European Vulnerability Database or other public databases, or have undergone additional security testing.

In the course of conducting due diligence, if a product manufacturer identifies vulnerabilities in any of its components, including free and open source components, it must notify the developer of the component to address and remediate the vulnerability, if applicable. provides developers with applied security fixes. Once a product is on the market, manufacturers must take responsibility for ensuring that vulnerabilities are addressed throughout the life of support, including free and open source components integrated into products with digital elements.

Section 2(3a) This Regulation applies to free and open source software only if it has been made available on the market in the course of commercial activity.

Congressional ITRE Committee Draft on Vulnerability Disclosure

Section 3(39) “Actively Exploited Vulnerability” means a vulnerability for which there is credible evidence of malicious code being executed by an attacker on a system without the authorization of the system owner. I mean

Article 11(1) Manufacturers shall notify ENISA of actively exploited vulnerabilities in their products with digital elements in accordance with paragraph 1a of this Article. Unless there are legitimate cybersecurity risk-related reasons, ENISA will, upon receipt of notification, contact the CSIRT designated for the purpose of coordinating vulnerability disclosures in accordance with Article 12 of Directive (EU) 2022/2555 of the Member State concerned. Forward notices and notify market surveillance authorities of notified vulnerabilities. If a fix or mitigation is not available for the notified vulnerability, ENISA shall ensure that information about the notified vulnerability is shared on a knowledge-based basis in accordance with strict security protocols.

The notice referred to in Section 11(1a)(1) shall be subject to the following procedures:
(a) in any event within 24 hours without undue delay after the manufacturer becomes aware of the existence of an actively exploited vulnerability, including whether a known fix or recommended mitigation is available; early warning.

(b) Vulnerability notification without undue delay and in any event within 72 hours after the manufacturer becomes aware of the actively exploited vulnerability; Update the general information referred to in point (a), including corrections or mitigations, if applicable. Indicates the actions taken and an assessment of the extent of the vulnerability, including its severity and impact.

(c) A final report within one (1) month after submission of the vulnerability notification under (b), or if a fix or mitigation is available, including at least the following:

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

(ii) information about the attacker who exploited or is exploiting the vulnerability, if available;

(iii) details regarding security updates or other remedial actions provided to correct vulnerabilities;

Article 11(1b) After the availability of a security update or the introduction of another form of remediation or mitigation, ENISA shall declare vulnerabilities notified pursuant to paragraph 1 to Article 12 of the Directive (EU). shall be added to the European Vulnerability Database as described in Article 3. 2022/2555.

Section 11(2)(2e) Manufacturers that qualify as micro, small and medium enterprises shall be exempt from Sections 1a(a) and 2b(a).

https://github.blog/2023-07-12-no-cyber-resilience-without-open-source-sustainability/ No cyber resilience without open source sustainability

Show More
Back to top button