What are the Key Changes in Software Liability

A summary of key changes in software liability today

Liability law is shifting for organizations that deliver software products, especially in cases where those products manage or touch customer data.

Until recently, customer agreements (End User License Agreements (EULAs), subscription agreements, terms of service, etc.) once provided a buffer against liability to customers for data breaches and other data-related risks. However, this is changing as well.

According to the 2023 Annual Litigation Survey produced by Norton Rose Fulbright, 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.

Looking at changes in caselaw worldwide, we can also see this evolution taking place. There has been a clear move from the privity of contract, which essentially limited a consumer's protection, to algebraic formulas now used to determine an organization's burden concerning the standard of care and duty of care.

For a more modern understanding of this shift, we need to look no further than current protections associated with consumer data. With precedents set by large fines, leveraged by the stipulations of legislation like GDPR, the impact of responsibility placed on these organizations is growing faster than nearly any other area of liability.

And this is a trend that is continuing. The government is increasingly moving towards wider legislation not just to protect consumer data but national infrastructure and assets as well.

In the wake of the NotPetya attack against Ukraine and the Solarwinds hack in the US, governments are moving swiftly. Both an Executive Order in the US and a Cyber Resiliency Act in the European Union represent a foundation for change to come.

Worse, there is a discussion of insolvency related to insurance to protect against these events. This can be attributed to the increased cost of fines and the more catastrophic potential of attacks.

All of this makes it a priority for organizations to understand software liability and the changing impact it will have.

How do new liability regulations affect my organization?

Liability for organizations that produce software is changing.

Because of this, it's important to understand how these changes impact your business and the necessary due diligence your development teams and organization need to take.

As we've spoken about in our blog, the evolving landscape of software supply chain attacks has reached a critical stage. In response, governments worldwide have started taking notice and increasingly turning towards businesses to place responsibility for protecting public data.

For a time, businesses have relied heavily on customer agreements (end user license agreements, or EULAs, subscription agreements, terms of service, etc.) to limit their liability to customers for data breaches and other data-related risks. Whether caused by negligence or direct hacking attempts, customer agreements can provide potential padding, especially for large organizations, when navigating liability.

However, as regulators become more active in enforcement matters, customer agreements are losing their ability to limit organizations for data-related liability. Customer agreements may limit liability between the provider and the customer, but they do not reduce a provider's exposure to government regulators. Looking at the current total of collected GDPR fines (as of 2023, measured in multiple billions), it is clear modern legislation is attempting to send a message to organizations about their responsibility to protect consumer data.

In the case of GDPR, it has global implications even if you don't do business directly in any of the member countries of the EU, as it protects citizens using systems well beyond the borders of the EU. In many ways, the reach of GDPR has created a model that other governments are also starting to follow. Even in the US, typically slower to act on heavy regulations at a federal level, states have begun to establish their protections, like the CCPA and CPRA in California, VCDPA in Virginia, CPA in Colorado, and CTDPA in Connecticut.

In recent years action to create further protections and regulations has accelerated. In the wake of continued events like SolarWinds, the Log4Shell vulnerability, and a long list of others, increased pressure on lawmakers has reached critical mass.

Similar to ensuring foundational safety regulations for transportation, governments have taken heed of a growing concern from the public.

What changed?

The growing nature of attacks that are not limited to the consequence of data loss alone. The risk associated with software vulnerabilities must now incorporate loss of life, changing the equation when attributing negligence and the accompanying cost. Additionally, governments must increasingly defend against espionage, cyber terrorism, and other bad actors.

While some will dismiss headlines or write the growing rhetoric as fear, uncertainty, and doubt, the best companies will work proactively to understand risk and liability within this new and changing context. Looking closely at executive orders and other government communications, the best businesses see an opportunity to partner and grow through education and best practices.

Over the next few sections, we’ll cover some of the things you need to know about software liability, allowing your organization to be better informed and improve today.

History of liability

While the United States may be one of the more well-known countries when discussing litigation, every part of modern society is built on a foundation of understanding the importance of liability. And this isn't something associated with the last couple hundred or so years.

Going back to ancient Rome, we can see recognition of liability as part of their code of law. They called it obligatio, which most commonly referenced an obligation or agreement between two parties, similar to what we'd consider contract law today.

Likely, liability goes back even further than this, as we see evidence in religious and other historical texts. Looking at manuscripts that span recorded history, evidence of contracts is often visible between humans, nations, and even gods.

