You can harden every server you own and still be breached through a payroll provider, a file-transfer tool, or an open-source library three dependencies deep that nobody on your team has ever read. Third-party and supply-chain security risk is the danger that arrives through the organisations and code you rely on but do not control, and it has quietly become one of the most common ways in.

The quick version

  • Third-party risk is exposure created by the outside parties you depend on, vendors, contractors, cloud providers, the software you install. You inherit a slice of their security whether you asked to or not.
  • Supply-chain risk is the same idea aimed at the things you build and run: a compromised software component, a tampered update, a dependency buried inside another dependency.
  • It is not a fringe threat. In Verizon's 2025 breach report, the share of breaches involving a third party doubled to 30%, roughly one in three.
  • The trap is treating this as a one-off questionnaire at procurement time. Vendors change, code changes, attackers move, so the work is continuous, and it starts with knowing what you actually depend on.

The idea in depth

The uncomfortable premise is that your attack surface no longer ends at your own perimeter. Every supplier with a login, an API key, or code running inside your product is part of how you can be reached. The clearest case is the SolarWinds compromise disclosed in December 2020: attackers slipped malicious code into a legitimate, signed update of the Orion network-monitoring product. Around 18,000 organisations installed the trojanised update, and a smaller set, including US federal agencies and major technology firms, were then actively targeted. None of those 18,000 were careless about their own systems. They were undone by a supplier they trusted.

So the first move is the least glamorous and the most important: know what you depend on. You cannot manage risk in a vendor or a component you have never inventoried. Before the next audit, build a single list of the third parties that touch your data or your production systems, and rank them by blast radius, what would break, and what would leak, if each one were breached tomorrow. Most teams discover the list is both longer and stranger than anyone assumed.

An honest limitation. An inventory tells you who you depend on, not how secure they are. A signed vendor questionnaire is a snapshot of what someone claimed on one day, and SolarWinds proves that even a reputable, certified supplier can become the vector. Knowing your dependencies narrows the problem; it does not solve it. That is why the frameworks below treat this as ongoing risk management, not a gate you pass once.

The framework that names the work: NIST C-SCRM

The most widely cited playbook for this is the US National Institute of Standards and Technology's Special Publication 800-161, Revision 1, "Cybersecurity Supply Chain Risk Management (C-SCRM) Practices for Systems and Organizations" (updated 2022). Its core argument is structural: supply-chain risk has to be managed at every level of the organisation at once, enterprise strategy, the mission or business process, and the individual system, and across the full lifecycle of a product, from how you choose a supplier to how you eventually retire what they gave you. It is deliberately not a checklist. It is a way of making the risk somebody's explicit job rather than an assumption that "procurement probably handled it."

