What is Software Supply Chain Security?

Software supply chain attacks have accelerated faster than most security teams anticipated. Sonatype’s 2026 State of the Software Supply Chain report identified more than 454,000 new malicious packages published to open source repositories in 2025, bringing the cumulative total to over 1.2 million since 2019. The blast radius keeps expanding as organizations consume more open source software, ship more container-based workloads, and distribute software through increasingly complex pipelines.

Software supply chain security is the discipline of protecting every component, process, and system involved in building and delivering software, from the source code developers write to the dependencies they pull in, the build systems that compile and package their code, the registries that store their artifacts, and the infrastructure that runs those artifacts in production. It’s a lifecycle concern, not just a deployment-time check.

What makes this discipline distinct from traditional application security is the scope. Application security focuses on the code your team writes. Supply chain security focuses on everything your code depends on, and everything that touches your code on its way to production. For container-based delivery pipelines, that means every base image, every package, every build tool, and every registry interaction is part of the attack surface.

Why software supply chain security matters now

The urgency behind software supply chain security is driven by a structural shift in how software is built. Modern applications are overwhelmingly assembled from existing components rather than written from scratch. A typical container image contains hundreds of packages, each with its own dependency tree, maintainers, and update cadence. Every one of those components is a trust decision, and most organizations are making those trust decisions implicitly rather than deliberately.

The dependency problem is a trust problem

When a developer adds a package to a project, they’re trusting that the package does what it claims, that the maintainers are who they say they are, the package registry has not been compromised, and the package will continue to receive security updates. Multiply that trust decision across every dependency in every container image across an organization, and the scale of implicit trust becomes clear.

Attackers have recognized that compromising a single widely used package can give them access to thousands of downstream organizations. Techniques like dependency confusion, typosquatting, and maintainer account takeovers have become standard tools in the attacker playbook. The impact of software supply chain attacks extends well beyond the initial compromise, propagating downstream through every organization that consumes the affected component. The software supply chain has become the preferred vector precisely because the trust relationships are implicit and the verification infrastructure is often absent.

Containers changed the attack surface

Container security has always been a multi-layered concern, but containerization accelerated the supply chain security challenge in ways that are still catching up with many organizations. A container image is a complete, immutable software artifact that bundles application code with its operating system dependencies, runtime, and configuration. That immutability is a security advantage because what you test is exactly what you deploy. But it also means every vulnerability in every layer of that image ships to production unless you’re actively scanning, verifying, and updating.

The container registry has become one of the most critical points in the supply chain. It’s where images are stored, distributed, and pulled for deployment. If an attacker can push a tampered image to a registry, or trick a deployment pipeline into pulling an unverified image, the compromise reaches production without triggering any code-level security controls. Registry security, image signing, and pull policies are supply chain security concerns that did not exist before containerized delivery became the default.

Regulatory pressure is accelerating

Government and industry mandates are making supply chain security a compliance requirement, not just a best practice. Executive Order 14028 on Improving the Nation’s Cybersecurity requires US federal software suppliers to meet specific supply chain security standards, including SBOM generation and secure development practices. The NIST Secure Software Development Framework (SSDF) provides the reference architecture. And SLSA (Supply-chain Levels for Software Artifacts) offers a graduated framework for verifying that artifacts were built securely.

These frameworks are not just government requirements. They’re shaping procurement standards across industries. Modern software is overwhelmingly assembled from open source components, and those components frequently carry known vulnerabilities. Organizations that cannot demonstrate supply chain integrity through provenance attestations, SBOMs, and verifiable build processes are increasingly locked out of enterprise and public-sector contracts.

How software supply chain security works

Supply chain security is not a single tool or practice. It’s a set of controls applied at every stage of the software delivery pipeline. Each stage has distinct attack surfaces and requires specific protections.

Securing source code and dependencies

The supply chain starts where the code starts. Source code repositories need access controls, commit signing, and branch protection rules that ensure only authorized changes make it into the codebase. But the bigger risk is usually in dependencies, not the first-party code itself.

Dependency management for supply chain security goes beyond keeping packages updated. It includes verifying that packages come from trusted sources, that they have not been tampered with since publication, and that their transitive dependencies (the packages your packages depend on) are also trustworthy. Lockfiles, hash verification, and dependency pinning are baseline controls. Private registries and curated package feeds add a layer of organizational control over what enters the dependency tree.

Securing the build process

The build system is where source code and dependencies are transformed into deployable artifacts. A compromised build environment can inject malicious code into every artifact it produces, regardless of how clean the source code is. Build integrity means running builds in isolated, ephemeral environments that start clean every time, producing provenance attestations that record exactly what was built, with what tools, from what source, and generating SBOMs that provide a complete inventory of every component in the final artifact. It’s one of the hardest stages to secure because the compromise is invisible at the source code level.

