Make sure your company is prepared for evolving software liability regulations

An allegory about liability

Here’s a scenario…

You launched a new product six months ago. Since the launch, your teams have already pushed several updates. It’s now the shining gem of your portfolio and the first big release since your company went public. It’s brought accolades for you and your company, and even better, it might be a career-defining moment.

You are about to step out a little early on Friday. There’s a smile building because you have plans to get out on the water and enjoy time with your family. Maybe even take out that boat you never seem to have time for.

Your phone buzzes, and instinctively you take it out. The message preview shows an urgent Slack message from the leader of your Customer Success team.

It’s unusual to get something from them, even if it’s still early on a Friday. They apologize for the message on a Friday and acknowledge they know you have plans for the weekend.

Disaster strikes

Unfortunately, one of your new product's customers claims to have evidence of their private customer data for sale on the dark web. They also believe they see information from their competitor’s customers as well.

Your heart sinks. It’s unlikely you’ll be spending any time with the family this weekend. Much less taking the boat out. It will take more than a few minutes to figure out, no matter what this is.

At first, you want to point to the customer being hacked. It’s possible someone could have stolen their login information. It’s a stretch, so you decide not to bet on it, but still worth investigating.

You take a few deep breaths to remain calm, thinking and then rationalizing that you have plans for cybersecurity intrusions. If there is an issue with your product, you should be okay.

So what’s next?

As part of your immediate response, you assemble a tactical team with members from across the organization.

DevOps and Information Security are reviewing any potential activity that seems unusual or out of the ordinary. Product and engineering dive into researching the possibility there’s an issue with the product itself. Customer Success is working to maintain the relationship and assure the customer your team takes the issue very seriously. And in case things get really bad, your legal and marketing teams are working on a public response.

It’s your worst fear: the breach wasn’t caused by compromised login information for your customer. Though unknown to you, that theme will come up shortly.

Devil in the details

DevOps and Information Security come back with evidence of subtle activity going unnoticed for months. Apparently, user names, passwords, and security keys have all been compromised. The intruders' activity looked like typical engineering work, so it passed the checks and systems you had in place. Security has found and removed the intruders' access, but the damage is done.

Further research makes it clear that no customer data has been spared. Millions of rows of data are likely now available to those that would do harm or make a profit with it. And it doesn’t stop there.

Evidence shows that the intrusion was possible via an open source framework with a known, high-severity vulnerability that your teams never patched. It just so happens this framework may be used across your organization. However, there is no tooling in place to verify at that scale. This means it will take months to understand the true impact.

The security team claims they made development aware of the issue months ago. But you’re already aware of ongoing struggles between the security and development teams. To say they don’t get along is a bit of an understatement.

How to respond?

When you ask if development implemented the recommended fix, they can’t tell you because the development team has decided to use different tooling. The new tool they chose had previously approved the use of the component since it didn’t have the vulnerability at that time. The development tool doesn’t actively check for new vulnerabilities in released products.

So far, it’s pointing to a case where every application you use is vulnerable.

You didn’t even get to eat dinner with the family on Friday. Saturday was a mix of video and cell phone calls with no resolutions. Teams are scrambling to come together but lack the processes or tools to figure out exactly what happened.

It’s early on Sunday morning. You haven’t slept, and it shows. You sign in to yet another video call.

Facing the (liability) music

As you join, the product and development leaders are already arguing with the leaders for DevOps and Security. They are pushing back on the accusations, saying that if they fixed everything passed over the fence to them from security, no new products or features would ever be produced. The typical bickering between these areas of your organization escalates into personal attacks.

You raise your voice, quieting them down like you would your children. Then you look to your legal team, hoping they can offer something. That’s why they’re here, right?

Unfortunately, the news isn’t any better there. They advise that many of the indemnity clauses in your EULA won’t protect you from something like this. They also specifically call out that customers can’t inspect the contents of your application.

They advise that since there is evidence that your teams were aware of the issue, you had a “standard of care” to maintain and a “duty of care” to protect your users and their data. They add that since some data includes customers in the European Union, you’ll be subject to GDPR fines and regulations. The legal team predicts this will become a very public story, and the recommended course of action is to prepare for a public response.

As you digest everything they’ve said, you realize this will most likely mean litigation and government insight.

You stare out the window of your home office and into the reality of the future you are about to embark on…

From fiction to reality

This sounds like fiction, but it’s not. These exact things have already happened. In many ways, it’s ripped from the headlines.

Making matters worse for organizations, there’s a real change concerning the legal status of responsibility and liability for assembling software with low-quality parts.

But where are these changes coming from, what will liability for organizations look like in the future, and why is the government becoming increasingly involved?

That answer is complicated, and we’ve written a piece that takes a much deeper look than we’ll provide in this blog.

In short, it’s twofold.

Changes to case law

First, case law has been evolving as it relates to the responsibility of end users and customers of products for almost 200 years.

From precedents that once focused on requiring a specific contract between two parties to rulings that it is not within reasonable expectation for end users of products to inspect the quality or safety of those products.

Two specific cases represent the most relevant changes to those that would impact organizations that produce software or manage customer data.

In MacPherson v. Buick Motor Co., a man is injured when the wheel of his automobile fails. The wheel was provided by a supplier to the Buick Motor Company, but the ruling identifies it is the responsibility of the automobile manufacturer to take extra precautions. In other words, companies must ensure the parts they install are of high quality and safe for the consumer.

In another case, Donoghue v Stevenson, a customer finds a decomposed snail in a bottle of ginger beer. This leads to a diagnosis of severe gastroenteritis and shock. The customer sued the bottling company, and the ruling was that it was not reasonable to expect the customer to inspect the quality or contents of the bottle.

