EU Cyber Resilience Act Pressures Software Makers

Hey everybody, we're here in Minneapolis at the Open Source Summit, and we're having a little chat about the Cyber Resilience Act coming out of the EU with Christopher Robinson. How are you doing today? I'm doing well, my friend.

This thing is coming faster than most people realize. Right. But there's also a lot of folks, it turns out from your own surveys, that don't even know what it is yet.

Right. So for the uninitiated, explain. Yeah.

So broadly, several years ago, the European Union made the Cyber Resilience Act, and it went into effect, I believe it was two years ago. And this year, 2026, is the first year where some of those legal obligations come into effect. And then next December, December 11th, 2027, is when the cybersecurity requirements come into effect.

The law is 90 pages long, so it's not surprising a lot of people haven't read it. But if you're a manufacturer and you're making a product and you're trying to sell that in the European Union, there are some pretty severe legal and financial consequences that arise from this. So, we and other people in the open source ecosystem have been talking about this for two to three years now.

And we have education classes, guides, tools, working groups, webinars. We've done a ton of work. And last year we worked with our LF Research team, and they did a study kind of understanding how people know what they know about and what they're planning on doing around the CRA.

The results last year weren't great. And they weren't so great, we called the title Unaware and Uncertain because again, people didn't know what they had to do or when things had to happen. Again, the community, we spent the last year doing classes, webinars, outreach, conference presentations, podcasts, interview, all this type of stuff.

So we did the report again, did the survey again, and we had hoped that, hey, all of our good work is going to yield some results. So in 2025, the survey showed that globally about 62% of the respondents either didn't know anything about the CRA or only know very little. Hmm.

That was bad. We were all sad. We got the results from the 2026 report.

And the report, we actually reached out to almost double the number of respondents, so the data is much better. We have deeper, richer data now. Unfortunately, the results are now about 66% of the respondents don't know anything or knew very little.

So we were very sad about that, and we did a little blog this week talking about it, trying to help shock people into this is something that is very serious, and you need to take steps now. So what is the most serious consequence here for folks who write software? What is it that should be keeping them up at night about this?

So if you're a manufacturer and you sell what's called a product with digital elements in the European Union, so you sell something that's hardware, software, firmware related, or you have an app on a smartphone, an Xbox, these types of things. So if you sell that in the Union, the most stiffest penalties. So if you are found to be violating the cybersecurity requirements, and there are 21 of them in Annex 1, if you are found to be violating those, you have earned yourself up to a two and a half percent of your last year's total global revenue penalty for each infraction.

Got it. So if you violated all 21 of those things, that could be upwards of two and a half percent your global revenue times 21. Billions of euros are at stake here.

So is it the people who are consuming, say, an open source project that need to worry about this most, or do the maintainers need to care? Because a lot of times the maintainers are like, "I just built this thing. " So fortunately, open source maintainers, there's some words about them in the law, and it's like the whole digital ecosystem's built upon open source software.

There are no requirements. So if you're an upstream maintainer, you legally don't have to do anything. Okay.

Now, most of these maintainers, these creators, take a lot of pride in their work. Their software is their resume, is their reputation and their life. So they do care, and they will want to do some things.

And what we're trying to, part of this education work we've gone through, is to help educate the manufacturers that actually have these legal and financial risks, trying to educate them on how to engage with open source maintainers. Because again, they don't have to do anything. They probably will be helpful on some level.

Mm-hmm. But manufacturers are the ones that have this problem. They own this risk.

Yeah. And they need to figure out how to persuade upstream to get the outcomes they need. Well, beyond the fact that it's a point of pride, they'll also have multiple choices out there, and some people will lean towards the project- Yep ...

that might have more of these issues resolved for them. Right. Well, and generally, GitHub is the largest forge on the internet.

They hold about 80% of open source software. Every year they do a report. Last year, the State of the Octoverse report stated in GitHub there were 630 million projects.

Fun fact, not every piece of software is written to the same standard of quality and is not intended for commercial use. I know it's shocking. I'm appalled.

And a lot of these projects are, "Hey, I'm a student, and I'm doing a research project," or, "I'm doing an experiment or prototype," and then it gets abandoned. There are a large portion that a project intends to land within a commercial product, and they embrace that, being part of the global economy. But most don't.

