Continue your mission
Supply chain security is the discipline of identifying, assessing, and mitigating cybersecurity risks that originate from third parties: software vendors, hardware manufacturers, cloud service providers, managed service providers, open-source libraries, and any other external entity whose products o
# Supply Chain Security
Supply chain security is the discipline of identifying, assessing, and mitigating cybersecurity risks that originate from third parties: software vendors, hardware manufacturers, cloud service providers, managed service providers, open-source libraries, and any other external entity whose products or services are integrated into the organization's technology environment.
A supply chain attack compromises a trusted third party and uses that trust to reach the ultimate target. The attacker does not breach the target directly. The attacker breaches a vendor, compromises the vendor's product or service, and the target organization installs the compromised product or consumes the compromised service through a legitimate, trusted channel. The target's firewalls, endpoint detection, and access controls do not stop the attack because the attack arrives through a path those controls are configured to trust.
Supply chain attacks are the most efficient attack vector available to sophisticated adversaries because they multiply reach. Compromising one vendor with 18,000 customers (SolarWinds) provides potential access to 18,000 organizations. Compromising one open-source library used by millions of applications (Log4j) provides potential access to virtually every organization running Java applications. Compromising one file transfer tool used across industries (MOVEit) provides access to thousands of organizations and tens of millions of individual records. The attacker invests once. The impact scales with the vendor's customer base.
Supply chain attacks target different points in the supply chain:
Software build compromise. The attacker infiltrates the vendor's software development or build process and inserts malicious code into the product before it is distributed to customers. The compromised product is signed with the vendor's legitimate code-signing certificate and distributed through the vendor's legitimate update mechanism. The customer's systems accept it as a trusted update.
SolarWinds (2020) is the defining example. Russian SVR operators (APT29) compromised the build process for SolarWinds Orion (an IT management platform) and inserted a backdoor (SUNBURST) into a legitimate software update distributed to approximately 18,000 customers. The update was digitally signed by SolarWinds. Every customer who installed it received the backdoor through a trusted channel.
Dependency exploitation. The attacker compromises an open-source library or dependency that is included in the target's software. Modern applications contain 70% to 90% open-source components. A vulnerability in one widely-used library affects every application that includes it.
Log4Shell (December 2021) was a critical remote code execution vulnerability (CVE-2021-44228) in Apache Log4j, a ubiquitous Java logging library. Log4j was embedded in hundreds of thousands of applications across virtually every industry. The vulnerability allowed an attacker to execute arbitrary code on any system running a vulnerable version of Log4j by sending a specially crafted log message. The impact was global and immediate.
Managed service provider compromise. The attacker compromises a managed service provider (MSP) or managed security service provider (MSSP) and uses the MSP's administrative access to the MSP's customers' environments to deploy ransomware, exfiltrate data, or establish persistent access. MSPs are high-value targets because a single MSP compromise provides access to dozens or hundreds of customer environments through the MSP's legitimate remote management tools.
The Kaseya VSA attack (July 2021) exploited a vulnerability in Kaseya's remote monitoring and management (RMM) platform, used by MSPs to manage their customers' IT environments. The REvil ransomware group exploited the vulnerability to deploy ransomware through Kaseya's update mechanism to MSPs' customer environments, affecting over 1,500 businesses.
Application exploitation. The attacker exploits a vulnerability in a third-party application that the target organization uses. The vulnerability is in the vendor's code, but the exploitation occurs in the target's environment.
MOVEit (May-June 2023) was a SQL injection vulnerability in Progress Software's MOVEit file transfer application. The Cl0p ransomware group exploited the vulnerability at scale, exfiltrating data from over 2,500 organizations and affecting approximately 90 million individuals. Cl0p did not deploy ransomware or encrypt files. They exfiltrated data through the trusted file transfer application and used the stolen data for extortion.
Hardware supply chain. The attacker compromises hardware during manufacturing or distribution. This includes implanting surveillance capabilities in networking equipment, compromising firmware in storage devices, or inserting malicious components into hardware during manufacturing. Hardware supply chain attacks are the most difficult to detect and the most difficult to attribute. Documented examples include concerns about networking equipment from certain manufacturers and compromised USB cables with embedded wireless transmitters.
Supply chain attacks exploit the fundamental security architecture of trust relationships. Organizations configure their security controls to trust specific vendors: the firewall allows traffic to the SaaS provider, the endpoint allows updates from the software vendor, the build pipeline includes open-source libraries from package registries. This trust is necessary for operations. It is also the attack surface.
The challenge: every trusted relationship is a potential supply chain vector. An organization with 50 software vendors, 10 cloud services, 200 open-source dependencies, and 5 managed service providers has 265 trust relationships, each of which could become a supply chain attack path. Managing this surface requires the same continuous vigilance that managing the internet-facing attack surface requires.
Supply chain attacks produce outsized damage relative to the attacker's investment because the impact multiplies through the vendor's customer base. NotPetya (delivered through a compromised Ukrainian tax software update) caused $10+ billion in global damages. SolarWinds compromised approximately 18,000 organizations through a single vendor compromise. MOVEit exposed data from 2,500+ organizations. Log4Shell affected virtually every organization running Java.
Individual organizations cannot defend against supply chain attacks through their own controls alone because the attack arrives through a trusted channel that those controls are designed to permit. Defense requires the vendor to secure their product, the customer to verify the vendor's security, and the industry to establish standards that make supply chain compromise more difficult and more detectable.
Governments have responded to supply chain attacks with regulatory action. Executive Order 14028 (May 2021, issued in direct response to SolarWinds) requires federal agencies and their software suppliers to meet enhanced software supply chain security standards, including Software Bills of Materials (SBOMs), secure development attestations, and vulnerability disclosure requirements.
NIST CSF 2.0 elevated supply chain risk management from a subcategory (in CSF 1.1) to a full category under the new Govern function (GV.SC), reflecting its increased importance. ISO 27001:2022 added Control A.5.21 (Managing Information Security in the ICT Supply Chain). CMMC 2.0 includes practices related to supply chain risk management. The European Union's NIS2 Directive includes supply chain security requirements for essential entities.
The regulatory direction is clear: supply chain security is no longer optional, and the responsibility is shifting from purely voluntary vendor assessment to mandated supply chain risk management programs.
Open-source software powers modern applications. The convenience of importing a library that solves a problem is immense. The risk is that the library's security is maintained by volunteers, its dependencies may include hundreds of transitive components (dependencies of dependencies), and a vulnerability in any component in the dependency tree affects every application that includes it.
Software Composition Analysis (SCA) tools (Snyk, Mend, Black Duck, Dependabot) scan applications to identify which open-source components are in use, which have known vulnerabilities, and which have licenses that create legal risk. SCA is a VSD control that provides visibility into a supply chain surface that would otherwise be invisible.
SBOMs (Software Bills of Materials) provide a machine-readable inventory of every component in a software product, enabling customers to assess their exposure when a new vulnerability is disclosed. If a vendor provides an SBOM and a new Log4j vulnerability is announced, the customer can immediately check whether the vendor's product includes Log4j without waiting for the vendor's advisory.
Supply chain security sits primarily in the VSD (Vulnerability and Surface Defense) domain of the Planetary Defense Model. VSD is the ocean layer: the attack surface where adversaries probe and breach. The supply chain is a subset of the attack surface that is uniquely difficult to manage because it extends beyond the organization's own infrastructure into the vendor ecosystem.
CDA's Continuous Surface Reduction (CSR) methodology applies to supply chain risk. "Every surface you expose is a surface we eliminate." Every vendor integration, every open-source dependency, and every managed service relationship is an exposed surface. CSR evaluates whether each surface is operationally necessary, whether it is minimally scoped (the vendor has only the access required for the service), and whether it is monitored for anomalous behavior.
CDA's Orbital Alliance Framework (OAF), a cross-domain protocol defined in the PDM, treats partner and vendor ecosystems as orbital bodies whose security posture affects the planet's defense. A vendor with weak security that has API access to the organization's production environment is a moon with a decaying orbit: it will eventually collide with something critical. OAF provides the framework for assessing vendor security posture, establishing contractual security requirements, monitoring vendor compliance, and maintaining contingency plans for vendor failure or compromise.
Three TOP missions connect to supply chain security:
The interaction with adjacent domains: TID detects exploitation of supply chain vulnerabilities (compromise indicators from vendor infrastructure, anomalous behavior from trusted software). IAT controls the access that vendor integrations have (scoping vendor API access to minimum required, monitoring vendor session activity). DPS protects data that vendor integrations can access (encryption, DLP controls on data shared with vendors). SPH maintains the configurations that minimize supply chain blast radius (network segmentation between vendor-accessible systems and critical infrastructure). RGA provides the governance framework that mandates vendor assessments and contractual security requirements.
CDA approaches supply chain security with one specific emphasis: operational verification over questionnaire-based assessment. Conventional vendor risk management sends a questionnaire. The vendor's sales team fills it out with favorable answers. Nobody verifies. CDA's approach includes external assessment of the vendor's internet-facing posture (the same ASM techniques used for the client's own environment), contractual requirements for incident notification and SBOM provision, and continuous monitoring of the vendor's security rating and publicly disclosed incidents. Trust is verified, not assumed. ZPA applies to vendors as it applies to everything else: "Trust nothing. Possess nothing. Verify everything."
Word count: 2,097
CDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.