Perhaps the best modern example of how these cases have informed modern liability is to look at GDPR. For organizations that store, manage, or touch personal data, GDPR established rights for end users that are still shaping the world today.

Based on past cases, we know GDPR has reached beyond the European Union (EU) borders. Given the non-trivial fines associated with violations (to date hundreds of billions of Euros), we can also attribute the power and impact of GDPR to governments leaning in to protect citizens. More specifically, these actions were taken because organizations were not self-regulating or conducting business with the customers’ best interests in mind.

Increased cyberattacks lead to greater regulation

The second shift can be attributed to the evolution of attacks on software supply chains. In a recent blog post, we covered this exclusively. While attackers started with a focus on zero-day vulnerabilities (what we see in our story above), they have shifted the direction of attacks to development infrastructure and even the developers themselves.

In the wake of NotPetya, which crippled Ukraine and the SolarWinds attacks, the US government has taken an aggressive stance. Showing their cards with the Executive Order on Cybersecurity in 2021, they laid out a myriad of requirements. Among those is a specific callout for organizations to secure their supply chains.

We see similar potential for regulation around the world as well. In legislation like the Cyber Resilience Act proposed in the EU in September of 2022, there are even deeper dives into what’s expected, specifically calling out open source and how it should be managed. Using GDPR as a precursor, this will likely have reached well beyond the EU.

All of these point to organizations being held increasingly liable for cybersecurity incidents. While those have predominantly been related to cybersecurity data intrusion, products will be increasingly held to a higher standard based on what we see happening at the government level.

Again, we’ve written a detailed piece on liability for the Sonatype Launchpad. It covers:

Additional case law examples
Calculation of liability burden
Standard of care
Duty of care
… and more

Check it out to better understand liability's past, present, and future.

What about cybersecurity insurance?

This is a case of only seeing the tip of the iceberg. With regard to organizational liability, the future looks even bleaker.

Regarding litigation, according to the 2023 Annual Litigation Survey produced by Norton Rose Fullbright, 33% of those surveyed indicated litigation was associated with cybersecurity, data protection, and data privacy. In addition, 42% also gave acknowledgment as one of the biggest concerns for litigation in 2023.

We can translate this to mean even greater losses are expected this year. This is becoming one of the major, if not most concerning, items for legal teams serving organizations charged with storing, managing, and protecting consumer data.

To date, insurance has played a role in helping reduce the financial burden of cybersecurity litigation. However, that may not be something organizations can depend on.

At the end of last year, Computer Weekly reported that due to the increasing size and nature of cybersecurity attacks, insurance to protect organizations from these types of losses might not be around for much longer.

In the interview, a risk management leader in Europe, Carolina Klint, stated, “There is a real risk that cyber-attacks may be targeted at critical infrastructure, health care, and public institutions. And that would have dramatic ramifications in terms of stability.”

Fixing this today

How could the main character in our story manage this better?

In truth, it isn’t the responsibility of one individual in an organization to elicit change. The organization needs to be working together to understand, identify, and minimize risks to the security of its software supply chain.

However, poor dependency management practices are at the core of the situation in our tale. This led to even poorer management of the organization’s software supply chain.

Like many organizations, our fictional company had not moved fast enough in the wake of events like the SolarWinds attack and the log4shell vulnerability. Given this, it’s not unwarranted to highlight the recklessness of not understanding the impact that improper and ignored dependency management practices can lead to attacks that leak consumer data or have other broad impacts.

Building better protections for software supply chains

In our scenario, everyone was left to make their own decision on the tool. This isn’t much different than letting everyone in a car decide whether or not they want to wear a seatbelt.

Tooling and processes have matured to the point where, when properly deployed, you can be even more efficient.

While this may initially appear as a cost to the organization, that cost is arguably removed. Instead, you’ll see a return on that investment compared to potentially catastrophic losses. And this is why governments are leaning in more heavily today. They see it as negligent not to take basic steps to secure your software supply chain.

Added to this, the days of being able to use contract law to disclaim all liability are likely coming to an end. We can see this directly as case law has evolved, shifting to apply more completely to protecting end users. Today a shift has occurred. We attribute this shift to the arrival at a point where evolving case law applies more completely to protecting end users. And where customer agreements (like EULAs) formerly provided indemnity clauses, they also often prevent those same end users from any due diligence of inspecting the safety of the components used in the product they purchased.

What you can do about vulnerabilities today

What’s most concerning about our fictional story (again, not far from reality) is that this scenario could have been avoided with two key steps:

Step 1 - Know what components are in what applications. In this example, the vulnerability was known and of high severity. You might be thinking, that’s unlikely. But in our research last year, we found that organizations were still downloading vulnerable versions nearly a year after the log4shell announcement.

Step 2 - Implement tooling that lets you know about newly discovered vulnerabilities and immediately understands where the impact is and how to fix it. Sadly, if our story goes further, it’s very likely that the vulnerable framework isn’t the only issue. Modern tooling means you don’t have to query 4,000 project owners, asking them if they use a specific version of the Log4j framework. You know, and they know at the same time.

Sonatype provides tools that work across your organization to bridge gaps and allow communication of factual information to reduce and minimize risk.

Reach out to us today, we’d love to help you avoid the same fate as the one described above and, in reality, many organizations today.

In the meantime, you can broaden your understanding in several areas through other content provided by Sonatype’s Launchpad. Here are a few we recommend to pair nicely with this article:

We also recommend these blog posts:

Shifting Nature of Open Source Attacks (Part 1, Part 2, and Part 3)
EU Cyber Resilience Act: Good for Software Supply Chain Security, Bad for Open Source?

Editor’s note: This article was co-written by Jeff Wayman. Read more about open source from Jeff, or connect with him on LinkedIn.

You can read more from Jeff here or connect with him on LinkedIn.