The European Cyber Resilience Act (CRA) is reshaping security practices for software products distributed in the EU. In a recent interview, Michael Lieberman, CTO and Co-Founder of Kusari, provides clarity on what CRA means for the open source ecosystem.

Who Bears Responsibility Under CRA?

The CRA primarily targets commercial entities selling products with digital elements in the EU, not individual open source maintainers. As Lieberman explains: “If you’re an open source maintainer and not doing it commercially, you’re off the hook for this.”

He clarifies that the legislation aims “to go after big names”—companies that “have made billions of dollars selling open source, but when it comes to something like, ‘Hey, you’ve had a massive vulnerability that’s been known to be exploitable for the past three months, and you haven’t done anything about it,’ they all just throw their hands up and say, ‘Hey, that’s not on me. That’s on the open source.'”

Three Key Roles Under CRA

Lieberman identifies three key personas involved in the CRA framework:

• Open Source Maintainers: Individuals not selling code commercially have no obligations
• Open Source Stewards: Organizations like Linux Foundation that help foster security collaboration
• Manufacturers: Companies selling products with digital elements bear primary responsibility

Practical Steps for Security Compliance

For projects looking to align with CRA-level security practices, Lieberman points to the OpenSSF Security Baseline, which provides controls for maintaining secure projects:

“It’s essentially a set of controls that describe how you should maintain a project—things like having security documentation, enabling multi-factor authentication for accounts with access to the main branch, running security scans, and similar activities.”

Supporting tools include:

• OpenSSF Scorecard: Generates reports checking security practices
• Darn: Performs remediation actions (e.g., adding security.md files)
• All Star: Applies baseline rules across organizations

Addressing Common Confusion

The CRA has some limitations in its scope. Lieberman notes that “anything that falls under national security or military purposes doesn’t fall under the CRA,” and that certain industries already have equivalent regulations.

When it comes to SaaS products, there’s further nuance: “Generally, SaaS offerings don’t fall under the CRA. However, things like the Netflix client you might download onto your TV—that does fall under the CRA.”

Improving Global Collaboration

With different regions developing security regulations, Lieberman expresses concern about fragmentation: “Once we start to say, ‘Hey, there’s going to be different vulnerability schemas and different security schemas,’ that’s going to be a huge problem.”

He advocates for standardization: “What can we do to at least align on a bare minimum,  so we don’t end up in a situation where selling a product in Europe requires a completely different set of security tools than selling the same product in Asia or the US?”

Ultimately, Lieberman sees the CRA as potentially beneficial for the open source ecosystem: “I think the CRA provides incentives to support the manufacturers who may be capitalizing on [open source] to deliver the right solutions. It provides the Linux Foundation a strong reason to say, ‘Hey, we need to be working together more.'”

By placing responsibility on commercial entities rather than individual maintainers, the CRA creates a more sustainable security model where those with resources address vulnerabilities.

For more information on implementing security practices for open source projects, visit the OpenSSF or Linux Foundation websites.