Supply Chain Security — When Your Vendor's Vendor Becomes Your Problem

The Third-Party Reality

The data on third-party risk is no longer ambiguous. It has crossed a threshold that demands structural changes to how organisations manage their vendor ecosystems.

The Verizon 2025 Data Breach Investigations Report documented a decisive shift: third-party involvement in confirmed breaches doubled from 15% to 30% year-over-year. This is the single largest year-over-year change in any breach vector the DBIR has tracked.

SecurityScorecard's 2025 Global Third-Party Breach Report corroborates and extends the picture. Across all organisations analysed, 35.5% of breaches were third-party related. Among Fortune 500 companies, that figure rose to 46.75% — meaning nearly half of all breaches at the largest companies originated outside their own perimeter.

The financial impact is proportionate. IBM's 2025 Cost of a Data Breach Report measured vendor-related breaches at an average of $4.91 million, 12% above the overall average. These breaches also took 267 days to identify and contain — nine days longer than direct breaches. The detection gap matters: every additional day of undetected compromise expands the blast radius.

SecureFrame's 2026 research quantifies the scale of the management challenge. The average organisation now manages 286 vendor relationships, up from 237 the prior year. Sixty-one percent of organisations experienced a third-party breach in the past twelve months. Ponemon Institute's 2025 manufacturing sector study found that 42% of manufacturers had been breached through vendor access.

These numbers describe a systemic condition, not an anomaly. The modern organisation's attack surface extends far beyond what it directly controls.

The trajectory matters as much as the current state. Vendor counts are growing as organisations adopt more specialised SaaS tools, cloud services, and managed security providers. Each new vendor relationship introduces not only the vendor itself but its entire dependency chain. The compounding effect is an attack surface that expands faster than most security teams can assess it.

Beyond Third Parties — The Fourth-Party Problem

Most vendor risk programmes, where they exist at all, focus on direct (third-party) relationships. The deeper layers of the supply chain receive little attention despite carrying substantial risk.

Research from SecurityScorecard and other supply chain analysts indicates that for each direct vendor relationship, an organisation inherits roughly 14 times as many fourth- and fifth-party dependencies. An organisation with 286 direct vendors may be exposed to over 4,000 entities it has no contractual relationship with and, in most cases, cannot even name.

The CrowdStrike incident of July 2024 demonstrated what concentration risk looks like at the fourth-party level. A faulty Falcon sensor update — not a cyberattack, but a software quality failure — disabled 8.5 million Windows computers globally. Parametrix estimated the direct financial losses for the top 500 US companies alone at $5.4 billion. Airlines grounded flights. Hospitals reverted to paper records. Payment systems went offline.

The critical insight is structural: CrowdStrike was not a direct vendor for many of the affected end-users. It was a vendor of their vendors — a fourth party embedded so deeply in operational infrastructure that its failure cascaded through layers of dependency most organisations had never mapped. A hospital that contracted with a managed IT provider, which in turn deployed CrowdStrike, experienced the disruption without ever having evaluated CrowdStrike as a risk.

This pattern of concentrated fourth-party dependency is not unique to endpoint security. Cloud infrastructure (AWS, Azure, GCP), identity providers, DNS services, and certificate authorities all represent single points of failure that propagate through the supply chain. The Snowflake credential theft campaign of 2024, which affected over 165 customer organisations, demonstrated how a compromise at one platform can simultaneously expose data across hundreds of unrelated companies.

The mapping challenge is significant. Most organisations lack tooling or processes to identify their fourth-party dependencies systematically. A vendor may disclose its primary subcontractors in a due diligence questionnaire, but rarely provides a complete inventory of the software platforms, infrastructure providers, and service partners it relies on. The result is a risk landscape that organisations can sense but cannot see.

Fourth-party risk is not theoretical. It is a demonstrated cause of operational disruption and data loss at scale.

The Software Supply Chain