flowchart TD
  A(["Enterprise level
strategy, risk appetite, policy"]) --> B(["Mission / process level
which suppliers matter, to what"])
  B --> C(["System level
controls on each integration"])
  C --> D(["Lifecycle
select → onboard → monitor → offboard"])
  D -.->|"reassess as vendors
and threats change"| B
NIST C-SCRM treats supplier risk as a multi-level, continuous discipline, not a one-time procurement gate. Leaders Loop

The practical translation is to put a name against each tier. Someone owns the policy ("we do not give production data access without X"), someone owns the supplier shortlist for a given business process, and someone owns the controls on each live integration. The practical entry point most teams skip is the last stage of the lifecycle: offboarding. Revoke the API keys and accounts of vendors you no longer use this quarter. Dormant third-party credentials are a standing door, and nobody is watching it.

The scale is not theoretical. Verizon's 2025 Data Breach Investigations Report, from a review of more than 22,000 incidents, found the share of breaches involving a third party doubled year on year, from 15% to 30%. The same report flagged a related habit: when credentials leaked in a third-party code repository, the median time to fix them was 94 days. Three months is a long time to leave a key under the mat.

You don't get to choose your suppliers' security posture, but you do choose how much depends on it.

Knowing what's inside: SBOMs and the software supply chain

Third-party risk is partly about organisations, but modern software adds a second layer: the components inside what you ship. A single application can pull in hundreds of open-source libraries, each pulling in more. When a flaw appears in one of them, the Log4j vulnerability of December 2021 is the canonical scare, the first question every leader asks is, "Are we using it, and where?" Most organisations could not answer quickly, because no one had a list of ingredients.

That list of ingredients is a Software Bill of Materials (SBOM): as the US Cybersecurity and Infrastructure Security Agency puts it, "a formal record containing the details and supply chain relationships of various components used in building software" (see CISA's 2025 Minimum Elements for an SBOM, issued for public comment in 2025, building on the 2021 NTIA baseline). The point of an SBOM is brutally simple: when the next Log4j lands, you grep your inventory instead of guessing. The MOVEit file-transfer attacks of 2023, where a single flaw in one product cascaded into thousands of downstream organisations via the data those organisations held, are the cost of not being able to answer that question fast.

flowchart LR
  A(["New vulnerability
disclosed (e.g. Log4j)"]) --> B{"Do we have
an SBOM?"}
  B -->|"No"| C(["Days of manual hunting,
uncertain coverage"])
  B -->|"Yes"| D(["Search the inventory,
find every affected build"])
  D --> E(["Patch the known set,
verify, move on"])
An SBOM turns "are we exposed?" from a frantic guess into a database query. Leaders Loop

If you build or ship software, the action is to require an SBOM, from your own build pipeline and from the vendors whose software you embed, and to make someone responsible for checking it against new advisories. You don't need a perfect programme to start. Even an imperfect, machine-readable list of components beats the all-too-common alternative of finding out you were exposed when a customer or a regulator tells you.

A worked example

Take a mid-sized retailer, call it Harbour & Co. (Illustrative scenario throughout; not a real company or breach.) Harbour runs its own e-commerce platform competently: patched servers, multi-factor logins, a tidy internal security team. It also uses a third-party live-chat widget on every product page, because the support team likes it and it took ten minutes to install.

That widget loads JavaScript from the vendor's servers directly into the checkout flow. One day the vendor is compromised, and the attacker modifies the widget's script to skim card numbers as customers type them. Harbour's own systems are never touched. Its firewalls log nothing unusual. The breach is happening in code Harbour's customers' browsers run, served by a supplier Harbour never security-reviewed because "it's just a chat box."

Run Harbour through the lens of this Toolkit and the failures are obvious in hindsight: the widget never made it onto a dependency inventory, and nobody had assessed its blast radius, even though it could execute code on the checkout page, the highest-stakes place on the site. The fix is not exotic. Inventory every third party that executes code or holds data; rank the chat widget as high-risk precisely because of where it runs; and apply a basic control, a content-security policy and subresource-integrity check, so a tampered script simply fails to load. The lesson generalises past chat widgets: the danger is rarely the systems you scrutinise. It is the convenient ones you waved through.

Frequently asked questions

What's the difference between third-party risk and supply-chain risk?

They overlap heavily. Third-party risk is the broader idea, any outside party you depend on (a vendor, a contractor, a cloud host) can expose you. Supply-chain risk usually narrows that to the things flowing into what you build and operate: software components, updates, hardware, and the suppliers of suppliers you may not even know about. In practice you manage them together, because a malicious software update (supply chain) usually arrives from a vendor (third party).

We're small, does this really apply to us?

Yes, and arguably more so. Smaller organisations lean harder on third-party tools precisely because they can't build everything in-house, so a larger share of their attack surface is borrowed. You don't need a formal C-SCRM programme. You need a list of who can touch your data, a sense of which ones would hurt most, and the discipline to remove access you no longer use. That is hours of work, not a department.

Isn't a vendor security questionnaire enough?

It's a start, not an answer. A questionnaire captures what a supplier claims at one moment; it doesn't tell you what they'll be like in eighteen months, and it can't catch a supplier who is breached through no fault of their own. Treat it as one input alongside continuous basics: least-privilege access, monitoring of what vendors actually do in your systems, and prompt offboarding. The goal is to limit how much depends on any single supplier being perfect.

What is an SBOM and do we need one?

A Software Bill of Materials is a structured list of the components inside a piece of software, its ingredients label. If you build or ship software, you benefit directly: when a new vulnerability lands, an SBOM lets you find every affected build in minutes instead of days. Even if you only buy software, asking vendors for one is a reasonable, increasingly standard request that signals you expect them to know what's in their own product.

Where should a leader start if they've done none of this?

With an inventory, not a tool purchase. List every third party that touches your data or runs in your production systems, rank them by what breaks if they're breached, and start applying tighter controls and reviews to the top of that list. From there, name an owner so the work continues after you've moved on to the next fire. Software and vendor relationships drift; the inventory only stays useful if someone keeps it alive.

Related in the Toolkit

Supplier risk doesn't sit alone, it's an applied case of threat modelling (asking "how could this go wrong, and through whom?"), and the single highest-leverage control over a third party is usually who can access what. Both are the natural next reads.

Where to go next