What Is Supply Chain Security?

In December 2020, around 18,000 organizations downloaded a routine update to SolarWinds Orion. The update was signed, it came from the vendor's own build system, and it carried a backdoor the attackers had planted inside the build pipeline. None of the victims had a vulnerability of their own to patch. They were breached because something they trusted was compromised upstream. US officials attributed the operation to Russia's SVR, the group tracked as APT29.

That is the problem supply chain security exists to address. Every organization runs code it did not write, hardware it did not build, and services it does not control, and an attacker who compromises one of those upstream dependencies inherits access to everyone downstream. This guide covers what supply chain security is, the kinds of supply chain risk a defender actually faces, why the attack surface has grown the way it has, the lifecycle and controls that manage it, the frameworks that govern it, and how it fits inside an exposure-management program.

What is supply chain security?

Supply chain security is the practice of identifying, assessing, and reducing the risk that an organization inherits from the third parties, software, hardware, and services it depends on. It covers the entire chain of suppliers behind a product or system, not just the direct vendor you signed a contract with, but that vendor's suppliers, the open-source components in their code, the build systems that compile it, and the update channels that deliver it.

The defining trait is that the risk lives outside your perimeter. Traditional security hardens what you own and operate. Supply chain security deals with the parts of your operation that someone else owns and operates, yet that still run inside your environment or hold your data. You cannot patch a vendor's build server. You cannot audit every commit to an open-source library you pulled in three dependencies deep. What you can do is know what you depend on, judge how much to trust each link, and put controls between you and the parts you cannot verify.

Two related disciplines sit under this umbrella, and it helps to keep them straight. Software supply chain security focuses on the code path: open-source dependencies, build pipelines, package registries, and the integrity of the artifacts you ship and consume. Third-party risk management focuses on the vendor relationship: the SaaS providers, contractors, and service firms that touch your data or systems. Both are supply chain security. They differ in where the risk enters.

The kinds of supply chain risk

A supply chain attack is any compromise that reaches you through a trusted upstream party rather than directly. The common forms are worth naming because the defenses differ.

Compromised software updates. The attacker breaches a vendor's build or distribution system and ships malware inside a legitimate, signed update. SolarWinds is the canonical example: the SUNBURST backdoor was inserted into Orion builds between March and June 2020 and distributed through the normal update channel. The 3CX desktop app compromise in 2023 followed the same pattern. The victim did nothing wrong; they installed an update from a vendor they trusted.

Malicious or compromised open-source components. Modern applications are mostly other people's code. An attacker who can insert a backdoor into a widely used library reaches everyone who depends on it. The XZ Utils backdoor (CVE-2024-3094), discovered in 2024, is the sharpest recent case: a malicious maintainer operating as "Jia Tan" spent over two years gaining the trust of the project, then planted a backdoor in the liblzma compression library that could have enabled remote code execution through OpenSSH on countless Linux systems. It was caught before it reached most production environments, but only by chance.

Dependency confusion and typosquatting. Attackers publish malicious packages to public registries (npm, PyPI, and others) with names that either mimic popular packages by a character or two, or that collide with an organization's internal package names so the build system pulls the public, malicious version instead of the private one.

Hardware and firmware tampering. Malicious implants or modified firmware introduced during manufacturing, shipping, or at a supplier. Harder to pull off than software attacks and rarer, but high impact when it happens because it sits below the operating system.

Third-party and service compromise. A SaaS provider, managed service provider, or contractor with access to your environment is breached, and the attacker uses that trusted access to pivot into you. The supplier is the entry point; you are the target.

Why the supply chain attack surface keeps growing

The exposure is not a fluke of a few bad incidents. It is structural, and three shifts drive it.

First, software is assembled, not written. A typical application is overwhelmingly open-source and third-party code, often with hundreds or thousands of transitive dependencies, components pulled in not by your developers but by the components your developers chose. Each one is a link in the chain, and most go unexamined.

Second, the cloud and SaaS turned vendors into operators inside your environment. A SaaS provider holds your data. An identity provider authenticates your users. A CI/CD platform builds and signs your code. Each integration is trusted access that an attacker can inherit by compromising the provider instead of you.

