The SolarWinds breach, announced in December 2020, changed how security professionals think about enterprise risk. Attackers compromised the software build process of a trusted network management vendor. The malicious update was signed with a legitimate certificate and pushed through the normal software update mechanism to 18,000 organisations, including US government agencies and major corporations.
The organisations hit did not have weak security practices. Many had sophisticated security teams and significant investment in perimeter defences. None of that mattered, because the attack entered through a channel those defences were designed to trust.
Supply chain attacks have grown in frequency and sophistication every year since. In 2026, they represent one of the highest-impact categories of cyber threat precisely because they exploit the trust relationships that modern enterprise IT depends on.
How Supply Chain Attacks Work
| Attack Vector | How It Enters | Real Example |
|---|---|---|
| Compromised software update | Malicious code in legitimate vendor update | SolarWinds Orion (2020) |
| Malicious open source package | Typosquatted or hijacked npm/PyPI package | event-stream npm package (2018) |
| Vendor credential compromise | Attacker uses stolen MSP credentials | Kaseya VSA attack (2021) |
| Hardware supply chain | Malicious firmware in hardware from manufacturer | Bloomberg Supermicro claims (disputed) |
| Third-party data processor breach | Attacker accesses customer data via vendor | MOVEit Transfer exploitation (2023) |
Why Perimeter Security Does Not Stop These Attacks
Enterprise security architecture traditionally builds defences at the boundary between the internal network and the external internet. Firewalls, intrusion detection systems, and endpoint protection tools are calibrated to identify and block external threats.
Supply chain attacks do not cross that boundary as hostile traffic. They arrive as legitimate software updates from vendors whose domains are whitelisted, as code from package repositories that development teams are authorised to use, or as data transfers from contracted service providers. The attack blends into normal operations because it is indistinguishable from them.
The trust that makes modern IT ecosystems efficient, the ability to push software updates automatically, to use shared libraries, to outsource specific functions to specialist providers, is the same trust that supply chain attackers exploit.
The Scale of Third-Party Risk in 2026
The average large enterprise now uses over 1,500 SaaS applications. Each represents a potential entry point. Each vendor has its own security posture, its own software dependencies, and its own exposure to the vulnerabilities that supply chain attackers target.
The Ponemon Institute’s 2025 Third-Party Risk Management Study found that 61% of organisations had experienced a data breach caused by a third party in the previous two years. The average cost of a third-party breach was measurably higher than the average cost of a breach from direct attack, because detection is slower and the scope of data exposure is often broader.
Concentration risk compounds the problem. When a widely used platform like MOVEit Transfer, SolarWinds Orion, or Log4j has a critical vulnerability, the impact is not confined to one organisation. A single exploited flaw can simultaneously breach thousands of organisations that use the same software.
Building a Vendor Risk Management Programme
Tier Your Vendors by Risk
Not all vendors present equal risk. A vendor with access to your customer data, your production systems, or your development pipeline presents fundamentally different risk than a vendor who supplies office furniture. Start by mapping which vendors have access to what, and classify them into risk tiers based on the sensitivity of that access.
Tier 1 vendors with access to critical systems or data warrant annual security assessments, contractual security requirements, and right-to-audit clauses. Tier 3 vendors with no system access warrant basic due diligence only. Most organisations over-invest in assessing low-risk vendors and under-invest in scrutinising high-risk ones.
Assess Their Security Posture, Not Just Their Questionnaire Answers
Security questionnaires are a standard vendor risk tool and a notoriously unreliable one. Vendors answer with the responses that win contracts, not necessarily with accurate self-assessments. Independent validation, through third-party security ratings services like SecurityScorecard, BitSight, and RiskRecon, provides continuous passive assessment of a vendor’s external security posture without relying on self-reported data.
For Tier 1 vendors, SOC 2 Type II reports provide a more rigorous independent assessment. The Type II report covers not just whether controls exist (Type I) but whether they operated effectively over a defined period. Request current reports, not ones from two years ago.
Limit Access to What Vendors Actually Need
The principle of least privilege applies to vendor access as much as to internal users. Vendors frequently end up with broader access than their function requires because provisioning access is easier than calibrating it precisely. An annual access review for all vendor accounts, removing any access that cannot be justified by current business need, is a high-return control that most organisations do not run consistently.
Network segmentation that isolates vendor-connected systems from core business systems limits the blast radius when a vendor is compromised. A vendor breach that can reach only the systems the vendor legitimately needs to access is meaningfully less damaging than one with unrestricted lateral movement.
Software Supply Chain Security Specifically
The software supply chain deserves specific attention because it is the vector used in the most damaging attacks. Every software component your organisation uses, whether commercial, open source, or internally developed, has dependencies on other software components. Each dependency is a potential entry point.
Software Bill of Materials (SBOM) generation, a machine-readable list of all software components and their versions, has become a regulatory requirement for software sold to US federal agencies and is increasingly expected in other regulated sectors. An SBOM enables rapid identification of whether your software contains a newly discovered vulnerable component.
Dependency scanning tools, including Dependabot (GitHub), Snyk, and OWASP Dependency-Check, continuously monitor software dependencies for known vulnerabilities and alert when a component needs updating. These should be integrated into every development pipeline as a mandatory gate.
Contractual Protections That Actually Matter
Vendor contracts should require notification of security incidents within a defined timeframe, typically 24 to 72 hours of discovery. Right-to-audit clauses allow independent security assessment when concerns arise. Data processing agreements must specify where data is processed, how it is protected, and what happens to it at contract termination.
Insurance requirements are increasingly standard in enterprise vendor contracts. Requiring vendors to carry cyber liability insurance provides a financial backstop but should not substitute for actual security assessment. A vendor with a $5 million policy and poor security practices is not adequately mitigating risk.
Common Mistakes in Third-Party Risk Management
One-time assessments that are never refreshed. A vendor who passed your security questionnaire 18 months ago may have grown rapidly, changed infrastructure, or experienced an unreported incident since then. Risk is dynamic; point-in-time assessments give a false sense of ongoing assurance.
Focusing exclusively on large, named vendors. The most damaging supply chain attacks have frequently entered through smaller, less scrutinised vendors that have access to production systems or data. Attackers target the weakest link, which is rarely the largest provider.
No incident response plan for vendor breaches. When a vendor notifies you of a compromise, the time to build your response plan is not after receiving the notification. Tabletop exercises that include third-party breach scenarios are among the most valuable preparation most organisations skip.