The software supply chain introduces a distinct category of risk that operates alongside — and often independently of — vendor relationship management.

Sonatype's 2024 State of the Software Supply Chain report identified 512,847 malicious packages across major open-source repositories, representing a 156% year-over-year surge. ReversingLabs' 2025 research found that malware on open-source platforms increased 73% year-over-year, with software supply chain attacks growing three times faster than the overall malware trend.

The scale of recent incidents illustrates the exposure:

The xz-utils incident is particularly instructive. A nation-state actor spent approximately two years building trust as a legitimate open-source contributor before inserting a backdoor into a compression library used by virtually every Linux distribution. The backdoor was discovered accidentally by a Microsoft engineer who noticed anomalous SSH performance. Had it reached stable releases, it would have provided a remote code execution path into millions of servers.

Gitguardian's 2025 research found 39,000 secrets — API keys, credentials, tokens — exposed in public npm packages. Each represents a potential entry point into an organisation's infrastructure through a dependency it may not even be aware of.

The software supply chain challenge is fundamentally different from vendor management. Traditional TPRM evaluates the security posture of a known counterparty. Software supply chain risk emerges from transitive dependencies — the library your library depends on, maintained by an anonymous contributor in their spare time. The average enterprise application contains hundreds of such dependencies, creating an attack surface that questionnaires cannot address.

The attack economics are compelling from the adversary's perspective. Compromising a single widely used package can provide access to thousands of downstream applications simultaneously. The cost of mounting a supply chain attack — registering a typosquatted package name, contributing to an open-source project over time, or exploiting a maintainer's compromised credentials — is trivial compared to the potential reach. This asymmetry explains why software supply chain attacks are growing faster than virtually any other threat category.

The Regulatory Push

European regulators have recognised that supply chain security cannot remain a voluntary best practice. Three major regulatory instruments now mandate structured approaches to vendor and supply chain risk.

NIS2 — Supply Chain as Mandatory Risk Management

Article 21(2)(d) of the NIS2 Directive explicitly lists supply chain security as one of the minimum risk management measures that essential and important entities must implement. This is not a recommendation. It is a legal obligation with enforcement consequences.

The directive requires organisations to address vulnerabilities specific to each direct supplier and service provider, consider the overall quality and resilience of products and services, and take into account the cybersecurity practices of suppliers including their secure development procedures. Member state transposition deadlines passed in October 2024, with enforcement now underway across the EU.

Critically, NIS2 applies to essential and important entities across 18 sectors — far broader than previous EU cybersecurity legislation. Management bodies bear personal liability for ensuring compliance, including with supply chain security measures. This shifts supply chain risk from a technical concern to a board-level governance obligation.

DORA — Critical Third-Party Provider Oversight

DORA Articles 28 through 44 establish the most prescriptive third-party risk management regime in any EU regulation. The framework goes beyond requiring financial entities to manage their own vendor relationships — it creates a direct supervisory mechanism for providers deemed systemically important.

In November 2025, the European Supervisory Authorities designated 19 ICT service providers as Critical Third-Party Providers (CTPPs) under the DORA oversight framework. These providers — primarily major cloud platforms and financial technology infrastructure — are now subject to direct regulatory supervision, including the power to conduct inspections, request information, and impose penalties.

For financial entities, DORA requires maintaining a Register of Information documenting all ICT third-party arrangements, with standardised reporting templates. The regulation explicitly addresses sub-outsourcing chains, requiring financial entities to assess the risks arising from their providers' own outsourcing arrangements — a direct regulatory response to fourth-party risk.

CRA — Software Bill of Materials and Security by Design

The Cyber Resilience Act (EU 2024/2847) addresses the software supply chain dimension directly. Products with digital elements placed on the EU market must comply with essential cybersecurity requirements, including vulnerability handling processes and coordinated disclosure obligations.