Third, attackers follow leverage. Compromising one widely used vendor or library yields access to thousands of downstream targets at once, which is a far better return than attacking each target individually. That economics is why supply chain attacks have moved from rare to routine, and why a single upstream compromise now shows up as a data breach across an entire customer base.

The consequence for a defender is the same as it is for any unmanaged exposure: you cannot defend what you cannot see. An undocumented dependency, an unvetted vendor with API access, an update channel nobody monitors. These are the supply chain equivalent of the forgotten internet-facing host, and they fail the same way.

The software bill of materials: knowing what you run

You cannot secure a supply chain you cannot inventory, and the foundational control is a software bill of materials (SBOM): a formal, machine-readable list of every component, library, and dependency inside a piece of software, including the transitive ones. It is the ingredient label for code.

An SBOM is what turns the next zero-day in a common library from a frantic, manual hunt into a query. When the next XZ-style flaw lands in a widely used component, the organizations that can answer "where do we run this, and which version" in minutes are the ones with current SBOMs for everything they build and consume. The ones without spend days grepping through build systems trying to figure out whether they are exposed at all. The standard SBOM formats, SPDX and CycloneDX, exist so this inventory can be generated, shared, and consumed by tooling automatically rather than maintained by hand.

SBOMs moved from best practice to expectation after the SolarWinds breach. US Executive Order 14028 (2021) directed federal agencies and their software suppliers toward providing SBOMs, which pulled the practice into the commercial mainstream because vendors selling to the government had to comply.

The supply chain security lifecycle

Supply chain security runs as a continuous loop, for the same reason attack surface management does: your dependencies and vendors change constantly, and a one-time review describes a supply chain that no longer exists.

Map and inventory. Build the picture of what you depend on. Generate SBOMs for the software you build and the software you consume, and maintain an inventory of third-party vendors and services along with the access each one holds. You cannot assess or monitor a dependency you have not catalogued.

Assess and vet. Judge the risk of each link. For software components, that means checking for known vulnerabilities, maintainer health, and provenance. For vendors, it means security reviews, certifications, and contractual controls before granting access. This is where you decide how much to trust each supplier and what controls that level of trust requires.

Verify integrity. Confirm that what you received is what the supplier actually published, and that it was built the way it claims. Verify signatures, check artifact hashes, and where available consume build provenance attestations so a tampered or substituted artifact is rejected before it ever runs.

Monitor continuously. Watch the chain for change and new risk: a newly disclosed CVE in a dependency you ship, a vendor that suffers a breach, a package that changes maintainers or behavior. A newly exposed dependency is a detection input for the SOC, not just a backlog item.

Respond. When an upstream compromise lands, the SBOM and vendor inventory turn the response from guesswork into scoping. Identify which systems run the affected component or depend on the breached vendor, contain them, patch or replace, and revoke any trust the attacker may have inherited.

Controls and frameworks that govern it

Several controls do the practical work of securing a supply chain, and several frameworks tell you how to organize them.

On the control side: maintain SBOMs so you know your components; scan dependencies continuously for known vulnerabilities and tie that into your vulnerability management program; verify the integrity and provenance of artifacts before they run; harden the build pipeline itself, since the pipeline is the target in update-poisoning attacks; vet vendors before granting access and constrain that access to least privilege; and pin and review dependencies rather than pulling the latest of everything by default.

On the framework side, three are worth knowing:

• NIST SP 800-161 Rev. 1, "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations," is NIST's primary guidance for C-SCRM. It frames supply chain security as risk management across the full system lifecycle and is the reference most US programs build against.
• SLSA (Supply-chain Levels for Software Artifacts), currently at version 1.2, is a framework for build integrity. It defines build levels L0 through L3, from no guarantees (L0) through provenance exists (L1) and a hosted build platform that signs provenance (L2) to a hardened build platform with strong tamper protection (L3). It gives teams a concrete ladder for hardening the build pipeline.
• Executive Order 14028 (2021) is the policy lever that pushed SBOMs and software supply chain requirements into the federal procurement process, and through it into the wider market.

How supply chain security fits exposure management

