Host Intro (Gene Kim)

The next speaker is Dr. Stephen Magill, VP of Product Innovation at Sonatype, who has been doing research in software security, static analysis, and development best practices ever since his PhD work over 15 years ago.

You heard him yesterday when he presented on Java's paradox and the difference between price elasticity versus inelasticity. The prospect of software liability has been talked about for decades, but there are many reasons, and there is actual evidence to believe, that the development organizations that create software and services will actually be liable for the software and services they create, which includes all the software components they are made of.

If that is true, things like GDPR and the Log4j remediation are two events that can teach us important things about how to get ready for this new era of software liability. Here's Stephen.

Stephen Magill

Thank you, Gene. I'm here to talk about software liability, which means talking about regulations, which can be kind of boring. So I'm going to start off by talking about cars, which are exciting, right? Except actually I'm going to talk about car vehicle ignition switches, which is maybe somewhere in the middle.

I want to start with this story, which goes back to 2014 and has to do with a particular fault in certain Chevy vehicles. In those vehicles, the ignition switch had the property where, if you had a sufficiently heavy keychain on it, something like the picture on the right here, and it vibrated in the right way, that could cause the ignition to turn off. The problem was this little pin called a detent plunger that was too short. It wasn't exerting enough pressure, and so it didn't satisfy GM's specifications in terms of the force required to turn that.

When the car turned off unexpectedly, power steering stopped working. The person in the car gets surprised. And critically, two seconds after the ignition turns off, the airbags stop working. This makes it much more likely that you get into a wreck and makes it more likely that you get injured or even die in a wreck. That's exactly what happened. Over a hundred people, by some estimates, died as a result of this issue.

GM identified the part that was to blame and promised to do better next time. They said, we'll pay our suppliers more, we'll work with them, we'll check quality better than we were in the past. No need to do a recall or anything. That might surprise you, because that's not at all what happened. That's not what we expect from vehicle manufacturers.

What we expect when you have an incident like this is this: 30 million cars were recalled, $900 million in fines, over $600 million paid out in the various lawsuits as settlements for the victims of this issue.

We all expect this. We expect this from vehicles. We expect this when it comes to food safety. If some tainted produce gets into the supply chain, we expect that that can be pulled, and that growers or distributors, whoever was at fault, will be liable if they didn't follow best practices.

But in software, it's a very different story. We have the ability to put into our licenses and end-user agreements language like this. This actually comes from ChatGPT's agreements, so it's topical, but this text is basically verbatim in so many licenses: basically, we're not liable. We're not liable for any damages, even if we've been advised of the possibility of such damages. We knew this could be a problem and we didn't do anything, but hey, you can't sue us.

That's just not working anymore. We've tried voluntarily upping the bar on security, and certainly a lot of companies have. I think a lot of companies here are paying attention to security as part of their process. They're doing all the right things. But as an industry, we're not where we need to be.

I think a great example of this is Log4j. Log4j was sort of our ignition switch moment. It's this critical component. Something was really wrong with it. We essentially needed to do a recall, right? Get that out of production. Most people did. But this is a graph of downloads of Log4j from Maven Central, by week. You're seeing different versions of Log4j. The red ones are all vulnerable versions.

This graph goes about 10 months after the disclosure. If you look at the numbers today, they largely are similar to the right of that graph. Basically, 38% of the Log4j downloads are still the vulnerable version. We have not succeeded in pulling that bad component out of our supply chain. Because we haven't done it voluntarily, the regulation monster is coming now.

That's what I'm going to be talking about: what does that mean? What sort of regulations are here, and which ones are coming, so that we can all get prepared?

Actually, this is not without precedent even in software. We have some regulations that have already come to pass, namely GDPR. In 2016, GDPR was passed, and that happened in the wake of a number of high-profile data breaches. We kept hearing year after year about disclosures of personal information: credit cards, Social Security numbers, passport numbers, birth dates, Facebook's thing with Cambridge Analytica, all this personal information getting out there.

GDPR was at least in large part a response to that. It was saying, we've got to give people control over their data so they can at least decide, hey, I don't trust this particular company. I want them to pull my data. I want to make sure they don't have access to it.