What we can gather from this is that part of the nature of humanity is to understand where to place responsibility when something bad happens. In general, the goal is to return a person or business to its wholeness before the incident and compensate for any potential loss that the incident could impact in the future.

Given this, it would seem that determining fault is pretty straightforward. Something happens, we find the person that did it, determine if they actually did it, and then decide on a consequence.

But who's actually at fault can be difficult to isolate with the relationship isn't straightforward. And what happens when there are potentially many parties involved in a process that leads to loss? This is where it becomes less clear-cut.

To better understand, we'll look at three cases that have helped shape how we allocate liability today.

Cases that helped shape liability

Winterbottom v. Wright (England)

In 1842, Winterbottom, a contracted driver of a stagecoach contracted to deliver mail, was injured when the stagecoach collapsed. Winterbottom sued Wright, who was contracted to maintain the stagecoach by the same organization that had contracted Winterbottom to drive the stagecoach.

Winterbottom claimed that Wright had been negligent in his failure to properly maintain the stagecoach, which led to Winterbottom's injury. The court sided with the defendant because Winterbottom and Wright did not have "privity of contract." Thus, Wright had no duty of care toward Winterbottom.

This holding is orthogonal to the dominant approach today, which provides that a person may be liable for their negligence without a contract between the parties. However, for consumers of defective products in 19th century England, the focus was on the allocation of liability between parties to a specific contract In this case, because Winterbottom had not entered directly into a contract with Wright, Wright was not liable for the harm caused to Winterbottom.

MacPherson v. Buick Motor Co. (United States)

In 1916, Macpherson, an owner of a Buick Runabout, was injured when one of the car's wheels collapsed. Although the wheel was not manufactured by Buick, they had installed the part purchased from their supplier. The court decided that Buick was liable in this instance, rejecting the holding in Winterbottom v. Wright.

The ruling is considered a precursor to the modern product liability framework. The reasoning here was that if there is a reasonable basis for concluding that a product could put someone in harm, then extra steps must be taken to ensure the safety of anyone that will come into contact with the product. This should hold regardless of the contract between the parties in question. Put another way, in this case, the rule put forth is that if you build a product with parts from other suppliers, you are responsible for how those parts perform in the new product.

Donoghue v Stevenson (Scotland)

In 1928, Donaghue joined a friend at a local cafe. She ordered a Scotsman Ice Cream Float, which consists of ice cream topped with ginger beer from the bottler, D. Stevenson, Glen Lane, Paisley.

When the remaining ginger beer was poured into her glass, she saw a decomposed snail. She became ill, which included a trip to emergency service and a diagnosis of severe gastroenteritis and shock.

Up to this point, for a party to be held liable for harm caused, caselaw in Scotland required privity of contract or either intentional or unintentional trespass. Trespass is someone doing something to someone else either intentionally, like physical assault, or unintentionally, where harm transpired, but not based on a direct motive like operating a car recklessly.

In this case, neither intentional nor unintentional trespass was present. Under prior case law, Donahue would not have a case. However, the court eventually sided with Donahue on the principle of negligence. This decision set a precedent for case law in Scotland and provided a foundation for negligence in common law worldwide.

Today we would more commonly refer to negligence based on an obligation of duty of care, which informs most modern views on the importance of food safety. In harvesting, preparing, and delivering food, there is an expectation of care placed upon those involved in those operations. Here again, we see this to be true regardless of any contract or agreement that might be in place.

United States v. Carroll Towing Co. (United States)

In 1947, a barge, the Anna C, was leased to the Pennsylvania Railroad Company by Conners Marine Company and was loaded with flour owned by the United States. On the same day, the Caroll Towing Co. was contracted to remove a different barge moored to the same pier as the Anna C and several other barges. In removing the other barge, the lines to the Anna C became disconnected. This resulted in the Anna C floating into other barges and eventually sinking. As a result, the United States initiated an indemnity lawsuit against the Caroll Towing Company.

It's important to point out the complicated nature of this case, as many parties were involved. This included contracts between the Pennsylvania Railroad company and the United States, as well as contracts between Pennsylvania Railroad, Conners Marine, and Carroll Towing. Ultimately, liability was shared across these companies (including liability between them) and was decided in a court of appeals. Specifically, Carroll Towing was responsible for ensuring barges they interacted with that day were safe and secure. In this duty, they failed.

The complexity of this case led to how we more commonly view negligence today, establishing a formula for a standard of care. Judge Learned Hand wrote the following:

