With publishing as Regulation (EU) 2024/2847 in the Official Journal of the European Union, the Cyber Resilience Act (CRA) enters into force (EIF) on December 10, 2024. The CRA will fully apply three years later, on December 11, 2027. The CRA will obligate all products with digital elements, including their remote data processing, put on the European market to follow this regulation. This new blog series will cover the implementation of the CRA and its relevance to open source software.
In Part 1, we will provide a general overview of the CRA and highlight LF Europe and the OpenSSF’s current activities in relation to the implementation. The next blog in the series will go more in depth on the three-year implementation timeline and beyond.
CRA Overview
The CRA intends to address threats and vulnerabilities by establishing standardized frameworks for cybersecurity requirements as part of a wider set of European product legislation. It regulates so-called “products with digital elements”, or PDE for short, and its horizontal nature gives it a big scope, including a wide set of hardware and software, but excluding medical devices, cars and other product types with their own safety and security rules. The primary goal is to reduce the costs for data breaches and increase customer trust in products with a digital element.
As such, the CRA comes with all the current European single market instruments and mechanisms attached, from standardization, conformity assessment and certification to market surveillance and regulatory sandboxes, consumer protection measures and representative actions. And while distributors and importers also have obligations, manufacturers who sell their products on the European market, and headquartered in the EU or not, carry most of them in the CRA, they need to show conformity to the regulation depending on the product class, cooperate with market authorities on their request and follow rules for vulnerability handling.
What makes this regulation remarkable are some of its provisions for open source software.
CRA and Open Source
Does it affect open source projects? How can they prepare and position themselves in the market?
What seems to be often the first question, especially in the open source world, is what it even means to “put a product on the market” in an open source context? The second question is how monetization changes obligations. Bingo! There is no easy answer that covers each and all cases that occur in open source development and consumption. By the time when the CRA fully applies, a lot of these questions will hopefully be answered more precisely, but for now it can be assumed that every digital product, or products running software, fall under this regulation. Â
Like other recent European legislation, it aims at fostering open source software and tries to minimize negative impact on the ecosystem, especially for MEs and SMEs. But what makes it so special is the introduction of a new market actor, the so-called “open source software steward”. Stewards are defined as having the purpose or objective of systematically providing support on a sustained basis for the development of specific open source PDEs intended for commercial use. But stewards can’t apply CE markings, the sign that a product sold in the EU has been assessed to meet high safety, health, and environmental protection requirements, only manufacturers can, and there are many questions unanswered yet.
CE Mark; Image Source: European Commission
Note: The CE mark indicates that a product can be freely traded within the European Economic Area (EEA), regardless of where it is manufactured. “CE” stands for “conformitĂ© europĂ©enne,” which translates to “European conformity” in English.
In most cases the process boils pretty much down to self assessment with some exceptions for certain product types, basically taking all measures necessary so that the design, development, production and vulnerability handling processes comply. If it’s not put on the market (ie. just a project on Github), there’s no need to declare conformity, apply CE marking or anything. However, if a project seeks to be used in products and wants to make life easier for their downstream and consumer/manufacturers, it should provide the info as required by the conformity process, especially in respect to the vulnerability handling processes in place.
OpenSSF’s CRA Activities
In addition to this blog series, the OpenSSF is planning several other initial activities and events as the CRA implementation begins, including:
- A podcast series with experts to provide an EU view on cybersecurity through the lens of the CRA.
- Providing comments for the TR-03183 by the German BSI, which is the first guidance on implementation on EU member state level.
- Participating in the ENISA consultation on guidance for the NIS2 Implementing Act concerning open source supply chain security with community partners.
- Conducting the Open Source Software Stewards and Manufacturers Workshop, an  event that brings together Linux Foundation projects with members and contributors to discuss the work necessary to implement the EU Cyber Resilience Act.
- After completion of the workshop, the OpenSSF and LF Europe will be hosting a series of working groups that will collaborate on the workstreams discussed at the December meeting that will deliver advice, guidance, tooling, and other recommendations to help support our upstream maintainers and projects, our members, regulators, and the whole open source ecosystem.
Join Us and Get Involved
If you’re a member of OpenSSF or LF Europe, join us on December 10 – 11, 2024 at the Open Source Software Stewards and Manufacturers Workshop and request an invitation: Be part of the initiative to advance secure software development with OpenSSF and the Linux Foundation! Contribute your expertise, collaborate with industry leaders, and help shape the future of open source security. Learn more and get involved today.Â
Keep an eye out for Part 2 of this blog series soon, with more details on the implementation timeline and other updates on OpenSSF’s CRA activities.