The CRA mandates that manufacturers produce a Software Bill of Materials (SBOM) identifying the components contained in their products. This requirement, with compliance deadlines phased through December 2027, creates a transparency mechanism that has been largely absent from the software supply chain. Manufacturers must also implement security-by-design principles and provide security updates throughout the product's expected lifetime.

The CRA's vulnerability handling requirements (Annex I, Part II) mandate that manufacturers exercise due diligence when integrating third-party components, and verify that those components do not contain known exploitable vulnerabilities. This creates a chain of accountability that extends through the software supply chain.

Taken together, NIS2, DORA, and the CRA create a regulatory environment where:

• Supply chain security is no longer optional — it is a legal obligation
• Fourth-party dependencies must be identified and assessed
• Software composition must be documented and monitored through SBOMs
• Enforcement carries meaningful consequences, including administrative fines and personal liability for management

Organisations operating across multiple regulatory regimes face compounding requirements. A financial institution subject to both DORA and NIS2 must satisfy the stricter of the two frameworks at each point of overlap. The CRA adds product-level obligations that affect any organisation placing connected products on the EU market. The cumulative effect is a regulatory environment that treats supply chain opacity as a compliance failure in itself.

SBOM as Foundation

The Software Bill of Materials concept has moved from a niche technical practice to a regulatory requirement in less than five years. US Executive Order 14028 (May 2021) mandated SBOMs for software sold to the federal government. The CRA now extends similar requirements across the EU market.

An SBOM is a machine-readable inventory of all components, libraries, and dependencies in a software product. It lists each component's name, version, supplier, and relationship to other components in the dependency tree. Standard formats include SPDX (maintained by the Linux Foundation) and CycloneDX (maintained by OWASP). Both support the level of detail necessary for vulnerability tracking, licence compliance, and provenance verification.

The operational value of SBOMs extends beyond compliance documentation. When a vulnerability is disclosed in a widely used component — as with Log4j in December 2021 — organisations with SBOMs can immediately determine whether they are affected. Without an SBOM, the same determination requires manual code review, vendor inquiries, and considerable uncertainty.

Despite the clear benefits and regulatory trajectory, adoption remains uneven. Industry surveys suggest that only approximately 30% of organisations currently produce SBOMs for their own software, and fewer require them from vendors. The gap between regulatory expectation and operational reality is significant — and the CRA's phased compliance deadlines are approaching faster than many product teams realise.

For organisations subject to the CRA, the SBOM requirement creates a deadline-driven implementation need. For all others, SBOMs represent a foundational capability for managing software supply chain risk — enabling continuous monitoring, vulnerability correlation, and evidence-based vendor conversations that annual questionnaires cannot provide.

The practical implementation path involves both producing SBOMs for internally developed software and requiring them from vendors. The production side is increasingly well-supported by build tooling — most modern package managers and CI/CD platforms can generate SBOMs as part of the build process. The consumption side — ingesting vendor SBOMs, correlating them against vulnerability databases, and acting on findings — requires dedicated tooling and processes that most organisations have not yet established.

Requesting SBOMs from vendors also serves a secondary function: it signals maturity. Vendors that cannot produce an SBOM for their own products likely lack the software composition analysis capabilities to manage their own supply chain risk effectively. The request itself becomes a meaningful assessment data point.

Visibility and Assessment

The current state of third-party risk management across most organisations does not match the scale of the threat or the expectations of regulators. The gap is not primarily technological — adequate tooling exists. It is organisational: resource constraints, fragmented ownership between procurement, security, and legal teams, and legacy processes designed for a simpler vendor landscape.

Whistic's 2025 Third-Party Risk Management Study (building on Prevalent's methodology) found that only 9% of organisations have achieved advanced TPRM maturity. The remaining 91% operate with significant gaps in their ability to identify, assess, and monitor vendor risk. The same research found that 94% of organisations cannot assess all the vendors they would like to — a resource constraint that grows more severe as vendor counts increase.

