What I learned in Brussels: the Cyber Resilience Act

Last weekend I co-organised an EU policy devroom at FOSDEM, marking the end of a wild ride in EU policy land working on the Cyber Resilience Act. In this post I want to contribute to a shared understanding of how the CRA will most likely affect developers of open source software.

by Maarten Aertsen

With the results of the negotiations (trilogue) public since December, we now know what to expect at a high level from the Cyber Resilience Act. I’ll link high-quality resources for those that want to understand what the CRA is about. I'll also tell my personal story of starting FOSS policy engagement in Brussels because of the CRA and share the lessons I learned.

Does the CRA affect me?

Benjamin Bögel (European Commission, responsible for the CRA’s implementation) returned to FOSDEM's main stage to give a 10-minute explainer of how CRA affects FOSS. I recommend watching it.

Using a flow-chart to get a rough sense

In his presentation, Benjamin uses a flow chart to help you figure out if the CRA affects you. That’s no substitute for reading the law (when it is formally published, likely in Q2 2024, don’t waste your time just yet), but it may help you to get an intuition.

Using a flow-chart to guide further reading

Seeing his flow-chart reminded me that I had made one myself while trying to wrap my head around the CRA scope, which has a bit more detail with pointers to the relevant recitals and articles:

Other introduction-level resources I recommend include:

• Bert Hubert’s “EU CRA: What does it mean for open source?” article
• Mike Milinkovich in Eclipse's "From Concerns to Solutions: An Update on the Cyber Resilience Act" webinar

I want to learn what's next. Where do I go?

FOSDEM featured an ”EU policy devroom” this year, that I contributed to as co-organiser. The first block was dedicated to the CRA and (sadly less known) updated Product Liability Directive (PLD):

• Mirko Boehm (Linux Foundation Europe) summarized the block in 10 minutes.
• On the next steps in CRA and PLD implementation:
  • A "CRA & PLD panel" with participation from the European Commission to hear about next steps in implementation. The audience raised questions about stewards, financial barriers to standard(isation|s) and many other topics. We learned that the Commission is eager to collect feedback to feed into their work, creating appropriate guidance.
  • Input from a ~70 participant workshop excercise summarized by the EC staff, where the devroom participants gathered Fears, Hopes and Solutions to feed into future implementation and guidance work by the European Commission.
• (for manufacturers under the CRA) the importance that the standards to be developed for the CRA are not aligned against FOSS:
  • Tobie Langel's lightning talk "40 new ways the CRA can accidentally harm open source"
    Bert Hubert previously wrote a section on capture of the European Standards Organisations by dominant industry players
• (for open source software stewards under the CRA) how to do CRA compliance and the challenge on how to do that in the open:
  • Marta Rybczynska's lightning talk: "CRA conformance for Open Source Projects"
• (for an introduction to the Product Liability Directive):
  • Robert Carolina's lightning talk: "When software causes harm – who pays and why?"
  • Omar Enaji's (European Commission) introduction to the PLD during the "The Regulators Are Coming: One Year On" (starting at 25min20s) at FOSDEM's main stage

Some CRA details less frequently discussed

Manufacturers downstream will need to send fixes upstream

In my original article, I wrote about responsibilities for integrators under the CRA. Article 10(4) requires integrators 'to excercise due diligence when integrating components sourced from third parties [..] They shall ensure that such components do not compromise the security of the product [..]'.

There is now a copyleft-inspired added obligation for manufacturers that find a vulnerability in a component they use to send fixes upstream:

Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.

This is nice.

Manufacturers can always use self-certification for FOSS

One of the biggest concerns in my November 2022 blog, was the compliance burden for so-called critical products (since renamed to important products). An exception has been introduced for manufacturers that allows for self-certification for important products, under the condition that the technical documentation is made publicly available.

Quoting a European Commission presentation at FOSDEM2024 (11min54):

When it comes to FOSS, we have a special provision in the CRA that says that irrespective of whether your product is important or not, you will always be allowed to undergo a self-assessment. You will not have to submit any FOSS that is in the scope of the CRA to a third party.
And the reason behind that is that when it comes to open source it is a transparent product and anyone including the users or integrators they can check for themselves if this product is secure. So you do not need a third-party that vouches for the product.

This seems useful. It will empower all users, not just notified bodies or economic actors with sufficient market power to inspect the security of the products they rely on. Perhaps it will incentivize some manufacturers to open up their products.

Learning FOSS policy engagement from scratch

This blog concludes a 17-month journey to understand the EU's attempt to regulate software with the CRA. I engaged in this policy process in an effort to minimise damage to the practice of free and open source software development. I looked back upon this process at FOSDEM, in a lightning talk "FOSS policy engagement: a CRA retrospective" with Enzo Ribagnac (Eclipse). It features my struggle to understand how Brussels works, roughly on a chronological timeline.

I am grateful to everyone who helped me along; it was quite the rollercoaster. Some lessons I learned:

1. We were too late. The proposal was already out when we noticed and had to try to influence its contents after the fact. Like chasing a train that has already departed, you are much better off being at the station ahead of time, so you can get boarded before it departs. Chasing required us to spend much more effort than would have been necessary had we been involved (update: or consulted!) on time.
2. We cannot expect the FOSS community to organise as an industry organises (in trade organisations). If it turns out that FOSS appears nicely organised to a policy maker, then they are probably not talking to the whole community but just to the industry part of it. Simon Phipps wrote about this more eloquently than I can.
3. We need the process for the digital dossiers in the EU to change, or figure out better mechanisms to do advocacy from the FOSS community. For all the EU's digital dossiers software is relevant, and for software FOSS is relevant. In hindsight; we got lucky on this one.
4. We should be talking more to parliament as a community; they are the people most accessible to us. On a more general note, European elections coming; they are important; please go vote if you are eligible.
5. It turns out that even if you don’t have any EU policy experience, you can figure out the landscape and make a difference.