The CRA and what it means for us

With the ratification of the Cyber Resilience Act (CRA) in Europe, there has been a lot of misunderstanding of what this means for Linux developers, Linux users, and manufacturers of devices with Linux inside of them. This talk will attempt to provide a rough understanding of the issues involved, who is affected, and what this means for everyone in our ecosystem. It is an updated talk from the Embedded Recipes version, as things have changed since then.

Greg KH

Transcript

1. The CRA and what it means for us Greg Kroah-Hartman gregkh@linuxfoundation.org git.sr.ht/~gregkh/presentation-cra
2. All of this is just my personal opinion, based on working as part of CRA expert group. “Us” means “Open Source developers”, not “manufacturers” or “businesses” or any other corporate role. I’m only going to focus on how this all will affect us individual developers in our role of creating software that everyone else uses. Disclaimer
3. The CRA has loads of TLAs ›Cyber Resilience Act (CRA) ›Product with digital elements (PDE) ›Open Source Software (OSS) ›Software bill of materials (SBOM) ›European Union (EU)
4. What is the CRA ›List of software “ingredients” in a “device” ›Making sure those “ingredients” are “safe”
5. What is the CRA ›EU Regulation covering PDEs in the EU market ›Obligations for manufacturers, distributors, and importers ›Product classification ›Market surveillance and enforcement
6. Market surveillance and enforcement ›Designated Cyber Security Incident Response Teams (CSIRT) ›European Union Agency for Cybersecurity (ENISA)
7. What is the CRA – cont. ›Requirements for cybersecurity portions of the PDE life cycle ›Vulnerability reporting and handling
8. Software life cycle requirements ›Risk management ›Design ›Development ›Documentation (SBOM) ›Production
9. Different “types” of products ›Default ›Level 1 ›Level 2 ›Critical
10. Stuff outside the scope of the CRA ›Services (websites, SaS) ›Many specific types of devices – Auto, medical, aeronautical, marine, etc. ›Non-commercial hobby products
11. Stuff outside the scope of the CRA ›Services (websites, SaS) ›Many specific types of devices – Auto, medical, aeronautical, marine, etc. ›Non-commercial hobby products – Until your software gets added to a product!
12. Different classification of groups ›OSS developers ›OSS “Stewards” ›Manufacturers ›Integrators ›Distributors
13. Is your open source project covered? * Are you providing FOSS or merely contributing? NOT IN SCOPE providing Are you directly monetizing the project? “Manufacturer” Legal person providing support to FOSS intended for commercial activities? yes “Open-source software steward” Development in the course of a commercial activity (in the broad sense)? no yes no yes no NOT IN SCOPE NOT IN SCOPE contributing * Simplified flow-chart for presentation purposes.
14. “legal person” ›Disagreement about what this means right now ›Hopefully will have clarity in a few months
15. Open-source Software Steward ›“Foundation” or other legal entity releasing open source software ›Supposed to not be an individual
16. Stewards responsibilities ›Provide a contact for security issues ›Report security fixes to <SOMETHING>
17. You should already be doing this! ›security.txt ›Become a CNA or fill out a web form ›https://bestpractices.dev/ ›reuse tool from FSFE
18. Stewards checklist https://github.com/ossf/wg-globalcyberpolicy/blob/main/documents/CRA/ checklists/OSS_Stewards_Obligations_Checklist.md
19. Timeline ›10 December 2024 – “entered into force” ›11 June 2026 – Governments ready – Assessment bodies ready
20. Timeline – cont. ›11 September 2026 – Manufacturers must report ›11 December 2027 – Entire regulation applies
21. Standards ›Use of standards is voluntary ›Standards are not finished yet ›Some will not be finished until after Dec, 2027 ›We are participating in the standards process
22. External Resources ›Linux Foundation CRA site ›Linux Foundation free CRA training course ›OpenSSF documentation ›Open Regulatory Working Group FAQ