The model was reviewed annually. It was updated when new threat intelligence arrived. It was presented to the board as a comprehensive view of the organization's attack surface. Nobody modeled the scenario where a widely-used software tool in the development workflow was compromised, and through it, every customer of every organization that used the tool.
The Architecture of Supply Chain Attacks
Supply chain attacks target the distribution mechanism rather than the end target. Instead of attacking an organization's network directly — a path protected by firewalls, detection systems, and security teams — the attacker compromises a trusted intermediary whose artifacts, code, or infrastructure the target organization incorporates into its own environment. The trust relationship that makes the supply chain function operationally is the trust relationship the attacker exploits.
The SolarWinds attack is the reference case, but it is not the only case. The Kaseya VSA attack compromised managed service providers who administered systems for thousands of downstream customers. The 3CX supply chain attack embedded malicious code in a widely-deployed communications platform. The XZ Utils backdoor attempt targeted a compression library present in the majority of Linux distributions. Each attack exploited a trusted software distribution mechanism. Each reached targets that had no vulnerability in their own directly-controlled systems.
The common thread is not the specific vector. It is the structural characteristic: the attacker entered the target's environment through a path the target trusted implicitly, because the path was a normal part of how software and services are delivered and consumed. The trust was not misplaced in a naive sense — the software had been used reliably for years. The trust was exploited because it was comprehensive and unverified.
The supply chain attack does not need a vulnerability in your environment. It needs a vulnerability in something your environment trusts. Your attack surface is not only the systems you control. It is everything those systems trust.
What Was Not in the Threat Model
Threat models are built around attacker capabilities and organizational vulnerabilities as they are understood at the time of the model's construction. The SolarWinds attack vector — compromising the build pipeline of a trusted vendor to insert malicious code into a software update — was known theoretically before it was executed at scale. It was not in most organizations' threat models because it had not been executed at that scale before, because the defensive complexity of the scenario made it feel remote, and because the threat model was built around direct attacks rather than supply chain attacks.
This is the persistent limitation of threat modeling as a governance practice: models are built from known threats and experienced attack patterns. Novel attack techniques — particularly ones that exploit trusted relationships rather than direct vulnerabilities — are systematically underrepresented because they have not yet occurred with enough frequency to be incorporated into standard threat model templates.
The Defensive Posture That Addresses It
Software Bill of Materials
A software bill of materials documents the components that make up deployed software: the libraries, frameworks, and tools it depends on, and their versions and origins. An organization with comprehensive SBOM coverage can determine, when a supply chain compromise is disclosed, which of its deployed systems are affected and how quickly. Without SBOM coverage, the response to a supply chain compromise involves manual inventory work under time pressure — discovering dependencies after the compromise is known rather than before.
Dependency Integrity Verification
Software packages and updates delivered through package managers and update mechanisms can be verified against cryptographic signatures that confirm the artifact's integrity and provenance. Verification that software artifacts match their expected signatures before deployment detects compromised artifacts at the point of installation rather than after deployment. This is technically straightforward for modern package management systems. It is not universally implemented because it adds friction to deployment workflows that were designed for speed.
Network Segmentation That Limits Lateral Movement
When a supply chain compromise delivers malicious code into an environment, the attacker's ability to cause damage depends on what the compromised software can reach within the network. Network segmentation that limits the blast radius of any individual compromise — including compromises delivered through trusted software — reduces the impact of supply chain attacks that cannot be prevented entirely. The attacker may get in through a trusted path. What they can do once inside depends on the architecture they find.
Vendor Security Monitoring
Organizations that monitor their software vendors' security posture — through intelligence services that track vendor security events, through engagement with vendor security programs, and through technical monitoring of software update integrity — have earlier warning when a vendor is compromised. The organizations that detected the SolarWinds compromise earliest were those that had monitoring infrastructure sensitive enough to detect the anomalous network traffic that the malicious code generated. The monitoring was not designed specifically for supply chain attacks. It was sensitive enough to detect the signal.
The Governance Investment
Supply chain risk governance requires investment in a different kind of visibility than traditional security programs provide. Asset inventories that include software dependencies, not only infrastructure and applications. Vendor security monitoring that tracks the health of trusted third parties, not only the assessment of their practices at a point in time. Threat models that explicitly include supply chain scenarios and are tested against known supply chain attack techniques.
The investment is not primarily technical. It is primarily a governance design choice to treat software dependencies and trusted vendor relationships as attack surface rather than as operational infrastructure. That reframing — from trusted input to potential attack vector — is what the organizations that were best positioned for SolarWinds had made before the attack. They had not necessarily predicted the specific technique. They had built the infrastructure for detecting anomalies in trusted channels, which turned out to be what was needed.
The attack nobody modeled for is usually the one that exploits the trust nobody thought to question. Build the monitoring that covers the trust relationships, not only the direct attack surface.
Model the supply chain. Monitor the trusted channels. Verify the software you deploy. The attack surface extends to everything your environment trusts, not only to everything you control.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.