Supply chain security is one face of exposure management. Exposure management is the discipline of finding and reducing everything that exposes an organization to attack, and your suppliers and dependencies are exactly that: exposure you do not directly control. The mindset is the same as attack surface management, applied to the parts of your operation that other people own.

The connection to the SOC is concrete. The vendor and dependency inventory is detection and triage context. When a widely used library lands a critical CVE or a vendor announces a breach, the SOC's first question is "are we affected, and where," and the SBOM and vendor inventory answer it. A newly disclosed upstream compromise is a detection-worthy event in its own right, fed alongside the SOC's other threat monitoring. Tie that to cyber threat intelligence on which suppliers and components are being actively targeted, and supply chain risk becomes something you prioritize like any other exposure, rather than something you only learn about when the breach notification arrives.

Frequently Asked Questions

What is supply chain security in simple terms?

Supply chain security is the practice of securing the software, hardware, vendors, and services your organization depends on but does not directly control. The goal is to manage the risk that an attacker compromises one of those upstream dependencies and uses that trusted relationship to reach you, the way the SolarWinds attackers reached 18,000 organizations through a single vendor update.

What is the difference between supply chain security and a supply chain attack?

A supply chain attack is the threat: an attacker compromising a trusted upstream party (a vendor, an open-source library, a build pipeline) to reach the targets downstream. Supply chain security is the defensive discipline that manages that risk by inventorying dependencies, vetting suppliers, verifying integrity, and monitoring the chain for change. One is the attack; the other is the program that defends against it.

What is a software bill of materials (SBOM)?

A software bill of materials is a formal, machine-readable list of every component, library, and dependency inside a piece of software, including transitive ones. It is the ingredient label for code. When a new vulnerability appears in a common library, an SBOM lets you answer "where do we run this, and which version" in minutes instead of days. The standard formats are SPDX and CycloneDX.

What are the most common types of supply chain attacks?

The most common are compromised software updates (malware inserted into a vendor's signed update, as in SolarWinds), malicious or backdoored open-source components (as in the XZ Utils backdoor), dependency confusion and typosquatting in public package registries, hardware or firmware tampering during manufacturing, and the compromise of a third-party vendor or service provider that has trusted access to your environment.

What frameworks govern supply chain security?

NIST SP 800-161 Rev. 1 is the primary US guidance for cybersecurity supply chain risk management (C-SCRM). SLSA (Supply-chain Levels for Software Artifacts), currently version 1.2, provides build-integrity levels L0 through L3 for hardening the build pipeline. US Executive Order 14028 (2021) pushed SBOM and software supply chain requirements into federal procurement and, through that, into the broader market.

How does supply chain security relate to exposure management?

Supply chain security is a component of exposure management. Exposure management finds and reduces everything that exposes an organization to attack, and dependencies and vendors are exposure you do not directly control. The same continuous discover-assess-prioritize-monitor mindset applies, and the dependency and vendor inventory feeds the SOC the context it needs to triage upstream compromises quickly.

Can you prevent supply chain attacks entirely?

No, because you cannot fully control or verify code and systems other people own. The realistic goal is to reduce the risk and shrink the blast radius: know what you depend on through SBOMs and a vendor inventory, vet and constrain each link, verify integrity before artifacts run, and monitor continuously so that when an upstream compromise happens, you can detect it and scope your exposure fast rather than learning about it from the breach notification.

The bottom line

Supply chain security is the practice of managing the risk you inherit from everything you depend on but do not control: the third-party code, the open-source libraries, the build pipelines, the hardware, and the vendors with access to your environment. The threat is structural, not incidental, because software is assembled from other people's components and attackers go where the leverage is, and a single upstream compromise, SolarWinds or XZ Utils, reaches everyone downstream at once.

The defense is the same loop you apply to any exposure, adapted to assets someone else owns: map what you depend on with SBOMs and a vendor inventory, assess and vet each link, verify integrity and provenance, and monitor continuously. NIST SP 800-161 frames the risk management, SLSA hardens the build, and the SBOM is the inventory that turns the next big upstream flaw from a multi-day scramble into a query. For an exposure-management program, supply chain security is the part that accounts for the risk living outside your perimeter.