That was first this data governance issue. But next is security, and it's easy to see why. Just like the data breaches chart kept growing and growing, we see the same thing with cybercrime. Cybercrime is now a $6 trillion industry, which makes it, if it were an economy, the third-largest economy after the U.S. and China. That's forecast to grow to $10.5 trillion by 2025, which will make it the largest transfer of wealth in human history. Think about that: over $10 trillion being transferred from legitimate individuals and businesses to cybercriminals.

This is why cybersecurity has the attention of every government out there, all sorts of different agencies in the U.S. and the EU and Canada, Australia, everyone is looking at this issue and thinking, what can we do? It's not working. We're not doing what we need to do. What rules can we put in place to make sure this improves?

It's not just the economic cost either. Technology serves such a critical role now that, just like when the ignition switch fails, people can die. When our technology solutions fail, the same thing can happen.

Hospitals in particular are frequent targets of cyberattack. There were over 500 healthcare breaches in 2021. Ransomware attacks continue to increase in the healthcare space. What does a ransomware attack do on a hospital? It takes their administrative systems offline. They can't check patients in. They can't follow their normal care procedures. It causes delays, which can result in deaths. If you look at the statistics, 24% of attacked hospitals have noted a rise in their mortality rates during the attack.

It makes sense that this is getting attention. It makes sense that we have to do something about this. In fact, FDA, the U.S. agency that's in charge of regulations for medical devices, has acted. About six weeks ago, they issued guidance saying they are now reserving the right to fail to approve devices if they have cybersecurity issues, or if the manufacturer is not following best practices.

They expect the manufacturers of medical devices now to be able to say what open source software is in that device, to have a system for monitoring that open source for vulnerabilities, and to have a disclosure and an update procedure to respond to critical vulnerabilities. This is in large part because these medical devices are often the entry for these hospital attacks.

But it's not just medical devices. There's a lot of discussion, legislation, guidance coming out that applies generally to software. This is a timeline of developments in the U.S. I'm not going to step through everything. The point here is just that there's a lot of discussion happening.

In the European Union, there's been discussion with the U.S. about coordinating efforts. The European Union Agency for Cybersecurity, ENISA, has produced guidance and been making steps towards additional rules and regulations in this space. I'm going to talk about where that's heading.

But I want to first talk about where we are. Everyone probably has been hearing more and more chatter about SBOMs, software bills of materials. That's because this is the thing that's in the current legislation. At least in the U.S., the federal government has said, we are going to start requiring this. Anyone who sells to the federal government is going to have to produce a software bill of materials. It's in that FDA guidance as well. It's in the legislation being considered in Europe.

This is a great first step. What is a software bill of materials? It's a list of all the open source components that are in your software product or your device, if it's an embedded system. What it does is make sure that you at least know what's going into your software. It's requiring people that are producing these systems to track that.

But if we go back to the car analogy, it's a bit like saying to the automakers: never mind about recalls and stuff. Here's your duty. We expect you, when you build a car, to print out a list of all the parts that went into that car and put it in the glove box. Then you're done. But we wouldn't accept that as the end of responsibility in the auto sector, and it's not going to be the endpoint of legislation here. It's a first step. It's not the final step.

What we're seeing in the legislation under discussion right now are the ideas of recall and liability.

The first thing I want to talk about is the EU Cyber Resilience Act, or CRA. You might have heard it mentioned like that. This piece of legislation is being considered. It's not law yet, but it's been discussed for a while and is marching in that direction. It says that manufacturers shall be able to take immediate corrective action to withdraw or recall a product as appropriate, or patch. If a vulnerability is disclosed, you have to be able to patch the product. If patching means you have to have the consumer mail it back or send it back for a patch, you have to do that recall.

Then in the U.S., the National Cybersecurity Strategy came out a couple of months ago, and it talks very explicitly about shifting liability, which is a huge change in how we deal with things. It says we're going to shift liability onto those who fail to take reasonable precautions. Basically, companies will be held liable when they fail to live up to the duty of care that they owe consumers, businesses, or critical infrastructure providers.

This would mean no more blanket immunity in these end-user agreements. What instead they're proposing is: we will have liability. You will be liable for problems caused by your software, but you'll have this safe harbor condition. You'll be okay, you'll be not liable again, if you're following certain best practices, certain minimum standards in terms of cybersecurity.