They are unaware and uncertain ofLike all these things, they just want to write the best software they can, serve the goals that they want to do. " That was some of the very early talk around when the original draft of the bill was very aggressive towards upstream and actually had requirements, financial penalties on them, and we and other foundations and groups were able to kind of get that pulled out of the law. But that was absolutely a tactic.

" And it's that manufacturer, that commercial entity is making a choice to use this and share it with their customers. They're selling it for money. Mm-hmm.

And we have another more probable problem is that, again, these manufacturers have all this money on the line. They're going to come upstream demanding these maintainers do this work for them and kind of unfairly putting the burden onto them. So the likely outcome is that people might just stop writing software.

That is a risk that some people might say, "This is too much work. I don't want to work for giant hyperscaler. " Is this likely to become a political football?

" That is absolutely a plausible scenario. It already has. We see this a little bit more with AI right now, where globally, governments are kind of racing to regulate AI, and the current US administration has been avoidant and distasteful of regulation.

But in the case of AI in particular, they are kind of getting all in. And that the scenario you described is absolutely something that could happen, and it takes away from the international global collaboration of why open source has been able to deliver $8 trillion worth of value to people, and the neutrality in space. Trying to politicize it is just going to hurt everybody.

Now, it wouldn't be the first time that somebody sat down and just decided to wait out the EU and the bureaucrats in Brussels and say, "Cooler heads will prevail," and eventually companies will start yelling at them and the regs will change. So is that a likely scenario, or how hard and fast is this stuff? We get to talk with the European Commission and the other kind of actors within the union, and we've kind of brought up a couple of points.

There's a whole flock of standards that manufacturers need to understand to be able to comply with the law. A bunch of those aren't going to be ready until after the law goes into effect. We've brought that to their attention, and they are very blunt and direct in saying, "The law is the law.

The dates and requirements are in there. " So this is absolutely going to be settled in the courts. This year it's just the vulnerability reporting requirements that come online.

That's the easiest piece is being able to report exploited vulnerabilities. Next year is all the cybersecurity requirements, the attestation, the CE mark requirements. Those are more complex, and those absolutely, the law goes into effect December 11th, 2027.

I anticipate the first lawsuits will be filed December 12th, which will delay people's understanding of what they need to do. Right. And they'll be kind of in limbo for a period of time.

So how big a lift is it really? Some of the things sound quote unquote reasonable. Mm-hmm.

And there has historically been a lot of maybe effort and labor, but maybe AI is going to automate some of this stuff as well. Mm-hmm. So at the end of the day, just how much pain are we looking at?

I'm a biased cybersecurity guy. There is nothing new in the CRA. These are all things that I have advocated in my cyber practice for almost 30 years.

Least privilege, identity and access control, multi-factor authentication. The newest thing is software bill of materials, and that's almost a decade old. And these are things that in the US, NIST has written about, CISA has written the Secure by Design guidelines.

So internationally, all these things are expectations that people should have been doing. So from my perspective, why weren't you doing this? Why are you kicking the can down...

I understand the business reasons why, but it's just like eh. All right. But if you are a large organization and it takes you quarters to build a release and release it, you're going to have a really bad day steering your organization's culture to be able to hit this more rapid cadence.

There's a ton of documentation. " Show me the documentation that you have one, show me the documentation and evidence you're following it. So these are all kind of basic things they should be doing.

Hopefully, they have. They might not. So won't this ultimately, the reason we don't do all those things is they take time and they add cost.

Yep. So if we're going to be forced to do those things, will we need to allow for, A, more time and, B, more expense for the development of software as it relates to all these projects? And maybe that's the difficult conversation we're about to have with the board.

Yeah. I think allowing more time is not an option. It is absolutely a risk management exercise.

You need to understand where you're exposed, you need to understand what components that are in your products, and you need to make some hard choices. Reduce your attack surface. If instead of having 1,000 dependenciesMaybe 500.

Kind of reduce your scope of work, but that's going to be a conversation that needs to be bubbled up to the board, and it needs to be shared with them in business terms. These are the likelihood and impact of what this consequence is on. So to your earlier point, we've been talking about best practices forever.

