Enacted in December, the European Union’s Cyber Resilience Act (CRA) introduces a set of mandatory security requirements for all commercial products with digital elements. The idea is to protect citizens from malicious hackers by improving the security of both hardware and software of these products.
Think of all the un-updated Android smartphones out there.
For manufacturers, the legislation comes with some pretty severe financial penalties, both for security breaches that cause consumer harm and for failing to disclose possible vulnerabilities.
But what if those products use open source libraries, and what if those libraries are found at fault?
For the most part, open source developers will not directly be subject to CRA unless they are actively making money from their software. Software distributors, such as Linux providers, however, can be subject to the law, and will most likely need to strengthen their entire software development life cycles.
And while the CRA does not concern individual open source developers directly, if their projects get used in commercial outlets, they may be asked to uplevel their security practices, noted Christopher Robinson, chief architect of OpenSSF, an industry consortium that aims to improve the security of open source software.
Robinson spoke with TNS at the Linux Foundation‘s Open Source Summit North America about this subject. At the conference, many of the U.S. attendees didn’t seem to know much about CRA, though European attendees knew all about it — and many fretted about the impact it would have and their own projects (and no doubt we’ll witness this concern next week at Open Source Summit EU as well).
“Pretty soon, people are going to be horribly liable for every single CVE [common vulnerability and exposure] in software that they ship,” Andy Lewis of ReversingLabs said, somewhat dramatically, in a talk at the Open Source Summit NA. “There’s some really bad days coming.”
Others, however, are more optimistic about CRA, even if the law will require some upfront work.
During a talk at the Open Source Summit NA, Red Hat security and privacy leader Roman Zhukov noted that CRA has the potential to finally fix many of the security issues that have long plagued open source.
“Now we have a great momentum powered by CRA to make sure we can finally fix security for those projects that didn’t look into it properly,” he said.
The legislation was enacted in December 2024. Beginning on Sept. 11, 2026, manufacturers will be responsible for reporting known vulnerabilities and exploitations. And the full law gets enacted in December 2027.
Manufacturer, Steward or Contributor?
Open source is still dominated by individual developers, who manage projects largely on their own time. And the EU tried to leave them alone.
As Zhukov pointed out in his talk, open source is “out of scope” from CRA regulations as a whole. But, he says, “the devil is in the details.”
There are scenarios where an individual developer may be brought into the courtroom, he noted: if they maintain a project that someone else sells, or if they charge for services related to the software.
“It is super nuanced,” Robinson agreed. You can take money for your project to cover costs and even living expenses. Once a project owner turns a profit, however, then they start to assume liability and will need to ramp up their reporting processes.
The law describes several different roles, each with a separate legal obligation. One is the manufacturer — or the vendor — that is primarily legally responsible for the product. There are also stewards, which are organizations like OpenSSF or the Linux Foundation. And, finally, there are contributors.
“But at the end of the day, if you take more money than they think you should, they potentially could bump you up to the manufacturer category, and there are potentially very harsh penalties,” Robinson said.
A manufacturer has a long list of obligations to the EU. Just as consumer appliances have certifications from the likes of Underwriters Laboratory, so too will manufacturers’ software-driven products come with safety guarantees.
Because of the reporting requirements, manufacturers will be forced to enact (if they haven’t already done so) secure-by-design development practices, software life cycle development and vulnerability management practices.
CRA liability for developers, from Roman Zhukov’s talk.
Liability Costs
If a malicious hacker breaches an account through a vulnerability in the device’s software stack and gets into a bank account or some personal data, then the manufacturer will be held liable.
According to the regs, if a company is aware that one of its products is being exploited, then it must provide the commission notice within 24 hours of finding out. The company must also provide the user with either a fix or an advisory detailing how best to protect themself from the attack. A full fix must be provided within three weeks, and a postmortem must also be provided.
For each infraction, the damages could be as much as 2.5% of the manufacturer’s total global revenue for that year.
There’s also a 1% penalty for failing to give out or giving out false information about a vulnerability.
“There’s a lot of documentation that the commission is going to be asking for, like SBOMs [software bills of materials] and risk assessments,” and a lot of current projects don’t keep up with this level of reporting, Robinson said. The OpenSSF has a free 90-minute virtual class to teach developers about the law (LFEL 1001).
So those software developers who supply libraries, utilities and applications to digital components will have to “get an uplift in security,” presumably from the manufacturers themselves, with additional engineering support.
Open source security projects like OpenSSL and OpenSSH will need to report vulnerabilities more quickly and provide more documentation about them.
“I know the commission would really like it if everybody kind of managed their software and their products like auto manufacturers do, just because there’s so many requirements, and safety is the top concern,” he said.
CRA liability for developers, from Roman Zhukov’s talk.
About the Distributors
Commercially focused open source software distributors such as Red Hat and Canonical are in a “weird spot” in relation to CRA, Robertson said. They can fall into the role of either manufacturer or a steward. Red Hat is both, for instance, because it offers Red Hat Enterprise Linux as a service, but it also maintains the Fedora nonprofit community.
“So, depending on what the problem is, they will have both hats available,” Robinson said, making a pun. “But given where the problem is, they’ll wear one or the other. The law is very clear that you can only have one role in a given incident, as you either are manufacturer or you’re a steward.”
So commercial distributors such as Red Hat will need to invest, as many have been doing, into teams of engineers to work upstream, ensuring the dependencies are being secured and documented.
Filling out some of these forms might be new to some developers.
Manufacturers in particular will need well-documented risk assessments and threat models, which describe how a product will be used, how it could be misused, and what actions they took to mitigate this particular threat.
“Most [software] companies don’t have that kind of rigor and discipline in their software development, and they’re going to need to have it, because the Europeans are going to ask,” Robinson said.
For individual developers, the OpenSSF has provided a baseline list of 41 practices they need to do to keep their projects secure, in the Open Source Project Security Baseline. The recommendations are split across three levels of maturity. Level one, individual developers should be “able to handle with a minimum amount of effort,” Robinson said. Mostly, it is documentation and configuration. The succeeding levels are aimed at larger teams.
The baseline builds from other security guidelines, such as those for PCI and HIPAA where relevant, and much of the reporting and even remediation processes can be automated over time.
The post What the EU’s Cyber Resilience Act Means for Open Source appeared first on The New Stack.
Open source is about to collide with product liability in a major way.