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 -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
