Managing Third-Party Cyber Risks in Complex Supply Chains

Big breaches often start somewhere boring. A refrigeration contractor with remote access to the network (Target, 2013). A file-transfer tool nobody on the security team had thought about in years (MOVEit, 2023). A compression library buried four layers deep in a Linux distro. Meanwhile most vendor reviews still run on an Excel questionnaire that gets filled in once, filed and forgotten, and attackers know that perfectly well.

Why the Excel Questionnaire Doesn't Protect Anyone

Think about how a typical security questionnaire actually gets answered. Somebody on the vendor side, often a presales engineer with a deadline, opens a 250-row spreadsheet, copies most of the answers from last year's version and ticks "Yes" next to encryption at rest. The file goes back to procurement. The vendor gets approved, and the next time anyone looks at it is the renewal, usually a year or two later.

During that year the vendor might push a dozen releases, sign up with a new hosting provider and open a partner API to the internet. None of it shows up anywhere. Companies with a lot to lose figured this out a while ago, and the yearly review has been sliding into irrelevance ever since. Large enterprises, especially the ones worried about data walking out through contractor integrations, about passing strict audit baselines, about NIS2 and DORA, now plug https://dxc.com/solutions/cybersecurity/cybersecurity-risk-management-and-compliance into their daily operations, usually alongside a couple of other vendors' tools, and look at supplier risk every week. Not once per renewal.

Verizon's 2025 DBIR puts a number on it: a third party showed up in 30% of breaches. The year before it was around 15%. Is that still a number a CISO can treat as a procurement issue?

Where the questionnaire typically lets security teams down:

• the answers are self-reported, and nobody checks them against what's actually exposed on the vendor's side
• a SOC 2 Type II report describes a period that ended months ago, often six to twelve months before it reaches the reviewer
• subprocessors, cloud hosts and open-source dependencies (the fourth parties) aren't in scope at all
• a catering supplier and a core banking platform get the exact same set of questions

Where the Risk Actually Sits

Code From People Nobody Has Met

Everyone still brings up SolarWinds. Fair enough. Back in 2020 somebody got inside the Orion build system and slipped the Sunburst backdoor into an update that SolarWinds signed with its own certificate. Why would anyone question that? About 18,000 customers didn't. They just installed it. Log4Shell (CVE-2021-44228) hit a year later from a totally different angle. The patch came out quickly. Finding every application that bundled Log4j took many teams weeks, and some were still finding copies months later.

Then in March 2024 came xz Utils. Someone using the name "Jia Tan" had spent about two years contributing to the project, gradually got maintainer rights and then shipped a backdoor targeting SSH on several Linux distributions. Andres Freund, a Microsoft engineer, caught it because SSH logins on his test machine were running around 500 milliseconds slow and he went digging. Without that bit of curiosity it could have reached stable releases.

An SBOM (Software Bill of Materials) won't stop that kind of attack. What it does is make the question "do we run this anywhere?" answerable. It's a machine-readable list of the components in a product, usually in SPDX or CycloneDX format, and Executive Order 14028 made it a federal procurement expectation in the US back in 2021. In practice it's worth:

• writing SBOM delivery into vendor contracts and asking for an updated one with each major release
• loading SBOMs into a tool that matches components against CVE feeds automatically
• asking for VEX documents too, since they say whether a known vulnerability is actually reachable in that product

With that in place, the next Log4Shell is a database query on Monday morning instead of three weeks of emails to every supplier.

When the Outage Comes From a Trusted Vendor

Not every supply chain incident involves an attacker. On 19 July 2024 a faulty content update for the CrowdStrike Falcon sensor took down about 8.5 million Windows machines. Delta alone cancelled thousands of flights over the following days, and hospitals and banks in several countries were working on paper for part of the day. Nobody broke in. One vendor that was trusted almost everywhere simply shipped a bad file.

How many of the affected organizations could have said in advance which of their own suppliers depended on Falcon? Very few, most likely. That's what concentration risk and fourth-party risk look like in practice, and DORA now requires financial entities to map it. For everyone else it isn't mandatory, but it's hard to argue it's optional.

Partner APIs Nobody Is Watching

Dell found this out the hard way in May 2024. Someone set up a handful of fake partner accounts, pointed a script at the partner portal and pulled roughly 49 million customer records out of it. Around 5,000 requests a minute, for almost three weeks. By most accounts, the attacker ended up telling Dell about the hole himself. There was no rate limiting worth mentioning.

The Snowflake incidents that same year were a variation on the theme. Around 165 customer environments, AT&T and Ticketmaster among them, were accessed with credentials that infostealer malware had harvested, in some cases from contractors' machines. Those accounts didn't have MFA. Nothing more sophisticated was required.

A short checklist for partner integrations:

