Understanding the EU Product Liability Directive

Jake Milstein:

Well, hey, everybody, and thanks for joining me. My name is Jake Milstein at Contrast Security. I'm being joined today by Jeff Williams, who is the founder of Contrast and also the creator of the OWASP Top Ten. And this is gonna come up because it's important today. He's also a lawyer, although he keeps that hush-hush.

So, Jeff, big directive by the EU Council just came in, just taking effect now about software liability. Can you tell folks what it's about?

Jeff Williams:

Yeah. Forever software has been licensed, and it has these restrictive terms in it, like use at your own risk and don't use this on anything important or nuclear reactors or anything like that. Well, the EU just said, forget all that. We're putting a new rule in place that now software is just like any other kind of product. Like, if you have a chainsaw that has a defect and it hurts somebody, the chainsaw company is liable for that defective chainsaw.

Now software producers are in the same boat. If you have software and it has some kind of defect and it hurts somebody, you can be sued in the EU for damage.

Jake:

And so when you say defect, like, what counts as a defect? 

Jeff:

Like, really, anything that causes harm to somebody explicitly including security defects.

They focus a lot on safety, but they're really thinking of that very broadly. Like, they talk about data disclosure and a bunch of other kinds of traditional cybersecurity kinds of defects.

Jake:

And so a vulnerability that you know is in there is part of this. So if you release software with a vulnerability and that ends up creating either a ransomware situation or data disclosure situation, you're liable now? Is that how it works if you're creating software?

Jeff:

That's exactly right. They're upsetting the apple cart. Everything's different now, and it doesn't matter if you have that license agreement. It doesn't matter what kind of software it is. It could be SaaS or a mobile app or a desktop app or middleware or something. It doesn't matter.

It doesn't matter if you wrap it in a service. It doesn't matter what you did. This is what's called no fault liability, and it's extremely broad. It means it doesn't matter if you were negligent or you did the best development job you could.

It doesn't matter if you have a clean scan report. It doesn't matter if you've checked any boxes. It doesn't matter if you have an SBOM. It doesn't matter if you're trained in security.

Like, all that stuff that we talk about, yeah. 

Jake:

It doesn't matter. The only thing that matters is the outcomes, and I think it's gonna force people to really focus and change the way they think about AppSec, not just checking the box, but getting to a level where they're comfortable with the fact that they won't be exploited.

If you can be negligent for anything that happens to your software, you want to make sure that there are certainly no vulnerabilities.

How do you see people doing that? How do you see companies making that change?

Jeff:

Well, I think they're gonna have to step their game up. I mean, they're gonna have to focus on the most critical things first and really think about what could cause harm and stamp those things out of their software.

They should prioritize the risks by the damage that it could cause to their users. One thing that's really important to remember is this only applies to natural persons, real people.

If you're a company and you buy software from another company, you don't have a right of action here. Not yet. Maybe they'll change that. There’s not a principled reason that I can think of why they would do that except for just to maybe take a baby step first before they go all in. It's a big thing.

Jake:

That's super interesting. So if a company buys something from another company, you can't sue under this, but it's that end consumer, the person whose Social Security number or – well, I guess not Social Security number, we’re talking about EU – but their personal data, their personal health information, their PII was just all of a sudden, stolen by somebody. Well, that's really interesting. 

Is it all software that's part of this? Is it paid and open source or just paid software?

Jeff:

It's paid software. Open source by itself isn't covered. If you use open source libraries in making your software, then you're responsible for any vulnerabilities or defects that might be in that software. So it really puts the onus on the consumers of open source, the companies building apps and selling them. That's where the liability lands.

Jake:

And one last question for you. What about zero days? What about if there's a zero day and you don't know about it because it's a zero day, is that still a defect?

Jeff:

Well, the way you ask the question makes it hard to answer.

There's a thing in this directive that says there's a development risk defense. And what it means is if the vulnerability was beyond scientific and technical knowledge at the time the software was released, including updates, then you're not liable because it wouldn't be possible for you to prevent that vulnerability.

But zero days are mostly instances of things that we know about, like safety serialization and expression language injection and so on. Those things are not beyond the state of the art. And so even if it's a zero day, a specific instance of one of those old libraries, it's like old wine and new bottles here, and it doesn't matter. You're still gonna be liable for that. So those really new things, new classes of vulnerabilities come out very infrequently, like, maybe one a year.

And so most zero-day events are going to be very useful to anybody.

Jake:

Yeah. So most zero days are not beyond scientific and technical knowledge and therefore no. Well, super interesting. Well, Jeff, thanks for joining me today on this. And on behalf of Contrast Security, thanks everybody for joining us. Have a great day.