Re: 2025-08-06 - coreboot Leadership Meetings Minutes

Hi,

a few remarks about the CRA part of the meeting notes:

Am 07.08.25 um 18:53 schrieb mina--- via coreboot:
> # 2025-08-06 - coreboot Leadership Meetings Minutes
> [...]
> ## coreboot Leadership Meeting - Late GMT
>
> ## Attendees
>
> Martin Roth, Mina Asante, Jay Talbott, Carl Turner, Michal Kopec, Alicja Michalska, Ziang Wang, Karthik R, Julius Werner.
>
>
> ## Minutes
>
> [...]
> ### [Martin] Discuss the EU-CRA
>    * Summary of the EU-CRA
>    * (https://en.wikipedia.org/wiki/Cyber_Resilience_Act)
>    *(https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/14449-Technical-description-of-important-and-criticalproducts-with-digital-elements_en)
>    * (https://www.linuxfoundation.org/research/cra-readiness?hsLang=en)
>
> ```
> The European Union's Cyber Resilience Act (EU-CRA) is a comprehensive regulation aimed at improving
> the cybersecurity of "products with digital elements" -meaning both hardware and software -sold
> within the EU. The CRA mandates that these products meet strict cybersecurity requirements
> throughout their lifecycle, such as secure-by-default settings, incident reporting, vulnerability
> management, and regular security updates. Products covered by the CRA range from everyday consumer
> electronics to large-scale enterprise systems, though some categories like medical devices and cars
> are governed separately.
>
> Key Provisions & Timeline
> The CRA officially entered into force on December 10, 2024.
> Most obligations will become mandatory on September 11, 2026, with full application commencing on
> December 11, 2027.
>
> Impact on Open Source Projects
> The initial drafts of the CRA raised substantial concern in the open source community, as its
> requirements could have placed undue liability and compliance burdens on individual contributors
> and small non-commercial projects. However, after extensive advocacy and negotiations, the final
> text provides important clarifications and exemptions:
> Non-commercial Open Source Exemption: If you maintain or contribute to open source software purely
> in a non-commercial capacity (i.e., you do not sell or distribute it commercially), the CRA does
> not apply to you. The regulation is designed to target commercial actors and companies that deploy
> open source in products for profit.
> Commercial Open Source: If an entity distributes open source software as part of a commercial
> activity—including selling, offering paid support, or bundling in commercial hardware/software—they
> must comply with the CRA as "manufacturers" or "distributors." This means they bear the primary
> responsibility for security obligations.
> Open Source Stewards: The final legislation introduces the "open source steward" concept,
> recognizing organizations like the Linux Foundation or Eclipse Foundation. These entities play a
> coordination or support role in fostering security practices in open source projects but are not
> automatically liable unless involved in commercial distribution
> ```
> * Werner and I had a meeting with the FSFE to discuss the EU-CRA.
>
> ```
> No obligations for the project itself, only the manufacturer (user of the project) is responsible.
>
> Clear for coreboot as such: It is used to enable/build commercial products. The only responsible
> entity is the manufacturer of the final product.
>
> It is expected very little from the project itself:
>
> * provide a proper documentation of the project
> * document the CVE-policy (mention how fast you can react, what the contact address is, when and where fixes are announced ...)
> * be available for market surveillance authorities in cases of questions
>
> coreboot does not have the obligation to fix vulnerabilities. If a fix is provided, make sure it is
> documented and made available to all users. It is enough to have it merged on main and document it
> properly. Putting in release notes can already be enough, too.
>
> There seems to be an incentive to join forces with other users to form a single entity for all
> CRA-related obligations.

I've seen that claim a few times,but I never was able to trace that 
claim to its source. Could you enlighten me who suggested that so I can 
educate that party?
Once a number of open source projects "join forces" to form a single 
entity, their obligations mandated by the CRA increase significantly 
because they will most  likely be classified as an open source steward.
However, if an organization already is an open source steward, it makes 
sense for them to rope in more projects to spread the load/cost.
The coreboot project (even if we consider the wider ecosystem of related 
projects such as payloads etc.) is nowhere near being an open source 
steward.

Unfortunately, lots of statements about the CRA published by 
self-proclaimed experts in the open source world are either simply wrong 
or refer to early drafts of the CRA (without explicitly stating said 
reference). Such misleading and embarrassing statements usually are 
neither retracted nor annotated with "no longer applicable".

I strongly recommend reading the CRA in its entirety regardless of 
whether you consult third parties about interpretation. The law is 
really well-written and easy to read (yes, even if you're not a lawyer) 
and even contains explanations (what is the intent, how are certain 
terms defined).


For example, one often overlooked gem in the CRA is this:
Chapter II, article 13, item 6:
"Manufacturers shall, upon identifying a vulnerability in a component, 
including in an open source-component, which is integrated in the 
product with digital elements report the vulnerability to the person or 
entity manufacturing or maintaining the component, and address and 
remediate the vulnerability in accordance with the vulnerability 
handling requirements set out in Part II of Annex I. 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 means manufacturers must notify upstream about a security bug, fix 
the security bug and contribute their security fixe upstream. This is huge.


> Three bullet points when it comes to reporting obligations:
>
> * report vulnerabilities
> * report incidents
> * volunteer reporting on other issues
>
> Obligation to report is only for known and exploitable bugs/vulnerabilities. If a bug /vulnerability is under embargo/not public yet, this obligation does not apply.

Citation needed for the "embargo" part. And no, recital 70 of the 
preamble of the CRA can not be interpreted in that way. Yes, I have read 
that text. At most, a manufacturer may ask the coordinating CSIRT to 
delay dissemination to other CSIRTs and ENISA, but that does not delay 
the obligation to report to the coordinating CSIRT and any such delay is 
at the discretion of the CSIRT.


>   In case of doubt, reach out to market surveillance authorities and ask.

Indeed. Or ask the European Commission. They even held multiple 
(extremely helpful) talks and discussions at FOSDEM and other events.


> Voluntary security attestation → What does it mean in the context of OSS?

That would be CRA chapter II, article 25 "Security attestation of free 
and open-source software"


Please note that right now there is an active process of writing 
harmonized standards (as referenced by the CRA). One such harmonized 
standard in development is "Essential cybersecurity requirements for 
boot managers". I hope to see someone from the coreboot project 
participate in that effort. The timeline for that standards process is 
extremely tight and a participation later this year might already be 
pointless. There is arguably some overlap between the vertical 
"operating systems" and "boot managers", but current consensus seems to 
put x86 system firmware in the "boot managers" camp.

(No, I unfortunately don't have time to attend the meetings of the boot 
manager harmonized standard on behalf of coreboot, I'm already working 
pretty much full-time on another related harmonized standard. I can 
provide a crash course for anybody willing to participate, though.)

Regards,
Carl-Daniel
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]