SLSA framework levels provide a useful maturity model here. At SLSA Build Level 3, the build process runs on a hardened build platform, the provenance is non-falsifiable, and the build platform isolates each build to prevent tampering between runs. This is where hardened, provenance-verified images become essential, providing cryptographic proof of how each image was produced.

Securing container images and registries

Container images are the primary delivery artifact in modern supply chains, which makes image security a central supply chain concern. Securing images starts with the base image. If the foundation is unverified, outdated, or bloated with unnecessary packages, every image built on top of it inherits those risks.

Trusted base images are minimal, regularly rebuilt against upstream security fixes, and distributed with verifiable provenance. They come with SBOMs that document every package included, vulnerability scan results that are transparent rather than suppressed, and cryptographic signatures that let consumers verify the image has not been tampered with since it was built. 

That transparency distinction matters: some image providers suppress or downplay vulnerability data to make their scan results look cleaner. A genuinely trusted image shows you everything, including what has not been patched yet, so your team can make informed decisions rather than operating on incomplete information.

Registry security involves controlling who can push and pull images, enforcing image signing policies, scanning images for vulnerabilities before they are deployed, and maintaining audit trails of every registry interaction. Organizations that treat their container registry as a trusted source of truth rather than a dumping ground for artifacts are materially better positioned to prevent supply chain compromises.

Securing deployment and runtime

The final stages of the supply chain are deployment and runtime. Deployment controls ensure that only verified, signed images from trusted registries are pulled into production environments. Admission controllers, image verification policies, and deploy-time SBOM checks create enforcement points that prevent unverified artifacts from reaching production.

Runtime security adds the last layer of defense. Even with a fully secured build and deployment pipeline, runtime monitoring detects anomalous behavior that might indicate a compromised component: unexpected network connections, unusual file system access, or processes that should not be running. Sandboxed execution environments provide isolation that limits the blast radius if a compromised component makes it past earlier controls.

The role of SBOMs in supply chain security

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in a software artifact: packages, libraries, versions, licenses, and their relationships. In the context of supply chain security, SBOMs serve as the transparency layer that makes everything else possible. You cannot verify what you cannot see, and SBOMs make the contents of software artifacts visible.

What distinguishes SBOMs as a supply chain security tool from SBOMs as a compliance artifact is how they’re generated and used. A compliance-oriented SBOM is generated once, filed away, and referenced during audits. A security-oriented SBOM is generated automatically with every build, attached to the artifact it describes, and consumed by automated tools that check for known vulnerabilities, license conflicts, and policy violations before the artifact reaches production. As GitHub’s analysis of vulnerability trends shows, the volume of published CVEs continues to grow each year, making automated SBOM-driven scanning essential rather than optional.

The most effective supply chain security programs treat SBOMs as living artifacts that travel with the software they describe. When a new vulnerability is disclosed, the SBOM lets you answer immediately: are we affected, where, and in which deployed artifacts? That response time is the difference between a controlled remediation and a scramble. For a deeper look at implementation, see our guide on software supply chain security best practices.

4 Common software supply chain attack vectors

Understanding how supply chains are attacked is essential to understanding how to defend them. Attack vectors target different stages of the pipeline, and each requires specific controls.

1. Dependency-based attacks

These target the packages and libraries your software depends on. Dependency confusion exploits the way package managers resolve names, tricking build systems into pulling a malicious public package instead of a legitimate private one. Typosquatting registers packages with names similar to popular libraries, banking on developer typos. Maintainer account takeovers compromise the credentials of a trusted package maintainer and push malicious updates through the legitimate distribution channel.

2. Build system compromises

Attackers who compromise a build system can inject code into every artifact it produces. This is particularly dangerous because the source code remains clean, and code review will not catch the compromise.

3. Image and registry attacks

Container-specific attack vectors include pushing tampered images to public registries, creating malicious images with names that mimic popular official images, and exploiting misconfigured registry access controls to replace legitimate images with compromised ones. Organizations without image signing verification and registry access management policies are particularly vulnerable to these vectors.

4. CI/CD pipeline exploitation

CI/CD pipelines often have elevated privileges (access to secrets, deployment credentials, production environments) that make them high-value targets. Attackers exploit pipeline configurations to exfiltrate secrets, modify build outputs, or inject steps that execute during otherwise legitimate workflows.

The rise of AI coding agents adds a new dimension to this threat: agents that generate code or modify dependencies can introduce supply chain risks at machine speed if they are not operating within secure, isolated environments. Poisoned pipelines are especially dangerous because they can produce artifacts that pass all automated security checks while carrying malicious payloads.

Core principles of software supply chain security