1. one scoped credential per vendor, no shared service accounts
2. rate limits and anomaly alerts on every partner-facing endpoint
3. OAuth tokens with lifetimes measured in hours
4. a regular hunt for old APIs left over from pilots and integrations that ended years ago

Palo Alto Networks Prisma Cloud and similar platforms can discover undocumented endpoints, and CrowdStrike Falcon's identity protection helps with the other part of the picture: what a vendor account that logged in with valid credentials goes on to do.

Regulators Now Expect Evidence

NIS2 started applying in October 2024, at least in the member states that transposed it on time (many didn't). Article 21 includes supply chain security in the list of required risk management measures, and members of management bodies can be held personally liable. For essential entities, fines go up to €10 million or 2% of worldwide annual turnover, whichever is higher.

DORA has applied to EU financial entities since 17 January 2025. Every firm has to keep a Register of Information listing all of its contractual arrangements with ICT third-party providers, and providers designated as critical are supervised directly by the European Supervisory Authorities. Contracts must cover audit rights and exit strategies, and supervisors do ask to see the exit plans.

NIST CSF 2.0 came out in February 2024 with a new Govern function and a supply chain risk management category, GV.SC. It isn't a regulation, but auditors outside the EU increasingly use it as their reference.

A folder of vendor PDFs on SharePoint isn't going to satisfy a DORA lead overseer. Frankly, it rarely satisfies internal audit.

What a Working TPRM Program Looks Like

Tier Vendors by Access, Not by Contract Size

A $20,000-a-year analytics plugin that can read the production database is a bigger problem than a $2 million facilities deal. Procurement usually sees it the other way round, which is odd when you think about it. Start with three tiers. More can come later.

• Tier 1: the vendor can reach regulated data, production or anything a customer sees. They get the full assessment and stay under continuous watch
• Tier 2: internal data and a narrow slice of the network. A lighter review once a year
• Tier 3: no data and no access, so a basic check and that's it

Stop Waiting a Year Between Reviews

BitSight and SecurityScorecard basically do what an attacker does on day one: scan the vendor from the outside. Open ports. A certificate that ran out three weeks ago. Employee passwords sitting in some infostealer dump. Patches that take a month to show up. Pair that with a short questionnaire (twelve questions, the ones that actually matter) and a new vendor can be cleared in about four days, where the old process meant three months of chasing people over email. Are the ratings flawless? No. Now and then a scanner decides an IP range belongs to the wrong company, and the vendor's score tanks for no good reason. Pick up the phone before tearing up the contract.

One Place for Workflow and Evidence

Intake, tiering, evidence, remediation tickets: in most shops all of that lives in OneTrust or ServiceNow GRC. Either one can spit out what a DORA register needs. IBM Security Guardium does a smaller job, but an important one: it shows what a vendor account is actually doing inside a sensitive database at 2 a.m. And when an auditor says "show me"? That should take a few minutes and one report. Not two weeks of digging through old email threads.

Zero-Trust Vendor Access

Target's attackers got in using credentials stolen from Fazio Mechanical, its refrigeration contractor, and then moved from a vendor portal into the payment network. Plenty of companies still give contractors permanent VPN access in much the same way. Zero-Trust Vendor Access puts an end to that. Contractors get into one application at a time through ZTNA, admin rights appear only when needed and vanish afterwards, the device gets checked before it connects, and every admin session is recorded.

The minimum baseline written into every contractor agreement should cover:

• phishing-resistant MFA on all privileged accounts
• notification of any breach within 24 hours
• a current SOC 2 Type II report or ISO 27001 certificate
• a list of subprocessors, with advance notice before it changes
• an SBOM for any software delivered
• a tested exit plan, including how data gets returned and deleted

Metrics Worth Reporting

A board slide that says "412 vendors assessed" tells nobody anything about risk. More useful metrics tend to be less flattering:

• the share of Tier 1 vendors with a current SBOM on file
• median time to close a critical finding raised with a vendor
• how many contractor accounts still have standing privileged access
• vendors whose external rating fell by more than 50 points in the quarter

If these numbers stay flat quarter after quarter, the program probably isn't doing much.

Where to Begin

Not with a new spreadsheet, obviously. A reasonable first step is to take the ten vendors with the deepest access, collect their SBOMs, map every API they connect to and remove any standing VPN accounts. That alone will close more real exposure than another year of questionnaires. After that comes the contract baseline: agree on it once and stop renegotiating it with every supplier. Legal will push back for a quarter or so, and then it simply becomes the document every new vendor signs before receiving its first API key.

Third-party risk won't go to zero. The chains are too long, and too much code comes from open-source contributors nobody has ever met. But the difference between knowing what's in the supply chain and guessing is something a security team can actually control. So the next time a vendor says its platform is SOC 2 compliant, what should the follow-up question be? Which subprocessors were left out of the audit scope, for a start.