Regulation

The Executive’s Guide to Third-Party Liability in Cyber Security Law

6 min read

Aug 21, 2024 7:37:56 PM

As cybercrime becomes increasingly sophisticated, governments worldwide are introducing initiatives to hold industries accountable for their data security, including vulnerabilities stemming from third-party sources. This shift means software companies and regulated industries must now grapple with the implications of third-party liability.

In this guide, we’ll explore what third-party liability is, why it matters, and how to prepare for upcoming legal requirements.

In this article:

What is third-party liability in software?
The regulatory gap: how third-party liability became so important
Emerging Global Standards and Regulations
Third-party liability in cyber security law
How to prepare for third-party liability laws

What is third-party liability in software?

Third-party liability refers to a company’s responsibility to keep their data and their user’s data secure from any vulnerabilities—including vulnerabilities introduced by third-party code. (Most software companies integrate libraries from third-party sources in their offerings. If a third-party library becomes vulnerable to cybersecurity threats, the company is liable for any resulting breaches. This extends to any harm caused to their users, clients, or partners.)

Key terms to know when discussing third-party liability

Understanding these terms will help you navigate discussions about third-party liability:

Third-party vulnerabilities: Specific vulnerabilities introduced by external code or services.
Software supply chain: All elements involved in creating and delivering a software product, including hardware, open- and closed-source code, operating systems, consultants, and testing tools.
Software bill of materials (SBOM): A comprehensive list of all software components that make up a software system, including code from vendors and open-source libraries.

The regulatory gap: How third-party liability became so important

The rise of third-party liability stems from the widening regulatory gap between software companies and industries that play an established, essential role in societies’ infrastructure.

How the world came to rely on (unregulated) tech companies

By the 1990s, critical sectors like finance, transportation, energy, and healthcare were already subject to stringent regulations. This regulation prevented any one regulated company from growing to the point of global scale. (For example, there is no worldwide consumer bank.) As a result, innovations happened on a smaller scale, and regulators were, for the most part, able to keep pace with those innovations.

The rise of the internet led to increasing global demand for software services, with consumers and organizations of all sizes relying on tech companies for commerce, navigation, communication, and more. Consequently, the tech sector exploded, expanding and innovating quickly — and did so largely unregulated.

Innovation relied on third-party code

As software capabilities expanded, more and more tech companies began building applications on code libraries written by outside sources to innovate efficiently and competitively. Today, most commercial software applications are built on a mix of proprietary in-house code and third-party libraries—much of which is open-source.

For example, an e-commerce marketplace in Spain could license a transaction processing system from a US fintech startup, which might include code libraries produced by companies in Mexico, Norway, Singapore, and Germany—or even open-source code with no single identifiable author. (And each contributing company could have built their code on even more third-party libraries.)

Since none of these companies were regulated, any cyber security standards were either set by the buyers or self-imposed. This became especially problematic as highly regulated corporations and government entities began using unregulated applications.

Third-party code became an easy target for cybercriminals

Hackers quickly realized that breaching a large enterprise directly was challenging, but infiltrating a smaller third-party supplier could provide access to a wealth of sensitive data, creating a “back door” to the supplier’s customers, clients, and partners.

After all, a system is only as secure as its weakest component.

Attacks-by-Year
[Source: Usenix]

This was a known issue in the software community for a long time, but in 2021, it became a matter of national security in the United States following the now-infamous SolarWinds attack.

In 2020, presumed Russian hackers gained access to an IT monitoring system created by SolarWinds, a third-party supplier to large companies, including Microsoft, Cisco, and Intel, as well as US federal departments, including Homeland Security, State, and Treasury. Through SolarWinds, the hackers gained access to more than 18,000 organizations’ data—and the breach wasn’t discovered until the spring of 2021.

This was not an isolated incident. Third-party software supply chain attacks have been increasing exponentially in the past few years, leading governments to make laws regarding third-party liability.

Emerging Global Standards and Regulations

The push for third-party liability is reflected in various global standards and regulations:

EU Cyber Resilience Act (CRA): Imposes stricter cybersecurity requirements on manufacturers of digital products, including liability for third-party components.
NIS2 Directive: Expands the scope of the EU’s cybersecurity laws to include a broader range of industries and holds companies accountable for supply chain security.
U.S. Executive Order 14028: Mandates federal agencies and their suppliers to adhere to stricter cybersecurity practices, including the use of SBOMs.

These and other regulations signal a global shift toward holding companies responsible for the entire lifecycle of their software, including third-party elements.

Third-party liability in cyber security law

Governments are increasingly focusing on holding companies accountable for the security of their applications, including third-party components. Third-party liability legislation generally falls into two approaches:

the prescriptive approach
the principled approach

The Prescriptive Approach: Rule-Based Compliance

Governments taking a prescriptive approach to software supply chain security (like the United States) set compliance standards for key industries. Companies must ensure their vendors meet these standards and establish procedures for addressing breaches.

Advantages: Clear standards make it easier for companies to ensure compliance and choose compliant vendors.

Disadvantages: Regulations can become outdated and take a long time to update, leaving companies burdened with costly, outdated compliance standards that don’t actually protect them from threats.

The Principled Approach: Outcome-Based Accountability

Governments taking a principled approach (like Germany) instead leave compliance standards up to the software companies—but penalize them heavily for any breaches. Regulated companies and government agencies are held to the standard of perfection: if you’re hacked, it’s because you weren’t secure enough.

Advantages: This approach encourages innovation and vigilance, as companies must constantly adapt to emerging threats.

Disadvantages: The lack of clear standards can make it difficult for companies to assess vendor compliance and protect themselves.

How to prepare for third-party liability laws

As governments advance cybersecurity policies, companies must invest in tools and practices to stay compliant. Proactive steps are essential whether you're a software vendor or a regulated client — and even if you’re not operating in a regulated space, protecting yourself (and your users, customers, and partners) from third-party vulnerabilities is still strongly advised.

How to prepare as a vendor

Implement a Software Composition Analysis (SCA) Solution: An SCA tool like Finite State can scan your codebase and third-party libraries for vulnerabilities, ensuring your software is secure.
Maintain an Accurate SBOM: Regularly update your SBOM to include all components in your software. Future contracts will likely require detailed SBOMs as proof of compliance.
Adopt Secure Coding Practices: Integrate security throughout your development process to minimize vulnerabilities, especially in third-party components.

How to prepare as a regulated client

If you are in a regulated industry, third-party liability laws will put the onus on you to ensure that your vendors use proper data security. To protect yourself and your stakeholders, you will need to do three things:

Demand SBOMs from Vendors: Ensure every vendor provides a comprehensive SBOM for their software. This transparency is crucial for assessing potential risks.
Analyze Vendor SBOMs: Use SCA tools to evaluate the security of third-party components. This is particularly important under principled liability approaches, where you may be held accountable for breaches.
Establish Third-Party Risk Management Programs: Develop processes for evaluating and monitoring your vendors' security and supply chains.

Analyzing vendor SBOMs can be a complex and challenging task, especially since it requires scrutinizing another organization’s code. This is where an advanced SCA solution like Finite State makes a significant difference.

Finite State empowers you to analyze any SBOM for vulnerabilities, even without direct access to the vendor's code. You can also use Finite State to verify the SBOMs provided by your vendors—our reputation for generating SBOMs that are more thorough and accurate than those created in-house is unmatched. This provides you with a dependable method to assess the true security posture of your vendors.