"Since there are occasions when every vessel will break from her moorings, and since, if she does, she becomes a menace to those about her; the owner's duty, as in other similar situations, to provide against resulting injuries is a function of three variables: (1) The probability that she will break away; (2) the gravity of the resulting injury, if she does; (3) the burden of adequate precautions. Possibly it serves to bring this notion into relief to state it in algebraic terms: if the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B < PL."

Put another way, liability exists when B < PL. In this case, placing responsible individuals aboard barges that had been interacted with during the day would have represented a burden that was less than the cost of damage to the other vessels and the cargo times the likelihood something bad would happen.

There's much more to each of these cases and additional cases that have helped inform and shape modern liability. However, what should start to stand out is that organizations have a growing responsibility. This responsibility includes a duty of care (expectation to act responsibly) and a standard of care (the level of responsibility). In the next section, we'll tie this legal history with the increasing expectations and shifting liability due to cybersecurity concerns for software organizations.

Shifting liability for software organizations

Sonatype has written extensively about the evolving nature of cybersecurity attacks on software supply chains. In the beginning, the most common approach was to exploit zero-day vulnerabilities. However, bad actors have become increasingly creative, moving to attack or trying to compromise projects directly.

Most recently, attacks include techniques such as dependency confusion, where malicious packages are inserted directly into development ecosystems. In this way, developers are directly compromised, often before they realize it or anything can be done.

This evolution represents a trend towards what was once old being new again. Today, you would be hard-pressed to find someone unfamiliar with malware. However, we more commonly identify this as an issue with someone downloading an attachment, clicking a link in a text message, or visiting a website without HTTPS.

In many ways, malware became a cliche for inexperienced Internet users, not trained software engineers. Unfortunately, that is no longer the case. The reality is that organizations developing software (which today is every large business) must defend against all the other types of attacks and these new forms as well.

What's driving increased liability?

Thinking of an attack can often be disconnected from the outcome. For most, there’s an obvious link to the loss of data. And every organization desires to keep its data safe and out of the hands of others that would use it nefariously. However, this is only part of the story.

Not all attacks aim to gain access to or expose customer data. While there are now trillions of dollars in costs associated with cybersecurity attacks, independently controlling systems integrated across a wide network of governments and private organizations is the real payoff.

Attacks that can control widely used systems have the potential for data loss, manipulation, and misuse, as well as national security implications. And this is exactly what happened to Ukraine in 2017 with NotPetya, when a popular Ukraine accounting product was compromised. To call the result devastating hardly scratches the surface of the cost and impact.

We saw this potential in the SolarWinds attack in the United States. Here, hackers targeted and gained access to internal systems that allowed them to inject their own malicious code and swap it for what should have been a routine update patch. The hacked update files were then made available to their customers. Though the true extent of loss is unknown, it was clear this attack allowed the hackers to gain access to government, public, and private organizations.

The real story here is that the defense assumes organizations are aware of the risk or, much worse, aware of an attack. In the case of NotPetya and SolarWinds, it wasn't until many months after the attacks had taken place that all the pieces came together. While there were signs, including a number of them missed, months passed, allowing the true scope of cost to remain unknown, even today.

The SolarWinds attack was not a wake-up call. That credit can be given to the destruction caused by NotPetya. However, it was a final signal to governments that more needed to be done.

Roughly a year after the SolarWinds attack, the US Executive Order on Improving the Nation's Cybersecurity was issued. While a lot is covered, from an increased focus on education to creating better communication across government organizations, it also focuses on securing software supply chains.

Matched with the US response, at the end of 2022, the European Union proposed Cyber Resiliency Act followed a little over a year after. And like the Executive Order in the US calls out the importance of protecting supply chains, "In a connected environment, a cybersecurity incident in one product can affect an entire organisation or a whole supply chain, often propagating across the borders of the internal market within a matter of minutes. This can lead to severe disruption of economic and social activities or even become life threatening."

In both cases, organizations that produce software should pay attention to the increased potential for government involvement. As more countries follow suit, foundations are laid for future regulation and greater scrutiny of responsibility.

What's the current state of liability for software organizations?

Though it is rapidly changing, organizations have often used the nuances of contract law to help protect themselves from liability. We saw this directly in Winterbottom v. Wright. And there are elements of this today in limitation of liability and disclaimer provisions in organizations' customer agreements.

This isn't necessarily nefarious as it often approaches gray areas of understanding the law regarding an acceptable risk an end user takes in using products.

At least it was a gray area.

