What is the difference between supply chain, third-party, and vendor risk management?

And how to measure the risk correctly.

I whiteboarded these concepts on YouTube.

SCRM, TPRM, and VRM are acronyms that people throw around a lot these days.

But what exactly do they mean?

On a recent LinkedIn thread with Tony Turner, I tested out my definitions of these concepts and changed my mental model slightly based on our conversation. So in this post I wanted to formalize these terms to help guide future discussions on the topic.

To be clear, I’m going to focus specifically on the cybersecurity risks related to these ideas. While there are many potential other types of risk (regulatory, operational, reputation, etc.) that organizations need to consider when dealing with other parties, I’ll focus my analysis on cybersecurity risk only.

To start, I’ll define cybersecurity risk management as the practice of determining the optimal combination of acceptance, avoidance, transference, and mitigation to address the potential occurrence of a malicious event impacting an organization’s intended data confidentiality, integrity, or availability.

Take a look at this post for a deep dive on these options.

With that definition out of the way, I’ll dive into some other

Foundational terms

First party

This is your organization and information systems it controls directly. If one of your employees (and I’ll limit the definition to include only employees) can merge code, make a configuration change, spin up or wind down a service directly, then this is a first-party asset.

First-party assets, however, can (and in almost every case, do) contain third-party code and assets themselves.

Second party

These are your customers and their information systems. They compensate you, either with money or data (as is the case with many B2C offerings) in exchange for a product or service.

Third party

These are people, organizations, and information systems with whom you have a direct relationship and on whom the confidentiality, integrity, or availability of your data relies but are not your employees or customers.

Some examples of these include:

• Contract developers who help build your application

• Open source developers whose projects you incorporate into your product

• Other software vendors your organization uses

Fourth party

Fourth parties (also known as n-parties) are the same as third parties except you do not have a direct relationship with them. For example, if you use Slack but have no direct relationship with Amazon Web Services (AWS), then AWS is fourth party. That is because Slack runs on AWS. Many people learned this the hard way when the former suffered downtime due to an outage with the latter.

With these terms spelled out, I’ll dive into the meat of the piece. I’ll begin with the most narrow discipline and work my way out from there.

A visual representation of my model:

Vendor risk management (VRM)

Vendors are third parties who vend things to you (the first party). This might sound reductive but a key piece here is that you compensate them for doing something or giving you something.

And the reason this is key to my definition is that it provides you with leverage over these parties that you would not otherwise have. While leverage varies based on a wide range of factors, the mere fact that you are compensating a vendor will generally give more control over their behavior than if you did not.

The line gets blurry when we talk about freemium offerings. That’s because use of them can be the start of a commercial relationship but, at the beginning, no money changes hands. For clarity, I will exclude management of these from the definition of VRM.

And finally, business partners can be vendors by my definition or they may not be. For example, if you a pay an organization a commission on joint sales efforts, then they are your vendor. If the relationship is reversed, then I would consider them to be your customer (they are paying you for leads or deals).

Third-party risk management (TPRM)

All vendors are third parties, but the latter category can include many organizations and assets that are not vendors.

For third parties who are not vendors, e.g. open source developers, you rely on them but don’t have as much leverage over them. Much of your risk management efforts must thus rely on some combination of asking nicely, threatening to shame them, or offering to pay them (and making them a vendor).

While all of the above may seem obvious to you, it clearly isn’t to some information security personnel at large organizations. For example, last year a major gaming company asked an open source developer to fill out a detailed security questionnaire.

The developer promptly illustrated the lack of leverage the company had over him by tweeting out his denial of the request.

Open source projects can also represent a fourth party, when your vendor uses the relevant library in their app. OpenAI customers learned about this the hard way in early 2023.

Supply chain risk management (SCRM)

The most expansive discipline of the three is supply chain risk management. This includes managing the risk not just third parties but also from second and fourth ones.

A customer - especially one of a software product - could accidentally or intentionally do something that allows a malicious actor to impact your data. For example, a customer might click on a phishing email that allows cybercriminals to gain an entry point to your network. Or a malicious insider at a customer may intentionally use your software to conduct a denial of service attack impacting your organization.

Fourth parties, even though you have no direct relationship with them, can also impact you. In addition to the Slack example, SecurityScorecard and the Cyentia Institute recently found some interesting things about forth-party risk. For the organizations they examined, half of them had over 200 fourth parties that had suffered a data breach in the last two years. This type of risk appears to be far from rare and is something that security professionals should incorporate into their calculus.

Measure risk the same way, irrespective of the relationship

It is important to understand your relationships with other organizations when deciding how best to manage the cyber risk resulting from it. With a vendor, you likely have the full suite of tools (mitigate, transfer, avoid, accept) available. For an open source project, your ability to mitigate and transfer risk will be more limited since it is difficult to exert leverage over them.

With that said, the way you measure the risk should not change based on the relationship. $100,000 of annual loss expectancy (ALE) from a vendor is identical to $100,000 of ALE from an open source project.

Oddly enough, though, many security teams create just this type of illogical dichotomy.

Processes for vetting vendors often involve exhaustive:

• Security questionnaires

• Reviews of external audit reports

• Demands for various contractual assurances

Subsequent to purchase, organizations will frequently:

• Conduct continued technical due diligence such as

  • Penetration tests

  • Application security testing

• Use security scoring tools to monitor the vendor

When vetting open source libraries, however, the same organizations often will just do a known vulnerability and license check using a software composition analysis (SCA) tool. If this happens at all, it is frequently a one-time review that occurs when the library is first merged into code.

This level of scrutiny is disproportionately low considering the risk involved. Log4shell - one of the most dangerous vulnerabilities in history - was present in an open source project for eight years before its public disclosure. I suspect that if organizations inspected the open source code they use as closely as they do their vendors, this issue would have surfaced much earlier. And if they did so, they would likely get much more “bang for their buck” in terms of supply chain risk management.

Conclusion

My goal with this post has been to create a framework for discussing the various disciplines of software supply chain risk management. I am absolutely open to refining it based on feedback from the community and look forward to making it both a living and actionable document.

And if you take anything away from this article, it would be this: understanding your relationship with other parties is important for risk management purposes but it should not impact your measurement of that risk.