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.
Key takeaways
Supply chain security protects every stage from source code and dependencies through build, registry, and production deployment.
Modern software is assembled from hundreds of packages, and any one can introduce vulnerabilities that propagate downstream.
Effective programs start with trusted content (verified images, signed artifacts, SBOMs) enforced at every pipeline stage.
Treat supply chain security as an infrastructure discipline, not a compliance checkbox, to catch threats early and respond faster.
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.
Principle
What this means in practice
Verify, don’t assume
Every component, dependency, and artifact should be cryptographically verified before it’s consumed. Build verification into the pipeline rather than relying on assumptions about source integrity, maintainer identity, or registry trustworthiness.
Start with trusted content
The base images and packages at the foundation of your supply chain determine the security posture of everything built on top of them. Hardened, minimal, provenance-verified base images reduce the attack surface at the root.
Verify at every transition
Each time an artifact moves from one stage to another (source to build, build to registry, registry to deploy), verify its integrity. Signing, attestation, and hash verification at transition points prevent tampered artifacts from propagating.
Generate transparency artifacts automatically
SBOMs, provenance attestations, and vulnerability scan results should be generated automatically as part of the build process, not manually or after the fact.
Enforce policy at the infrastructure level
Supply chain security policies (which registries are allowed, which images can be deployed, what vulnerability thresholds are acceptable) should be enforced by infrastructure, not by process documentation.
Minimize the blast radius
Assume that some component will eventually be compromised and design your pipeline to limit the damage. Least-privilege access, isolated build environments, and runtime sandboxing reduce the impact of any single compromise.
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
What is software supply chain security?
Software supply chain security is the practice of protecting every component and process involved in building and delivering software. This includes the source code, open source dependencies, build systems, container images, registries, and deployment pipelines. The goal is to ensure that every artifact deployed in production is exactly what it claims to be, has not been tampered with, and is free of known vulnerabilities. It’s a lifecycle discipline, not a single tool or checkpoint.
Why is software supply chain security important?
Modern software is assembled from hundreds or thousands of open source components, each with its own maintainers, vulnerabilities, and update cadences. A single compromised component can propagate through the entire delivery pipeline and into production. Supply chain attacks have increased significantly because they allow attackers to reach many downstream organizations by compromising a single upstream dependency or build system.
What is the difference between software supply chain security and application security?
Application security focuses on vulnerabilities in the code your team writes: injection flaws, authentication bugs, authorization issues. Supply chain security focuses on everything your code depends on and everything that touches it on the way to production. The distinction matters because most code in a modern application is not written by the team deploying it. It’s pulled in from open source libraries, base images, and system packages.
What is an SBOM and why does it matter for supply chain security?
An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in a software artifact. It matters because you cannot secure what you cannot see. SBOMs enable automated vulnerability scanning, license compliance checking, and rapid incident response when a new vulnerability is disclosed. When generated automatically with every build and attached to the artifact, they provide a continuous transparency layer across the entire supply chain.
How do container images relate to supply chain security?
Container images are the primary delivery artifact in containerized supply chains. They bundle application code with all of its dependencies, making them a complete representation of everything that will run in production. This makes image security a central supply chain concern: the base image you start from, the packages you add, and how the image is signed, stored, and verified all directly impact supply chain integrity.
What frameworks should I follow for software supply chain security?
The most widely adopted frameworks are SLSA (Supply-chain Levels for Software Artifacts) for build integrity, NIST SSDF (SP 800-218) for secure development practices, and the OpenSSF Scorecard for evaluating open source dependencies. Executive Order 14028 mandates NIST SSDF alignment for federal software suppliers, and its requirements are increasingly adopted as industry standards.
Quelle: https://blog.docker.com/feed/