Mm-hmm. They have been followed unevenly, to be generous. " And you jokingly mentioned, can AI help us?

And yes, artificial intelligence tools, LLMs, are a method that we can help accelerate things. They're not going to buy you back more time, but they can definitely help focus your work. They can do risk assessments, threat modeling.

They can do patch analysis, that type of stuff. So what we're going to need to do is be comfortable with ambiguity and be agile and be able to understand, where are the hot areas I need to focus on, where my greatest risks are, and devote my resources and my board's attention to those so that I can get movement on that. And one of the things you can do is participating in a foundation like the LF or the OpenSSF, Apache Eclipse.

There's a dozen foundations, and these are all people that are like-minded folks like us. They have documented practices. They might have tools.

They might have infrastructure to support. Specifically, I have classes. I have guides.

I have tools and education. We're going to be building AI skills to codify those best practices. Now I'm going to pass it over to the robot, and the robot can be an expert system saying, "Hey, I noticed you have some SQL injection pathing here.

" That's the only way you're going to get through this is automation. And it would seem to me that the auditors are going to use AI to find these issues faster and at less cost for them. Yes.

So, ultimately, is this now a math choice, right? My math choice is either I'm going to do the right thing, or I'm definitely going to encounter an issue that's definitely going to require a lawyer, and by the way, the lawyer's a lot more expensive than doing the right thing. Right.

Well, and AI and LLMs are great technology. They're not magic. They're not infallible.

It's all purely math. They're predicting what the next likely word is and giving that to you. They make mistakes a lot.

Our friends at Sonatype were analyzing a subset of patches generated by AI. It was like 30% of the time, they were wrong. They were bad.

They had errors. They added regressions or more vulnerabilities. So these are excellent tools, but you have to understand the risks and flaws.

" And that's where we all kind of, as we go enter into this, we need to understand that there's some unpredictability here, and whether you're an auditor and taking the gospel of what this robot hands you, or if you're an engineer and you're using LLM to augment your writing and patching, you need to understand that these things are fallible. You need to double-check the work, and you need to have a senior person, whether it's a developer or a senior auditor, double-checking that homework before you hit print and take action. So what's your best advice to folks about how to go have this conversation with their teams and their execs?

Because it's not necessarily going to be a popular subject. It is absolutely not. I'm a practitioner of a risk methodology called OpenFAIR, and it's a quantitative risk assessment methodology.

And if you're trying to talk to the Cs, when you're talking to engineers, it's a different style conversation, but if you're talking to executives, and that's where you need to focus to make the changes within your company. These are the people that have the purse strings. They supply the resources.

They determine what the priority is. Talking to them in business terms. There is a 90% likelihood that in the next 90 days, we're going to experience a $10 million loss.

Hey, do we care about that? Would you like to lose that? And again, it's 90%.

It's not 100%, but there's a strong likelihood this is going to happen. And here's some suggestions on how you can mitigate that risk. And then, as you're doing your risk assessment, don't worry about the unlikely or improbable things.

We could get hit by an asteroid tomorrow. That would be very sad. There's absolutely nothing I can do about it, and the probability is infinitesimally small.

Don't over-index on those type of problems. Don't make that bet on the prediction market? I won't.

But thinking about the most likely attack today that you're going to get breached on is credential theft and reuse. That is almost 60% of the time, per Verizon and CrowdStrike. This credential reuse is how bad guys get into your environment, how they steal your data, manipulate your systems, infiltrate your customers.

Vulnerabilities are about 20% of the likelihood. Very important, and that's where the space with developers and folks like us get to help. But think about where your most likely problem is.

You could take an LLM, and LLMs are amazing at pattern matching. Scan your repository for in the clear passwords or S3 bucket keys or tokens. That is going to happen, and that again will help you avoid violating laws like the CRA or data privacy laws like GDPR, the California Privacy Act, those types of things.

All right. Folks, you heard it here. I know it's hard, and there's a lot of choices that you've made over the years, but I guarantee you one thing, any choice that you make in the future that involves a courtroom is going to be a lot more expensive than just doing the right thing.

Right. Hey, buddy, thanks for coming by. Thank you for having us.

All right. And we'll be back in a minute.