The time investment required for traditional assessment methods is substantial. Organisations report spending an average of 37.4 hours per week on vendor assessment activities — questionnaire distribution, response review, follow-up, and documentation. For an organisation with 286 vendors, this translates to roughly eight hours of assessment activity per vendor per year, assuming no growth in the vendor portfolio.

This creates what practitioners describe as the "364-day blindness problem." An annual assessment captures a single point-in-time snapshot. For the remaining 364 days, the organisation operates on the assumption that nothing material has changed — an assumption contradicted by the pace of vulnerability disclosure, configuration drift, and personnel turnover at vendor organisations.

Continuous monitoring capabilities — security ratings, external attack surface assessments, threat intelligence feeds, and automated compliance checks — address this gap but introduce their own challenges. They require integration, calibration, and operational processes to act on findings. A security rating that drops from B to D is only useful if someone notices, investigates, and takes action.

The tiering of vendors by criticality is essential for making assessment programmes sustainable. Not all 286 vendors warrant the same level of scrutiny. Vendors with access to sensitive data, critical infrastructure dependencies, or deep network integration require continuous monitoring and detailed assessment. Vendors providing commodity services with limited access can be managed through automated checks and periodic review. Without tiering, organisations either over-invest in low-risk vendors or under-invest across the board.

The regulatory direction is unambiguous. DORA explicitly requires ongoing monitoring of ICT third-party providers. NIS2's implementing regulation specifies that supply chain security measures should account for changes in the threat landscape. Annual point-in-time assessments, while still necessary as a baseline, are no longer sufficient as a standalone approach.

The organisations that have moved beyond annual assessments report measurable improvements: faster detection of vendor security degradation, earlier warning of potential incidents, and a more defensible compliance posture during regulatory examinations. The investment required is real, but so is the risk reduction.

Contractual Controls

Contracts remain the primary legal mechanism for managing third-party and fourth-party risk, yet many vendor agreements lack the provisions necessary to support effective oversight.

Cascade Provisions

A cascade provision requires the vendor to impose equivalent security obligations on its own subcontractors. Without cascade clauses, the security requirements negotiated with a direct vendor may not extend to the fourth parties that actually process or access data. DORA makes this explicit: Article 29 requires financial entities to assess the risks arising from sub-outsourcing arrangements and to ensure that contractual provisions extend through the chain.

Right-to-Audit Clauses

The ability to audit a vendor's security practices — or to receive the results of independent audits — is essential for verification. DORA Article 30 requires that ICT contracts include audit and access rights, with unlimited access for competent authorities and resolution authorities. NIS2's implementing regulation reinforces the expectation that organisations verify, not merely trust, their suppliers' security claims.

Practical implementation varies. Large cloud providers typically offer SOC 2 reports and ISO 27001 certificates rather than permitting customer-specific audits. Smaller vendors may resist audit clauses as burdensome. The contractual negotiation must balance thoroughness with commercial reality while maintaining regulatory compliance.

Where direct audit is impractical, pooled audit arrangements, reliance on recognised certifications, and access to independent penetration test results provide alternative assurance mechanisms. The key principle is that some form of independent verification must exist — self-attestation alone does not satisfy regulatory expectations under DORA or NIS2.

Sub-Contractor Notification

Requiring vendors to notify the customer before engaging new sub-contractors — or before changing sub-contractors who handle sensitive data — provides a mechanism for ongoing fourth-party visibility. DORA requires that ICT contracts include provisions for the vendor to notify the financial entity of any intended sub-outsourcing of critical or important functions, with the entity retaining the right to object.

Incident Notification Timelines

The gap between when a vendor detects a security incident and when it notifies affected customers has historically been measured in weeks or months. Contractual incident notification clauses should specify timeframes of 24 to 48 hours, aligning with the regulatory reporting timelines that NIS2 and DORA impose on the affected organisation itself.

