As cybercrime becomes more sophisticated, governments have begun introducing initiatives to hold regulated industries accountable for their data security. This includes initiatives involving third-party liability, where software companies are held responsible for vulnerabilities that come from external sources.
This is an important issue for both software providers and regulated companies using third-party software. Here, you’ll get an overview of what third-party liability is, why it matters, and what you can do to prepare for third-party liability laws.
In this article:
1. What is third-party liability in software?
2. The regulatory gap: how third-party liability became so important
3. Third-party liability in cyber security law
4. 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 users’ data secure from any vulnerabilities—including vulnerabilities introduced by code from third parties.
Most software companies incorporate libraries from third-party sources in their offerings. If one of these third-party libraries becomes vulnerable to cybersecurity threats at any time, the company is still liable for any breaches of their own data.
Key terms to know when discussing third-party liability
If your company is discussing cybersecurity, odds are good that third-party liability will come up. The following terms are often used in conversations about this matter:
Third-party vulnerabilities: these are the specific vulnerabilities introduced by third-party code.
Software supply chain: this refers to all the elements that go into creating and delivering your software product. This can include hardware, open- and closed-source code, operating systems, consultants, and testing tools. It’s everything that touches your application as it’s being made, and everything that touches those things, and everything that touches those things, and so on.
Software bill of materials (SBOM): this refers to the full list of libraries that make up a software system, including code from vendors and open-source libraries. This terminology is more often used in discussions of cyber security policy and legislation.
The regulatory gap: how third-party liability became so important
Third-party liability became an important issue due to the extreme regulatory gap between software companies and industries that play an established, essential role in societies’ infrastructure.
The world came to rely on (unregulated) tech companies
In the 1990s, industries like finance, transportation, energy, and healthcare had already cemented themselves into the infrastructure of society. These industries were vital to the average citizen’s daily life as well as economies as a whole; therefore, governing bodies heavily regulated them.
This regulation prevented any one regulated company from growing to the point of global scale. (For example, there is no worldwide consumer bank.) This meant that innovations happened on a smaller scale, and regulators were, for the most part, able to keep in step with those innovations.
However, the internet and ubiquitous use of personal computers (and later smartphones and other smart devices) led to increasing global demand for software services. When the tech industry began, software applications were not regulated. Tech companies multiplied and innovated, and the capabilities of software increased exponentially.
In a matter of decades, software applications have become a crucial part of everyday life worldwide. Consumers relied on large tech companies for commerce, navigation, and communication—but so did small and mid-size businesses, enterprise corporations, and even government entities.
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. This was essential to economic survival. In order to innovate efficiently and competitively, tech companies couldn’t start from scratch. 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.
These third-party providers were also unregulated. An ecommerce 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 when highly regulated corporations and government entities began using unregulated applications.
Third-party code became an easy target for cybercriminals
A system is only as secure as its weakest component. Breaching an enterprise application is difficult, and malevolent hackers soon realized that it was much easier to breach a large entity’s data by simply targeting code produced by smaller players. Hacking a third-party software supplier created a “back door” to the supplier’s customers, clients, and partners.
[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.
In 2020, presumed Russian hackers gained access to an IT monitoring system created by SolarWinds. SolarWinds was 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—and it’s leading governments to make laws regarding third-party liability.
Third-party liability in cyber security law
Because of the growing threat of third-party attacks, governments have begun forming policies to hold companies accountable for the security of their applications—including the security of their third-party suppliers.
Third-party liability policy can be thought of as a spectrum across two general approaches, the prescriptive approach and the principled approach.
The prescriptive approach: focus on the rules
Governments taking a prescriptive approach to software supply chain security (like the United States) set compliance standards for key industries. Regulated companies and government entities are required to hold all vendors to a known set of security standards. Procedures are likewise set in place for when these standards are breached.
The advantage of this approach is that both regulated customers and their vendors know if they are compliant and what to do if suddenly they’re not (i.e., they’ve been hacked). This makes it easier for vendors to become compliant and easier for customers to determine which vendors are eligible for consideration.
However, this approach has a major disadvantage: reality moves faster than regulations. The measures a government prescribes can become obsolete, and changing regulatory standards takes time. This lag effect can burden industries with (expensive) outdated compliance standards that don’t actually protect them from threats.
The principled approach: focus on the results
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.
The disadvantage with this approach is that there is no clear-cut compliance standard (aside from being unbreachable). This makes it more difficult for regulated customers to source innovative vendors. Likewise, vendors lack clear security standards to meet in order to know if they are eligible, let alone a competitive solution.
On the other hand, this approach has the advantage of incentivising both third-party vendors and regulated entities to innovate at the speed of malevolent hackers. By raising the stakes of failure, principled policies encourage regulated entities to make absolutely sure that their suppliers and their suppliers’ suppliers are secure.
How to prepare for third-party liability laws
As governments begin exploring cyber security policies, software vendors and regulated clients need to invest in tools and practices that will keep them compliant. And even if you’re not operating in a regulated space, protecting yourself (and your users, customers, and partners) from third-party vulnerabilities is a smart idea.
How to prepare as a vendor
If you create software, you need to ensure that both your own code and your third-party code are vulnerability-free. You can do this with a software composition analysis (SCA) solution like MergeBase. An SCA solution analyzes every library that touches your final product and alerts you of any vulnerabilities.
In addition, you should begin the practice of preparing your software bill of materials for every contract. Future contracts in regulated spaces will depend on your ability to provide up-to-date information about where your code comes from, so it’s wise to begin preparing for this now.
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 are using proper data security. In order to protect yourself and your stakeholders, you will need to do two things:
- Obtain a software bill of materials from every vendor. You need to know exactly what code is being used for each contract. This is not always easy to do. Your vendors may not have a one-size-fits-all SBOM for every contract—and they may not have internally prepared their SBOMs for external viewing.
- Analyze every vendor’s SBOM. In addition to obtaining the vendors’ SBOMs, you need to analyze them for vulnerabilities yourself. (This is especially key if you are operating under laws that take the principled approach discussed earlier.)
Both of these can be very difficult to do because they involve inspecting another organization’s code. This is why using an advanced SCA suite like MergeBase is a good idea. MergeBase allows you to analyze anyone’s SBOM for vulnerabilities, even if you do not have direct access to their code. (You can even use MergeBase to verify the SBOMs your vendors give you—we have a reputation for generating SBOMs that are even more thorough and accurate than those a vendor creates in-house.)
It’s a reliable way to know exactly how secure a vendor is.
Don’t let third-party liability catch you off guard
Third-party liability laws are coming, and whether you’re a software producer or customer, the best thing to do now is prepared. MergeBase gives you the ability to find vulnerabilities in your own code as well as code from suppliers and vendors—which helps protect you from third-party liabilities.
If you want to prepare for third-party liability laws, we would love to show you how MergeBase can help. Book a demo with us today and see how you can protect yourself, your code, and your customers.