With the EU's General Data Protection Regulation (GDPR) legislation in 2018, the significant cost associated with attacks became a reality. Between 2020 and 2023, the total value of fines rose by 23x, resulting in nearly 3 billion Euros collected. And it isn't just the cost of the fines that have increased drastically. In the same period, the number of fines increased from 168 to 1443.

GDPR represents a dramatic shift in assigning organizations responsibility to keep their users' data safe. Again we can attribute this to the shifting definition applied to the standard of care and the duty of care organizations have.

While these violations remain tethered to data security today, that definition can be broad. Considering the implication of increasing standards, options for organizations to rely on the technicalities of contract law for protection are decreasing.

Further data supports that cybersecurity events and litigation costs in these areas are also increasing. According to the 2023 Annual Litigation Survey produced by Norton Rose Fulbright, 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.

In describing specific concerns related to cybersecurity, the report offers, "Mounting data breaches, ransomware and other cyberattacks are providing ample fodder for cyber-related disputes, while a slew of new and varying state data privacy laws complicates compliance efforts. Related litigation ranges from claims of negligence and fraud to criminal prosecutions over efforts to conceal cyberattacks."

This doesn't paint a great picture for organizations charged with keeping their customers' data safe. But it hasn't even considered the liability associated with securing the software supply chain and open source components, which is nearly every organization in existence today.

What does the future hold for liability?

Up to this point, most of the conversations related to liability focused on data loss and privacy concerns. And for today, that's where a majority of the effort is focused and will continue to be.

But what is at the heart of protecting data, and what about protecting national infrastructure to prevent attacks like NotPetya?

With specific callouts to the software supply chain by the US Executive Order on Cybersecurity and the Cybersecurity Resilience Acts, there's evidence that the future of liability will be drastically different from what we understand today.

And the foundation for these decisions has likely already been established in previous case law. If we look back to MacPherson v. Buick Motor Co., we can see that the manufacturer was held liable for the failure of a part on MacPherson's automobile.

More specifically, the law established that even though a supplier provided the parts, there was a duty of care placed upon the entity that assembled the parts to test and ensure, to their best ability, the risk for the customer had been minimized.

As an example that will inform the future, we can look at a similar situation in the Log4Shell vulnerability that crippled software development teams at the end of 2021 and well into 2022. While this was mostly an exercise addressing a potential cybersecurity risk, what about organizations using a vulnerable version of Log4shell?

As custodians of The Central Repository, Sonatype can produce statistics for the consumption of open source components, including those with known vulnerabilities. As discovered and detailed in the 2022 Software Supply Chain report, organizations continued to download the vulnerable version nearly a year after the disclosure of the vulnerability.

Looking back to Donoghue v Stevenson, this situation is reminiscent of the decomposed snail in a bottle. Like Donoghue, the end user of a software product does not have the responsibility to inspect and ensure the quality of the parts used in the product they consume.

Those same customer agreements that have helped organizations limit liability may direct liability back to the organization itself. Many customer agreements prohibit an end user from inspecting the contents of the software. Recalling the formula developed as part of United States v. Carroll Towing Co., the burden of adequate precaution is one of three variables.

Put in simpler terms, the historical case law, existing regulations, and increasing government rhetoric point to a future where sole responsibility is placed on the organization to ensure the software products they produce are safe for end users. To make matters worse, another pressure has arrived: insurance insolvency.

What about cybersecurity liability insurance?

At the beginning of 2023, analysts began to raise the alarm that increased cybersecurity attacks and associated losses have pushed cybersecurity insurance costs to unsustainable levels. This also means that capital markets and the insurance industry may no longer be interested in this business area.

As to why, we can look back to the changing nature of cybersecurity attacks, especially those on critical infrastructure. For a large-scale attack impacting a vast network of different services like hospitals, police, and fire/rescue, the potential for casualties and the associated liability of the organization that produced the compromised system could represent catastrophic financial loss.

For insurers, this would most likely mean insolvency, and not unlike what is seen in states impacted by seasonal storms. In the case of Florida, which faces repeated exposure and increased loss due to hurricanes, the state government has become the insurer of last resort. This has created a dramatic rise in costs for insurance and created an environment for increased government scrutiny and regulation.

Looking to the future, much like homeowners in Florida, organizations may very well have only one option to be insured, and that option will be both very expensive and connected to the federal government. This means organizations must prepare for direct and significant financial loss if they cannot secure their supply chain.

Luckily, in contrast to natural disasters that are nearly impossible to avoid, the tools, processes, and best practices for software supply chain security have matured. Today, when these are properly deployed, you can be even more efficient. Compared to liability, the cost is negative in this context.

Key Changes in Software Liability