Under NIS2, significant incidents must be reported to the competent authority within 24 hours (early warning) and 72 hours (full notification). DORA requires initial notification within four hours of classification for major ICT-related incidents. An organisation cannot meet these timelines if its vendor takes a week to disclose the breach. Contractual notification obligations must therefore be tighter than the regulatory reporting deadlines to provide adequate response time.

Beyond timing, contracts should specify the content of incident notifications: what happened, what data or systems were affected, what containment measures have been taken, and what the vendor's remediation plan is. Vague contractual language like "prompt notification" invites disputes during precisely the moments when clarity matters most.

Termination and Exit Rights

Contracts should include clearly defined exit provisions, including data retrieval, transition support, and reasonable termination notice periods. DORA Article 30 requires exit strategies for critical or important ICT functions, ensuring that termination of a vendor relationship does not itself create operational risk.

Data Processing and Residency

For vendors processing personal data, contractual provisions must align with GDPR data processing agreement requirements (Article 28 GDPR), including specifying the nature and purpose of processing, data retention and deletion obligations, and geographic restrictions on data storage. Where vendors use sub-processors, the contract should require prior notification and maintain the customer's right to object — creating another layer of fourth-party visibility.

The cumulative effect of these contractual controls is a legal framework that extends security governance beyond the organisation's direct perimeter. No contract eliminates fourth-party risk, but well-drafted provisions create accountability, transparency, and enforcement mechanisms that meaningfully reduce it.

The Path Forward

Supply chain risk is not a problem that can be solved with a single initiative or tool. It is a condition that must be managed — continuously, structurally, and with appropriate investment.

Building an effective supply chain security programme does not require perfection from day one. It requires commitment to incremental improvement: establishing vendor inventories, implementing tiered assessment, negotiating stronger contracts, and progressively extending visibility into deeper layers of the supply chain.

The organisations that manage it effectively share common characteristics: they have visibility beyond the first tier of their supply chain, they supplement point-in-time assessments with continuous monitoring, they embed security requirements into contracts with cascade provisions, and they maintain an SBOM practice that enables rapid vulnerability response.

The regulatory framework across NIS2, DORA, and the CRA now mandates most of these capabilities. The gap between current practice and regulatory expectation is significant for most organisations. Closing it requires treating supply chain security not as a procurement function or a compliance checkbox, but as a core component of operational resilience.

The starting point is visibility: understanding not just who your vendors are, but what they depend on, what software components they use, and where concentration risks exist. From that foundation, organisations can build tiered assessment programmes, implement continuous monitoring, negotiate meaningful contractual protections, and establish incident response processes that account for the reality that the next breach is as likely to originate three layers deep in the supply chain as it is to come through the front door.

The vendor's vendor is already your problem. The question is whether your programme reflects that reality.

Sources

Primary Breach Data

• Verizon — 2025 Data Breach Investigations Report
• IBM — Cost of a Data Breach Report 2025
• SecurityScorecard — 2025 Global Third-Party Breach Report
• Ponemon Institute / Black Kite — Third-Party Breach Report 2025
• SecureFrame — 2026 Third-Party Risk Report

Supply Chain Research

• Sonatype — 2024 State of the Software Supply Chain
• ReversingLabs — 2025 Software Supply Chain Security Report
• Gitguardian — State of Secrets Sprawl 2025

TPRM Industry Data

• Whistic / Prevalent — 2025 Third-Party Risk Management Study
• Parametrix — CrowdStrike Outage Impact Analysis

SBOM and Software Transparency

• NTIA — SBOM Minimum Elements
• SPDX Specification
• CycloneDX Specification

EU Regulatory Sources

• NIS2 Directive (EU 2022/2555) — EUR-Lex
• DORA Regulation (EU 2022/2554) — EUR-Lex
• Cyber Resilience Act (EU 2024/2847) — EUR-Lex
• US Executive Order 14028 — Improving the Nation's Cybersecurity