Effective supply chain security programs share a set of principles that guide both technical implementation and organizational culture.

Building a software supply chain security program

Moving from ad hoc security practices to a structured supply chain security program involves layering controls at each stage of the pipeline. The goal is not to implement everything at once but to establish a foundation and build on it as the organization matures.

1. Establish a trusted image foundation

The single highest-leverage action most organizations can take is to control what goes into their base images. If developers are pulling arbitrary images from public registries without verification, every other supply chain security investment is built on an unstable foundation.

A trusted image foundation means maintaining a curated set of approved base images that are minimal (reducing attack surface), regularly rebuilt (incorporating upstream fixes), and distributed with provenance attestations and SBOMs. 

The good news is that you do not have to build this from scratch. Hardened, continuously rebuilt base images with SLSA Build Level 3 provenance and full vulnerability transparency can be used as drop-in replacements for standard images, so teams can adopt them without reworking existing CI/CD pipelines.

2. Implement SBOM generation and consumption

SBOMs should be generated automatically as part of every build pipeline, attached to the artifacts they describe, and consumed by automated tools that check for vulnerabilities and policy violations. The two standard SBOM formats, SPDX and CycloneDX, are both widely supported by scanning and policy tools. Choose one and standardize across the organization.

3. Deploy image signing and verification

Image signing creates a cryptographic chain of trust between the entity that built an image and the environment that deploys it. Signing keys should be managed centrally, signing should happen automatically as part of the build pipeline, and verification should be enforced at deployment time through admission controllers or registry policies. If an image is not signed by a trusted key, it should not reach production.

4. Enforce registry and image access policies

Control which registries developers and deployment pipelines can pull from. Block access to unapproved public registries and enforce policies that require images to come from verified sources. For Docker Desktop, Registry Access Management provides these controls, ensuring policies are enforced consistently across developer workstations, not just in CI/CD.

5. Integrate vulnerability scanning into the pipeline

Scanning should happen at multiple points: 

• When dependencies are added
• When images are built
• When images are pushed to registries
• On a continuous basis for deployed artifacts

The goal is to catch vulnerabilities as early as possible in the pipeline, when remediation is cheapest and least disruptive. You’ll want continuous vulnerability analysis integrated directly into the developer workflow so issues are surfaced where engineers can act on them, rather than buried in a security dashboard that rarely gets checked.

6. Establish incident response for supply chain compromises

Supply chain incidents are different from typical security incidents because the compromise often originates outside the organization. Your incident response plan should account for scenarios where a trusted dependency is compromised, where a base image contains a newly disclosed vulnerability, or where a build system produces artifacts that cannot be verified. 

The faster you can identify which deployed artifacts are affected (this is where SBOMs pay for themselves), the faster you can respond.

Where does your supply chain security stand?

Supply chain security maturity varies widely across organizations. Use this self-assessment to identify where your organization falls and what to prioritize next.

Frameworks and standards

Several frameworks provide structured approaches to supply chain security. They’re complementary rather than competing, and mature organizations typically align with multiple frameworks.

SLSA (Supply-chain Levels for Software Artifacts)

SLSA provides a graduated framework for verifying the integrity of software artifacts. Its build levels establish increasingly rigorous requirements for how artifacts are produced, from basic build provenance at Level 1 to hardened build platforms with non-falsifiable provenance at Level 3. SLSA is particularly valuable because it translates abstract supply chain security goals into concrete, verifiable technical requirements.

NIST SSDF (Secure Software Development Framework)

The NIST SSDF (SP 800-218) provides a comprehensive set of secure development practices organized around four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. It’s the primary reference framework for federal software supply chain requirements under Executive Order 14028.

OpenSSF Scorecard and GUAC

The Open Source Security Foundation provides tools for evaluating the security posture of open source projects (Scorecard) and for aggregating and querying supply chain metadata (GUAC, Graph for Understanding Artifact Composition). These tools help organizations make informed decisions about which open source components to trust.

Getting started

Supply chain security is an infrastructure discipline. The organizations that approach it as a set of pipeline controls rather than a compliance checklist are the ones building the most resilient software delivery systems. The practices in this guide are designed to be layered incrementally. If your organization is starting from scratch, begin with the highest-leverage action: establish a trusted image foundation. Control what goes into your base images, generate SBOMs automatically, and enforce verification at every pipeline stage from there.

Docker Hardened Images provide a production-ready foundation with SLSA Build Level 3 provenance, continuous vulnerability monitoring, and cryptographic signatures that verify integrity from build to deployment. Combined with Docker Scout for continuous vulnerability analysis and Registry Access Management for policy enforcement, teams can create an infrastructure layer for supply chain security across their full delivery pipeline.

Explore our full catalog of hardened images and start replacing your base images today.

Frequently asked questions