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:
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.)
Understanding these terms will help you navigate discussions about third-party liability:
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.
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.
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.
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.
[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.
The push for third-party liability is reflected in various global standards and regulations:
These and other regulations signal a global shift toward holding companies responsible for the entire lifecycle of their software, including third-party elements.
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:
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.
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.
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.
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:
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.
Stay ahead of third-party liability laws with Finite State. Book a demo today to safeguard your code, your customers, and your business.