No cyber resilience without open source sustainability

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.

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.

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).