It shouldn't be a surprise that this is happening, because this has happened to literally every other industry that's reached a certain level of maturity. In the food and beverage industry, there was this Paisley snail case back in 1932 in England. Someone got a beer. There was a snail in that beer. They didn't notice. They drank the beer, and they got sick. The snail had tainted the beer. They sued the beer maker, and the beer maker was like, you should have checked the bottle for snails. The court said no, the consumer does not have a duty to do the inspection that the manufacturer should be doing. This beverage manufacturer should have been inspecting their facilities. They should have been taking care to ensure that things like snails did not end up in the beer bottle.

In the auto industry, these sorts of regulations go back to 1916 at least, where an individual named MacPherson sued the Buick Motor Company. Fun fact: Buick is now known as GM, so it connects back to that first story. They were getting sued over automotive issues way back in 1916.

What happened was a wooden wheel broke and injured the vehicle occupant. They sued the automaker. The automaker said, no, we're not liable for two reasons. One is, we didn't sell you the car. You bought it from a dealer, so you don't even have a direct business relationship with us. The other reason they gave was, we didn't make the wheel. It comes from a third-party supplier. We just installed it. Go talk to them.

But the court determined, no, the vehicle manufacturer, as the one assembling the vehicle, is in the best position to test and make sure that the parts are high quality, that they're passing the standards that are expected. You can see the analogy to software. We're taking all this open source, we're taking these components, we're plugging them together, we're producing some product. It makes sense that it would be our duty to ensure that that product is up to a certain level of security.

Like I said, these regulations are coming. Now is the time to start preparing, because we've learned, I think one thing that's a general theme in a lot of the talks in this summit and previous summits, that it takes time for large organizations to change how they do things. If we're going to make the most of this opportunity, we need to start now.

In the words of Winston Churchill, we should never let a good crisis go to waste. If we're going to all start running around, freaking out over this legislation that's coming, let's make the most of it. Let's see if we can turn it into a positive.

One way to do that goes back to some research that Gene and I did a few years ago as part of the Software Supply Chain Report. We collaborated on an analysis of industry practices and what different people at different companies saw in terms of productivity and risk management or security. There were basically four groups.

There was a group of companies where security came first: slow down the process, quarterly releases are fine, whatever, we just want to examine everything and make sure there are no vulnerabilities. Then there were people who were ship-at-all-costs, move fast and break things. Then there were the companies that were not achieving either: lots of room for improvement. And then there are these high performers that are doing both. They're having good security outcomes, and they're fairly productive.

What's interesting is when you look at where these are relative to each other, you find that those high performers, the ones that are paying attention to both security and productivity, are achieving better outcomes in both dimensions than those groups that are just focused on one or the other.

Why would that be? You can imagine the security-first folks. They're trying to focus on security. They're slowing the process down to do that. But then when something like Log4j comes out, they don't have the ability to quickly release a patch. They have this process that is not geared towards really acting in a timely way to unexpected security issues, and so they're not going to achieve as high a security threshold as someone who is able to ship quickly.

Similarly, the ones who are shipping quickly but have security built into their process don't have to worry about responding to certain disclosures. If there's a vulnerability that has been patched and then gets disclosed later, they've already worked it into their workflow, versus the productivity-first crew who maybe didn't notice that they have to go back and do a special release. It interrupts their work. They have all this unplanned work due to security issues.

If we act now, if we start preparing, we can make sure that we end up in the upper-right quadrant. Use this as an opportunity to examine your processes, put tooling in place, whatever, to get into that upper-right quadrant.

Some people have said, what do I do? This legislation is still under discussion. It could change. What sort of liability is it going to be? What are the minimum standards that they're going to put in place? I feel like I can't do anything right now because we don't know exactly what we're going to be required to do.

My answer to that is: if you just do these things, if you do this self-evaluation and try to get to a yes on all of these, you will be above the bar for anything under discussion in terms of this regulation. Think about your organization. If I told you about a new vulnerability right now, could you tell me: are you even using that component? Which applications are you using it in? Can you track remediation as you go to start fixing that? Can you track that remediation across your portfolio? And how long will it take you to get to the point where you've shipped and deployed an update that fixes that?

If you can answer yes to all of those, and you have a quick timeline for the fourth bullet, then you're in a good position with respect to everything that's being discussed. Act now while there's still time. Make the most of a potential crisis. Think back to GDPR in terms of guidance. Remember how much of a fire drill that was? We had two years from release of that legislation to when it went into effect. We potentially have more time if we start acting on this quickly, now when we see it coming. Thank you.