We spent the week at AI Engineer World’s Fair in San Francisco, on stage and on the floor. Here’s what we heard, and where we think it lands for anyone building with agents.

The SDLC is being rebuilt in public

This week at AIE felt like a synthesis of what’s been playing out in developer tools for the last few years, for anyone who’s been watching. The software development lifecycle is reshaping itself into an AI-native SDLC, and the industry is naming the new jobs and developer concerns that come with this rapid transformation.

The proof was in the track list: Evals, Context Engineering, Harness Engineering, Memory, Sandbox & Platform Engineering, Inference, plus a whole thread on “software factories.” Two years ago most of these phrases were far from being thought of as categories. Now each one is a discipline with its own sessions, its own vocabulary, and its own crop of companies on the expo floor built to solve that single problem.

So what were most talks about? A little bit less of “can agents and AI do this,” and more of “given this way of building, what decisions and trade offs do we need to think about?” Evals, loops, harnesses, context, memory, isolation, cost. None of this is brand-new, but it’s all getting a whole new level of mindshare, as developers work out the new shape of creating software with AI. Even the model labs spent much of their stage time on how you build with the model: the integration API, the harnesses, the ergonomics, rather than the model itself. 

The job we care most about: securing where agents run

Of all those emerging disciplines, sandboxing is the one that hit critical mass this year. There was a full track dedicated to sandbox and platform engineering, and the sessions inside it were still working out what a sandbox should even be: full VM, lightweight runtime, Kubernetes, something purpose-built. Talks focused on concerns such as running agentic sandboxes at scale and comparing isolation technologies head to head. 

This is the job Docker showed up to talk about, across three sessions.

Give agents more freedom by giving them less surface

Our EVP of engineering, Tushar Jain, gave the mainstage talk: “Unlock Agent Autonomy: The Runtime for AI-Native Systems.” The actors have changed – agents read and write whole codebases, spawn subagents, install dependencies, and call APIs across laptops, CI, cloud, and org boundaries, often unsupervised. Teams leaning into this shift are moving fast, but most organizations still won’t let agents run autonomously, not because the model isn’t capable, but because trust isn’t there yet. This thinking draws on a concept security researcher Simon Willison has written about, the “lethal trifecta”: any useful agent tends to end up with access to private data, exposure to untrusted content, and the ability to act in the outside world, all three, by design. No prompt or policy doc gets rid of that. The durable fix lives one layer down, at the runtime, which is where we spent the last decade: isolation, network policy, trusted images, credentials. Agents are just the next workload.

An agent doesn’t have to be malicious to be dangerous

Rowan Christmas, a staff product manager at Docker, made the risk concrete. In “YOLO Mode, Safely: microVM Sandboxes for Any Agent,” he ran a coding agent on his own laptop with nothing but read access, and no sandbox or unusual permissions. Within a few minutes it had pieced together a surprising amount about his online banking activity from what it could passively see. A destructive command like rm -rf is the obvious fear, but the mundane can bring risk: read access, plus untrusted content, plus the ability to act, is already enough to do damage. An agent doesn’t have to be malicious to expose you. It just has to be able to see. The alternative Rowan showed puts each session in its own Docker sandbox based on a microVM, with a boundary you define across filesystem, network, and tools. It can run Claude Code, Cursor, Codex, or whatever you’re driving.

Once an agent can install packages, run Docker, and reach the network, which describes most genuinely useful agents, a hardware boundary buys you something you can’t easily bolt on later. And where much of the scale conversation is cloud-first, built for fleets of agents running server-side, Docker’s approach starts first on the laptop the developer already uses, because that’s where most people actually run agents today. (We go deeper on the reasoning in “Why microVMs” and our comparison of sandboxing approaches, including what the isolation costs you, because it isn’t free.)

Nobody’s reviewing what your agents just installed

The third talk covered the tool layer. Jim Clark, a principal software engineer on our MCP team, spoke about “Who Approved That MCP Server? Governing the Tool Layer,” and opened with a line that got knowing laughs: “shadow MCP”. Developers install MCP servers faster than security can review them, and an unvetted server is a direct line to your data. That worry was all over the event, not just our session. Jim’s demo put every server behind one org-managed catalog, vetted, signed, default-deny on anything unapproved, with the policy enforced live on stage.

Where this leaves us

So how does it come together? An agent is only as trustworthy as the boundaries around it, and those boundaries live in three places: what it builds on, where it runs, and what it can reach. Miss any one of them and the other two won’t cover for you. A hardened image dependency is no help if the agent can still read your whole filesystem unsandboxed, and a locked-down sandbox is no help if the agent can call an unvetted MCP server straight out of it.

That was the case Docker made all week: harden what agents build on, isolate where they run, control what they can reach, and govern all three from one place. We think this is the part that has to be solved first, because it’s where AI-native developers will start building the apps of the future.

Further reading: 

• Docker Sandboxes run standalone (brew install docker/tap/sbx)
• Docker AI Governance ties sandbox and MCP policy into one console.
• MCP Catalog, Toolkit, and Gateway are in Docker Desktop today
• Docker Hardened Images are a drop-in change to your FROM line

According to Omdia’s 2026 software supply chain security report, 86% of organizations find SBOM generation challenging. A major driver is tool sprawl: teams cobbling together different scanners for different artifact types, getting inconsistent output across pipelines, and spending engineering time reconciling the results rather than acting on them.

SBOMs have become important to how security teams respond to vulnerability disclosures, how compliance teams satisfy auditors, and how procurement decisions get made. That makes the generation step load-bearing. If the SBOM your pipeline produces misses transitive dependencies, records declared versions instead of resolved ones, or is not cryptographically bound to the artifact it describes, every downstream decision built on that data inherits the gap.

This post covers the decisions that determine SBOM quality: when and where to generate, what separates actionable output from data that just checks a box, and how to keep generation reliable as your image portfolio grows.

When to generate: Build-time vs. post-build

The single decision that most affects SBOM quality is when you generate it. There are two broad approaches, and they produce meaningfully different results.

Build-time generation

Build-time generation hooks into the build system itself. The generator has access to the resolved dependency tree, the package manager files, and the full build context. It knows exactly what went into the artifact because it was present when the artifact was assembled.

Container build systems with native attestation support can produce an SPDX SBOM during the image build, attach it as an in-toto attestation, and push both the image and the SBOM to the registry in a single operation. Language-specific build plugins take a similar approach for application dependencies, generating SBOMs as part of the standard build lifecycle.

The advantage is structural: build-time generation captures the resolved state of every dependency, including transitive dependencies that post-build scanners may miss.

Post-build scanning

Post-build tools scan a finished artifact and reverse-engineer its contents. They work by identifying package manager metadata, file signatures, and known patterns within the artifact. This approach works on any OCI-compatible image, regardless of how it was built.

The trade-off is coverage. Statically linked binaries, vendored dependencies, and OS packages installed in intermediate build stages may commonly be missed by post-build scanners. The scanner can only report what it can detect, and detection is heuristic-based rather than derived from the actual build graph.

For container images, our documentation covers how to configure build-time SBOM attestation in detail, including the specific flags and generator options for different build workflows.

What makes an SBOM useful

Generating an SBOM is not the same as generating a useful one. The file format is standard, but the quality of the content varies dramatically depending on how and when the SBOM was produced. Five criteria separate actionable SBOMs from checkbox artifacts.

1. Completeness

A complete SBOM accounts for every component in the artifact across all layers and all package types. This includes OS packages from the base image, application dependencies from every package manager in the build, and any tooling or utilities added during the build process. 

This is where multi-stage and minimal base images create real gaps. A Dockerfile with a Node frontend, a C or C++ component compiled into a static binary, and a distroless final stage presents three distinct challenges: the Node layer has deep transitive dependency trees, the statically linked binary often carries no dependency manifest on disk, and the distroless base has no package manager at all. Post-build scanners can miss the statically linked dependencies and may undercount the Node tree. Build-time generation with access to each stage’s resolved dependency graph is the only way to get a complete picture.

2. Accuracy

Accuracy means the SBOM records resolved versions, not declared ranges. A package manifest might declare “^4.17.0” but the resolved version in the lock file is 4.17.21. The SBOM must reflect what was actually installed, not what was requested.

3. Freshness

An SBOM is a point-in-time snapshot tied to a specific build. Every time the artifact is rebuilt, the SBOM should be regenerated. Stale SBOMs create a false sense of visibility.

4. Verifiability

A verifiable SBOM is one that consumers can confirm was produced by the build system and has not been tampered with. Cryptographic signing and attestation frameworks bind the SBOM to a specific artifact digest, along with build provenance that records where and how the artifact was built.

5. Format compliance

Standard formats like SPDX and CycloneDX define required and optional fields. An SBOM that validates against the schema is interoperable across scanning tools, policy engines, and compliance workflows. One that does not may work with your current tools but will break when you change them.

Some base images already ship with SBOMs that meet all five criteria, along with SLSA Build Level 3 provenance and exploitability data. These SBOMs were generated at build time on hardened build platforms with non-falsifiable provenance, cryptographically signed, and attached as in-toto attestations bound to the image digest. They are continuously regenerated with every rebuild, so freshness is maintained without manual intervention. For those images, the generation question is answered for the most critical layer of the stack, and your effort shifts to generating a complete SBOM for the application layer you add on top.

Your generation toolchain is attack surface

The tools you use to generate SBOMs run with elevated access to your build environment. They read your source code, your dependency trees, and your build artifacts. A compromised generator does not just produce bad output; it has the access to exfiltrate or modify what it scans.

This is not a theoretical concern. Version tags on GitHub Actions and container images are mutable. A tool you pinned to v2.1 today can silently become something different tomorrow if a maintainer account is compromised or a tag is force-pushed. The exposure window for incidents like these is typically measured in hours, but automated pipelines can pull compromised versions within minutes.

Treat your generation tooling with the same rigor you apply to any other build dependency:

• Pin to immutable references (commit SHAs, not version tags).
• Verify checksums before execution.
• Run generation in CI, not on developer machines, for reproducible and auditable output.
• Monitor for upstream security advisories on your generation tools.

This is one dimension of a broader software supply chain security challenge: every tool in your pipeline is a dependency that needs the same scrutiny as your application code. For base images, you can sidestep this risk entirely. Images built on hardened build platforms with non-falsifiable provenance carry their supply chain metadata from the point of origin, cryptographically verified end-to-end.

Integrating SBOM generation into CI/CD

Manual SBOM generation works for one-off audits. For production workflows, generation needs to be automatic, reproducible, and wired into the rest of your delivery pipeline. The pattern is consistent across CI systems.

Generate at build

Add SBOM generation as a build stage step, immediately after the image is produced. For container images, BuildKit attestation flags are the most reliable approach. For application dependencies, language-specific plugins (CycloneDX for Maven/Gradle, npm/yarn for Node) produce the highest-quality output because they access the resolved dependency graph.

For multi-stage builds, generate from the final stage only. Intermediate stages often install build tools and test frameworks that do not ship in the production image. Generating against intermediate stages inflates the SBOM with components that are not deployed, creating noise in vulnerability scans.

Choose an attestation format

SPDX is the native output format for BuildKit attestation and the stronger choice if license compliance is a primary concern. CycloneDX has richer vulnerability correlation support and more granular component classification, making it the better fit for security-focused workflows. If your consumption tools (policy engines, vulnerability scanners, compliance dashboards) have a preference, follow it. If they support both, default to SPDX for container images since it requires no additional tooling beyond BuildKit’s built-in generator.

Attach to the artifact

Store the SBOM alongside the artifact it describes. For container images, this means attaching it as an OCI attestation in the registry rather than saving it as a separate file in an artifact store. Attestation-based storage keeps the SBOM discoverable, versioned, and bound to the specific image digest. When the image is promoted from dev to staging to production, the SBOM travels with it through every registry, rather than requiring a separate copy-and-sync workflow that inevitably drifts.

Validate before publishing

Add a validation step between generation and registry push. Run the SBOM through a format validator (SPDX and CycloneDX both provide official schema validators), check that the component count is reasonable for the artifact, and verify that the SBOM references the correct image digest. A build that produces 12 components for an image you know contains 200+ packages should fail the pipeline, not ship silently.

Scan and enforce continuously

SBOM generation at build time captures what’s shipped. Continuous scanning tells you what’s become vulnerable since. New CVEs drop daily, and an SBOM that was clean at build time can have critical exposures within weeks. Continuous analysis against SBOM data matches new disclosures against your inventory without re-pulling images, and surfaces policy violations as they emerge. With SBOMs attached to every image, you can gate deployment: no image ships without a valid SBOM, no image deploys with a known-vulnerable package above your severity threshold.

Implementation details vary by CI system. Our documentation covers the specific flags and configuration for generating and attaching SBOM attestations across common container build workflows.

Verifying your SBOM output

Before relying on your SBOM output for compliance reporting or vulnerability management, verify that it meets the quality criteria below.

• Component count sanity check: Compare the number of components in your SBOM against what you expect from the Dockerfile, lock files, and base image. A Node.js app with 200 declared dependencies should produce substantially more entries once transitive dependencies are included.
• Resolved versions, not ranges: Spot-check entries to confirm the SBOM records specific versions (4.17.21) rather than declared ranges (^4.17.0).
• Transitive dependency depth: Verify that transitive dependencies appear, not just top-level packages. If your app declares 30 direct dependencies but the SBOM contains 32 entries, transitive coverage is likely incomplete.
• OS package coverage: Confirm that base image OS packages appear alongside application dependencies.
• Digest binding: Verify the attestation references the correct image digest. An unbound SBOM cannot be trusted to describe its artifact.
• Format validation: Run the SBOM through a schema validator (SPDX and CycloneDX both provide official tools).

Start generating, then start verifying

The best time to add SBOM generation to your pipeline is the next time you touch your CI configuration. Start with your highest-traffic production image. Configure build-time generation, attach the SBOM as an attestation, and validate the output against the checklist above. Then expand to the rest of your portfolio.

If you want a head start, Docker Hardened Images ship with complete SBOMs, SLSA Build Level 3 provenance, and OpenVEX data already attached, so you can skip the generation step for your base layers entirely. For everything you build on top, Docker Scout provides continuous vulnerability matching against your SBOM data and enforces policies across your image portfolio.

• Get started with Docker Hardened Images →
• Explore vulnerability monitoring with Docker Scout →

Frequently asked questions

Sources

Omdia, Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption, May 2026.

In Omdia’s 2026 software supply chain security report, 73% of organizations that generate SBOMs say they enable more efficient vulnerability mitigation, yet 86% still find the generation process challenging. That gap between recognized value and operational difficulty is where most teams are stuck. For teams building and securing containerized applications, understanding what an SBOM is, and how to make it useful, is no longer optional.

This guide covers what SBOMs contain, why they matter for software supply chain security, how standard formats and tooling work, and where the industry is headed with regulations and enforcement.

What is an SBOM?

Every software artifact ships with dependencies. A container image based on Alpine Linux might include dozens of system packages, each with its own version, license, and upstream maintainer. An application layer on top adds frameworks, libraries, and transitive dependencies that the developer may never have explicitly chosen. The deeper the stack, the harder it becomes to answer a basic question: what is actually running in production?

A software bill of materials answers that question. It’s a structured, machine-readable inventory of every component, library, and module inside a software artifact. Where a package manifest like package.json or requirements.txt lists declared dependencies, an SBOM captures the resolved dependency tree after the build, including transitive dependencies, system-level packages, and metadata about each component’s origin, version, and license. Think of it as a nutrition label for software.

What an SBOM contains

A well-formed SBOM includes several categories of metadata for each component:

• Component identity: Package name, version, and supplier (e.g., openssl 3.1.4, maintained by the OpenSSL Project)
• Licensing: The license type governing redistribution and use (MIT, Apache 2.0, GPL)
• Dependency relationships: How components depend on each other, including direct and transitive dependencies
• Unique identifiers: Package URLs (purl) or SWID tags that enable cross-referencing against vulnerability databases
• Checksums and digests: Cryptographic hashes that let consumers verify the component has not been tampered with
  This data is structured using open standards, primarily SPDX or CycloneDX, to keep it machine-readable and interoperable across tools, registries, and compliance workflows. In practice, an SPDX SBOM entry for a single package looks like this:

{
  "name": "openssl",
  "SPDXID": "SPDXRef-Package-openssl",
  "versionInfo": "3.1.4",
  "supplier": "Organization: OpenSSL Project",
  "licenseDeclared": "Apache-2.0",
  "checksums": [{ "algorithm": "SHA256", "value": "a1b2c3..." }]
}

A real SBOM contains one entry like this for every component in the artifact, from the base image’s OS packages up through the application’s runtime dependencies.

Why SBOMs matter for software supply chain security

The value of an SBOM becomes clear the moment something goes wrong. When the Log4Shell vulnerability was disclosed in December 2021, organizations with current SBOMs could query their inventories and identify every affected image within minutes. Teams without them spent days manually tracing dependencies across registries and deployment manifests.

Sonatype’s research found that nearly 65% of open source CVEs lack an NVD-assigned CVSS score, and when scored independently, 46% turned out to be high or critical. Without an SBOM, those unscored vulnerabilities are invisible.

Faster incident response

When a new CVE drops, the first question is always where are we exposed? An SBOM makes that question answerable in seconds rather than days. Cross-reference the affected package and version against your SBOM library, and you have an immediate blast radius. Pair the SBOM with continuous vulnerability scanning and the process becomes automated: new CVEs are matched against existing SBOMs, and affected images are flagged without manual intervention.

Customer spotlight: JWP, a video streaming platform serving more than 1 billion users, enabled vulnerability scanning across 400+ repositories in under an hour. With SBOMs feeding their scanning pipeline, the team fixed thousands of vulnerabilities while filtering out tens of thousands of non-critical issues, reducing noise and accelerating remediation.

Regulatory compliance

SBOMs are moving from best practice to legal requirements. In the United States, Executive Order 14028 helped set SBOM requirements in motion for software sold to federal agencies. CISA’s 2025 Minimum Elements guidance aims to clarify what a useful SBOM should include. The EU Cyber Resilience Act (EU CRA) extends similar requirements to products sold in the European market. For organizations operating in regulated industries, finance, healthcare, defense, and critical infrastructure, SBOM delivery is becoming a procurement gate.

Proactive verification, not reactive trust

SBOMs shift the security model from assuming software is safe to verifying that it is. Rather than trusting that a base image is clean because the registry says so, teams can inspect the SBOM to confirm which packages are present, which versions are running, and whether any known vulnerabilities apply.

In practice, that means writing policies against SBOM data: no image ships if it contains a package from an unapproved supplier, no end-of-life component persists past a defined grace period, no image deploys without a matching SBOM attestation. These checks can run automatically in CI, turning the SBOM from a passive document into an active gate.

When combined with provenance attestations and cryptographic signatures, the SBOM becomes one layer in a verifiable chain of custody from source to deployment. You’re no longer taking the registry’s word for it. You’re cryptographically verifying it.

SBOM formats and standards

For an SBOM to be useful across teams, tools, and organizations, it needs a shared language. Two open standards dominate the landscape, each designed for a different primary use case.

SPDX (Software Package Data Exchange)

Developed by the Linux Foundation (ISO/IEC 5962:2021), SPDX is the most widely adopted format for license compliance and open source auditing. It is also the format used by BuildKit’s built-in SBOM generator, which attaches an SPDX document as an attestation to the container image during the build.

CycloneDX

Developed by the OWASP Foundation, CycloneDX is optimized for security workflows and DevSecOps pipelines. It includes fields for vulnerability metadata and dependency graphs, and integrates well with tools like OWASP Dependency-Track.

SBOM Formats at a Glance

If you’re building container images, start with SPDX. It’s the format BuildKit generates natively, so you get an SBOM as a build output with zero additional tooling. Your downstream scanning tools may prefer CycloneDX, and that’s fine. The two formats are interoperable, and converters exist for moving between them. Let the build produce SPDX; let consumption tools handle conversion if they need it.

How SBOMs fit into container workflows

In traditional software development, SBOMs are often generated after the fact, bolted on as a compliance artifact during release. Container workflows offer a better approach: generating the SBOM at build time, as a native output of the image build process.

Build-time generation

When you build a container image with BuildKit, the builder scans the final image filesystem and produces an SBOM that reflects what actually shipped, not just what was declared in the Dockerfile. Because it captures the resolved state after all build stages complete, it includes OS-level packages, application-level dependencies, and any files copied from external sources.

Source-level SBOMs, generated from manifest files before the build, frequently miss transitive dependencies and system packages. An image-layer SBOM reflects reality.

Attestation and provenance

An SBOM tells you what’s in an image. Provenance attestations tell you how it was built: which builder, which source commit, which build platform. Together, they form a verifiable chain of evidence that auditors and policy engines can evaluate programmatically. This is the model described by SLSA (Supply-chain Levels for Software Artifacts), where Build Level 3 requires hardened build platforms with non-falsifiable provenance. SLSA is the specification; in-toto is the attestation format it uses.

The SBOM itself is attached to the image as an in-toto attestation using the SPDX predicate format. Provenance is attached the same way, so both travel with the image as verifiable, machine-readable metadata.

Registry storage

Once the image and its attestations are built, they need to live somewhere consumers can access them. Pushing the image to an OCI-compliant registry keeps the SBOM co-located with the artifact it describes. This matters because an SBOM that lives in a separate system, a shared drive, a compliance portal, or a CI artifact bucket, will eventually drift out of sync with the image it was generated from. Co-location eliminates that gap: pull the image, and you pull its SBOM and provenance with it.

Continuous scanning

With SBOMs attached to images and stored in a registry, they become inputs for continuous vulnerability monitoring. New CVEs are matched against the components listed in the SBOM without re-analyzing the image itself. Instead of re-scanning every image when a new vulnerability is disclosed, the scanner cross-references the SBOM inventory and flags affected images immediately.

Policy enforcement

Scanning identifies risk. Enforcement acts on it. Policy engines can consume SBOM data to gate deployments based on rules the team defines: no image ships if it contains a package from an unapproved supplier, no end-of-life component persists past a defined grace period, no image deploys without a matching SBOM attestation.

These checks run automatically in CI, turning the SBOM from a passive document into an active gate. You’re no longer relying on manual review to catch a problematic dependency. The pipeline catches it before the image reaches production.

SBOM maturity: Where does your organization stand?

SBOM adoption isn’t binary. Most organizations fall somewhere on a spectrum from ad hoc to fully scaled. The following maturity model helps teams assess where they are and what to prioritize next.

Omdia’s 2026 software supply chain security survey surfaced that more than half of the organizations generating SBOMs are only generating them on a case-by-case basis. 

Common misconceptions about SBOMs

SBOMs are just a compliance checkbox

Teams that generate SBOMs solely to satisfy a procurement requirement are missing the operational value. SBOMs are most useful as a live data source for vulnerability management, incident response, and dependency tracking. A one-time SBOM generated for an audit and then filed away provides a false sense of coverage.

They’re the same as SCA

Software composition analysis (SCA) tools scan code or images for known vulnerabilities. An SBOM is the inventory that makes that scanning possible. SCA and SBOMs generally work together. The SBOM is the inventory, and SCA tools use that inventory, often generating their own, to check for known vulnerabilities. The distinction matters because scanning tends to be only as good as the inventory behind it.

SBOMs are a one-time artifact

An SBOM is tied to a specific image digest. Every time you rebuild an image, the SBOM should be regenerated to reflect any dependency changes. Stale SBOMs create a gap between what you think is running and what’s actually deployed. Automated build-time generation eliminates this drift.

SBOMs substitute runtime security

SBOMs tell you what shipped. They do not tell you what’s happening at runtime. An SBOM will not catch a zero-day that hasn’t been disclosed yet, detect anomalous process behavior inside a running container, or verify that the application logic is correct. SBOMs are one layer in a defense-in-depth model: they handle inventory and composition. Runtime monitoring, network policies, and access controls handle the rest.

What can go wrong without SBOMs

Let’s say a zero-day vulnerability is disclosed in a widely used library. Without SBOMs, the security team starts a manual triage: checking Dockerfiles, querying registries, asking developers which versions they use. Hours pass. Some images are missed because the affected package is a transitive dependency three levels deep. By the time the blast radius is mapped, the vulnerability has been public for two days.

With SBOMs attached to every image, the same triage takes minutes. Query the SBOM database for the affected package and version, get a list of every image that includes it, and prioritize remediation based on deployment context.

Getting started with SBOMs

The most common mistake teams make is treating SBOM adoption as a large-scale transformation project that’ll derail workflows. It doesn’t need to be.

• Start with one image. Pick a production image and enable SBOM generation on the next build. With BuildKit, that is a single flag:

Review the output. This single step often reveals transitive dependencies and OS packages you did not know were in the image.

• Automate generation in CI. Extend the flag to your CI pipeline so every image build produces an SBOM automatically.
• Store SBOMs alongside images. Attach SBOMs as attestations in your OCI registry so the SBOM stays co-located with the artifact it describes.
• Connect to monitoring. Feed SBOMs into a vulnerability monitoring tool that can continuously match components against new CVEs. This closes the loop between inventory and action.
• Set policies. Define what is acceptable: maximum CVE age, required minimum SBOM completeness, blocked licenses. Enforce these policies in the pipeline so non-compliant images are flagged before deployment.

Build with visibility, ship with confidence

SBOMs are the foundation of software supply chain security. They turn opaque software artifacts into transparent, auditable inventories that security teams, compliance officers, and developers can all use. But an SBOM alone is not enough. The real value comes when SBOMs are generated at build time, paired with provenance attestations, and continuously monitored against emerging threats.

Docker makes this workflow native. Docker Hardened Images ship with complete SBOMs, SLSA Build Level 3 provenance, OpenVEX exploitability data, and cryptographic signatures on every image. Meanwhile, Docker Scout provides continuous vulnerability monitoring powered by the SBOM data attached to your images, surfacing actionable insights across your entire image portfolio. Together, they give teams a verifiable chain of custody from source to production, with no manual assembly required.

Frequently asked questions

Source

Omdia, Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption, May 2026.

TLDR: Docker Content Trust (DCT) and the Notary v1 service at notary.docker.io are being fully retired (first announced in July of 2025). This blog explains what is changing, who is affected, and how to move to modern alternatives. 

Ten years ago, Docker Content Trust (DCT) gave the container ecosystem one of its first ways to verify the integrity and publisher of an image, built on The Update Framework and the Notary v1 project. The upstream Notary v1 codebase is no longer maintained, more modern signing tools have become the standard, and today a very small number (fewer than 0.05%) of Docker Hub pulls rely on DCT.

Last year we began retiring DCT for Docker Official Images, and now we’re completing that work by fully retiring DCT and the Notary v1 service at notary.docker.io. This post covers what’s changing, who’s affected (for most people, nothing), and the modern alternatives that are available to users.

Why are we retiring Docker Content Trust (DCT)?

DCT relies on the upstream Notary v1 server, the original TUF-based implementation that was first released in 2015, and the project is no longer maintained. In the years since, the ecosystem has standardized on OCI-native signing tools such as Sigstore/Cosign and the Notary Project’s Notation, that store signatures alongside the image in any compliant registry, with no separate trust infrastructure to run. The broader ecosystem has been retiring this approach–Microsoft deprecated DCT support in Azure Container Registry some time ago, and Harbor deprecated Notary v1 support too.

Retiring Notary v1 lets us put our investment behind other modern, standards-based tools (described below) that developers are already adopting, and behind making secure defaults first-class citizens on Docker Hub.

Who is affected by this change?

DCT was opt-in, and normal image pulls (docker pull) would not touch the Notary service, so if you’ve never deliberately turned it on, nothing about your workflow changes. You can stop reading here.

The change matters if you configured DCT for use, which usually shows up in one of a few ways:

• You have DOCKER_CONTENT_TRUST=1 set in your environment, shell profile, CI pipeline, or Dockerfile.
• Your scripts or automation use docker trust sign, docker trust inspect, or docker trust revoke.
• Your Kubernetes admission controllers or deployment policies check for DCT signatures.
• You publish images to Docker Hub with DCT signing enabled.

If you have never set DOCKER_CONTENT_TRUST and do not use docker trust commands, this change does not affect you. 

Pathway to retirement: timeline

We’re winding DCT down in stages rather than all at once. The brownouts are brief, scheduled outages, these are dry runs that flush out any pipeline still leaning on the service while there’s time to fix it. Writes go dark before reads, so signing breaks before verification and publishers can get the earliest heads-up.

Windows run ~4 hours and begin at 8AM Pacific Time.

Note this only touches DCT trust operations; ordinary docker pull and docker push operations will keep working through these windows.

What to do if you are affected: migration guide and alternatives

If any of the cases above describe your setup, here’s how to move off DCT cleanly. The ecosystem has settled on a handful of strong, widely-adopted tools, so this is as much a menu as a manual. The steps run from the quickest unblock to the most complete setup; pick the leading technology that fits your workflow, and go as far down the list as your situation calls for.

Ensuring image pulls succeed

If your only goal is to ensure that image pulls keep working past the shutdown date, disable DCT. This is the fastest path to unblocking your workflows, but it removes tag-level verification. 

# Remove from your current shell session
unset DOCKER_CONTENT_TRUST

# Or explicitly disable it
export DOCKER_CONTENT_TRUST=0

Search your environment for anywhere this variable might be set, including shell profiles, CI/CD configuration, Compose files, and K8s manifests. Once DCT is disabled, all pulls continue to work normally.

Ensuring pulls are repeatable

Tags on image registries can change when an image is updated. Pulling by digest guarantees that you get the exact image content you expect, regardless of whether a tag has been moved or overwritten. Digests are immutable.

# Find the digest of an image you have pulled
docker pull busybox:latest
docker images --digests busybox
# REPOSITORY   TAG       DIGEST                                                                    IMAGE ID
# busybox      latest    sha256:f85340bf...   abc123def456

# Pull by digest 
docker pull busybox@sha256:f85340bf... 

Use digests in dockerfiles for reproducible builds, and in Kubernetes manifests or Compose files to ensure predictable deployments. 

Digest pinning verifies content integrity (you get exactly what you asked for), but it does not by itself prove publisher identity. For that, you need cryptographic signatures, which is where Sigstore/Cosign and Notation come in.

Proving publisher identity

Two mature, actively maintained signing projects have replaced DCT’s signing capabilities in Hub. Both store signatures alongside the image in OCI-compliant registries.

Option A: Sigstore / Cosign

Cosign is part of the Sigstore project and supports identity-based signing using short-lived certificates tied to an OIDC identity. It stores signatures as OCI artifacts in the same registry, alongside the image. 

• Sigstore quickstart: https://docs.sigstore.dev/quickstart/quickstart-cosign/ 
• Cosign on GitHub: https://github.com/sigstore/cosign 

Option B: Notation

Notation is the CLI for the Notary Project. It uses a certificate-based PKI model and stores signatures as OCI reference artifacts. 

• Notation quickstart: https://notaryproject.dev/docs/quickstart/ 
• Notation on GitHub: https://github.com/notaryproject/notation

Enforcing verification in production

Signing images is only half the story. To get full security benefits, you need to enforce that only signed images can be deployed.

Kyverno (works with Cosign)

Kyverno can verify Cosign signatures before pulling into a cluster. See the documentation for details. 

Ratify + Gatekeeper (works with Notation)

Ratify can verify Notation signatures before admitting pods. See the Ratify quickstart for setup instructions.

Use Docker Hardened Images as a built-in replacement

If you currently rely on DCT to verify base images from Docker Hub, switching to Docker Hardened Images (DHI) is a free and secure path forward. Every DHI comes with cryptographic signatures, provenance attestations, and SBOMs already built in.

This means the integrity checks you relied on with DCT are guaranteed, and then some. DHI images are minimal by design and continuously rebuilt when new CVEs appear. You are not just replacing a verification mechanism, you are getting a more secure base image to begin with.

• Read more here: https://docs.docker.com/dhi/ 
• Or view the free catalog at dhi.io

Need help?

A couple of things worth knowing as you plan your move.

If you are a Docker Hub publisher currently signing images with DCT, Docker cannot provide replacement signatures on your behalf. You will need to adopt Cosign or Notation to sign your own images.

If you are a consumer of third-party images that were signed with DCT, contact those publishers directly to determine whether they plan to adopt modern signing.

For questions or issues related to the shutdown, or if you want to work more directly with us on a migration plan, contact Docker support.

The obvious takeaway from 2026’s biggest incidents is that attackers are increasingly using AI to move fast. Docker’s CISO, Mark Lechner, wrote about this shift and what every engineering team should do now.

What worries us is that the bar is about to drop further. For most of the last decade, finding a serious vulnerability in widely used open source took time and specialized skill. Frontier models now read code, reason across dependencies, and surface novel, chained vulnerabilities at machine speed, including flaws that survived years of expert review. Anthropic’s Mythos, and the more powerful models that follow it will find more vulnerabilities, faster, and by a wider margin than skilled humans could. The gap between a vulnerability being discovered and exploited has shrunk from years to hours, and a growing share are weaponized before they are ever public.

We believe the durable response in this reality is twofold: build products that are secure and transparent by default, and collaborate deeply across the ecosystem to share signals and intelligence. No single vendor sees the whole picture, and customers are best protected when supply chain technologies work together rather than in isolation.

Secure-by-default tools for devs, as AI embeds into the SDLC

As coding agents take on more of the software lifecycle, secure defaults have to cover more than what you build with. They have to cover where agents run and what they can reach. Today, Docker’s investment spans three areas covering sandboxes for local developers, secure dependencies, and governed access to vetted MCP tools. These capabilities and our upcoming products in the near future collectively help secure the developer environment as AI embeds itself into the SDLC:

Isolated, sandboxed execution for agents: Docker Sandboxes run AI coding agents in isolated microVMs, each with its own kernel, filesystem, and deny-by-default network, so a compromised dependency an agent pulls cannot reach the host, its credentials, or other workloads.

Trusted, open source foundations: Docker Hardened Images Community is free and open source under Apache 2.0. DHI are minimal, low-CVE images rebuilt from source with SLSA Build Level 3 provenance and signed SBOMs, built on Alpine and Debian. The catalog now spans over 3,500 hardened images and tens of thousands of hardened system packages, extending across container images, system packages, Helm charts, and MCP servers. DHI makes secure dependencies the easy, default choice.

Governed access to tools: Docker MCP Catalog and Gateway give agents a trusted, hardened set of MCP servers, plus centralized policy, secret blocking, and audit logging, so the connections agents make are verified rather than assumed.

Together these tools give developers a secure default from the first docker build through to the agent running in their environment. 

Working with the ecosystem on behalf of every developer

The second part of our approach is how we work with the ecosystem. For example, with the axios compromise earlier this year and the TeamPCP campaign, Docker worked with partners including Socket, the Trivy team, Checkmarx, and others to analyze the attacks and contain the blast radius (recap). The damage potential with these attacks could have been very large, however sharing signals across company lines, in real time, is what kept the blast radius relatively small. We have said it before, this is a posture we believe the ecosystem needs more of.

Docker is joining the Athena alliance

Athena is the next step in our journey of collaboration. Announced today, it is an industry coalition for the coordinated defense of open source software in the era of AI-accelerated vulnerability discovery, and Docker is a founding participant. Athena brings together organizations from across the software ecosystem to share findings and coordinate responses before vulnerabilities become public. Docker sits at a distinctive point in the supply chain, with millions of developers relying on us to build, distribute, and run software built on open source, so helping make that ecosystem more resilient is consistent with our mission. We look forward to working with the coalition on key ways in which Docker is uniquely placed to provide expertise and scale to this important cross-industry effort.

Further reading

• Docker Sandboxes
• Docker Hardened Images
• Defending your software supply chain (Docker CISO Mark Lechner)

Understanding software supply chain security is one thing. Putting it into practice across a real pipeline, with real deadlines and real constraints, is another. Most organizations recognize that their software supply chain is a growing attack surface, but translating that awareness into concrete, repeatable practices is where the work gets difficult.

But why should your team tackle this now? According to Sonatype, over 99% of open source malware identified in 2025 occurred on npm. And the first self-replicating npm worm emerged, spreading autonomously across developer environments and compromising hundreds of packages within days. Meanwhile, Verizon’s 2025 Data Breach Investigations Report found that the share of breaches involving third parties doubled year-over-year to 30%.

This guide focuses on those practices that matter most for teams building and shipping container-based workloads. It’s organized around five categories that follow the natural flow of software delivery: trusted content, build security, pre-deployment verification, access and policy controls, and continuous monitoring. This way, your team can be better equipped to protect your software supply chain in the wake of increasingly automated and sophisticated attacks.

1. Start with trusted content

Choose verified, minimal base images

Every container image inherits the security posture of its base image. If that foundation contains unpatched vulnerabilities, outdated libraries, or components you do not need, those risks propagate into every image built on top of it. The first and highest-leverage supply chain practice is selecting base images that are minimal, continuously maintained, and verifiably built. 

Look for base images that ship with complete SBOMs, provenance attestations at SLSA Build Level 3, and cryptographic signatures you can verify before deployment. Minimal images reduce attack surface by removing shells, package managers, and utilities that production workloads rarely need but attackers frequently exploit.This is where hardened, provenance-verified base images become a foundational practice. Rather than maintaining custom hardening scripts for each base image, teams can start from images that are rebuilt from source with full transparency into how they were produced.

Pin dependencies and verify integrity

Dependency pinning is a deceptively simple practice that prevents a category of supply chain attacks. When a Dockerfile references a tag like python:3.12, that tag can point to a different image digest tomorrow than it does today. A compromised or accidental change upstream flows silently into your builds.

Pin container images by SHA256 digest, not by tag. Pin language-level dependencies (npm, pip, Maven) to exact versions with lock files, and verify the integrity of those lock files in CI. If your build system pulls a dependency and the hash does not match what was committed, the build should fail.

• Scenario spotlight: Consider a team that builds nightly from a :latest-tagged base image. One morning, a routine build deploys to staging and integration tests start failing. The root cause: an upstream package update in the base image introduced a breaking change. With digest pinning and explicit upgrade workflows, this class of problem disappears entirely, and so does the more dangerous variant where a malicious change slips in unnoticed.

2. Secure the build pipeline

Enforce build provenance and attestation

Build provenance answers a question that SBOMs alone cannot: where was this artifact built, by what system, and from what source? Without provenance, you can verify what’s in an image but not whether the build environment itself was trustworthy.

The SLSA framework defines progressive levels of build integrity, from basic provenance documentation at Level 1 through hardened, tamper-resistant build platforms producing non-falsifiable provenance at Level 3. At minimum, builds should generate signed provenance attestations that link every artifact back to its source commit, build configuration, and builder identity.

In practice, this means configuring your CI/CD system to produce SLSA provenance attestations (typically expressed using the in-toto attestation format) alongside every image build. These attestations become the cryptographic evidence that your deployment policies can verify before allowing an image into production.

Harden CI/CD infrastructure

The build pipeline itself is a high-value target. If an attacker compromises your CI/CD system, they can inject malicious code into every artifact you produce, and your existing checks may not catch it because the malicious modification happens after the source code review.

Key hardening practices include:

• Isolate build environments so each job runs in a fresh, ephemeral context with no residual state from previous builds.
• Limit the secrets available to build jobs to the minimum required.
• Pin GitHub Actions and other CI plugins to full commit SHAs rather than mutable tags.
• Enforce branch protection rules that require code review and passing status checks before any merge to a release branch.

CISA emphasizes build system integrity as a foundational element of supply chain assurance. If you cannot trust the system that produced an artifact, no amount of post-build scanning will compensate.

3. Verify before you deploy

Generate and consume SBOMs continuously

A software bill of materials is only useful if it’s accurate, current, and integrated into your decision-making. Generating an SBOM once at release time and filing it away satisfies a compliance requirement but provides minimal security value.

The more effective practice is generating SBOMs at every build, attaching them to the image as attestations, and consuming them downstream in admission controllers, vulnerability scanners, and license compliance checks. When a new CVE drops, teams with current SBOMs can determine in minutes which running workloads are affected. Teams without them start a multi-day forensic exercise.

Pairing SBOMs with exploitability data (VEX) adds another layer of actionability. VEX documents indicate whether a vulnerability in your SBOM is actually exploitable in the context of your specific image, reducing the noise that causes alert fatigue and helps teams focus remediation on the vulnerabilities that actually matter.

Integrate vulnerability analysis into developer workflows

Vulnerability scanning is most effective when it surfaces results where developers are already working, not in a security dashboard that gets checked once a sprint. Shifting analysis into the inner development loop means flagging issues at build time, in pull requests, and during local development, well before an image reaches a registry.

This is where continuous vulnerability analysis integrated into the developer workflow becomes essential. Rather than batching scan results into weekly reports, effective programs surface findings alongside the code change that introduced them, with actionable remediation guidance.

The NIST Secure Software Development Framework (SSDF) reinforces this pattern. Practice PW.7 recommends that organizations review and analyze human-readable code to identify vulnerabilities and verify compliance with security requirements. Automated analysis integrated into CI/CD is the scalable implementation of that guidance.

4. Control access and enforce policy

Manage registry access and image policies

Your container registry is the distribution point for every image your organization runs. If developers can pull any image from any public registry without restriction, the supply chain extends to every maintainer of every image they choose to use.

Implement registry access controls that restrict which images are approved for use, enforce that all images come from verified publishers or internal builds, and require signature verification before any image enters production. Image access management policies ensure that teams can experiment freely in development while production environments consume only vetted, policy-compliant images.

• Scenario spotlight: Medplum, a healthcare developer platform helping customers meet HIPAA and HITRUST requirements, migrated their container foundation to Docker Hardened Images with just 54 lines added and 52 removed across their codebase. The result was a dramatically reduced CVE count, non-root execution by default, and no shell access in production. They also got a cleaner story to tell their auditors. Instead of explaining custom hardening scripts and per-CVE exception documentation, the team can point to documented hardening methodology and SLSA Build Level 3 provenance.

Apply least privilege across the pipeline

Supply chain attacks frequently exploit over-permissioned service accounts, CI tokens with broad scope, or shared credentials that provide more access than any single job requires. Applying least privilege to your delivery pipeline means scoping every credential, token, and API key to the minimum permissions needed for its specific task.

CISA specifically recommends phishing-resistant multi-factor authentication on all developer and CI/CD accounts. Beyond authentication, ensure that build service accounts cannot push to production registries, that deployment tokens cannot modify build configurations, and that no single credential grants access to both source code and production infrastructure.

5. Monitor, respond, and improve

Implement runtime monitoring

Static analysis and build-time scanning catch the threats you anticipate. Runtime monitoring catches the ones you did not. When a supply chain compromise makes it past your pre-deployment controls, runtime anomaly detection is the layer that identifies unexpected behavior: new network connections from a container that should not make outbound calls, file system modifications in an immutable image, or process execution patterns that diverge from the image’s normal profile.

Effective runtime monitoring for supply chain security goes beyond traditional application performance monitoring. It requires baseline behavioral profiles for your container workloads and alerting that triggers on deviation, not just on known-bad signatures. This is particularly important for detecting compromised dependencies that behave normally during testing but activate malicious behavior under specific runtime conditions.

Build incident response into your supply chain program

When a supply chain incident occurs, response speed depends on preparation. Teams that have practiced their response to a compromised dependency, a malicious base image update, or a build system breach respond in hours. Teams that have not practiced these scenarios scramble for days.

Your incident response plan should include procedures for:

• Identifying which artifacts were produced from compromised components (this is where provenance and SBOMs pay for themselves)
• Revoking and rotating credentials that may have been exposed
• Rebuilding affected images from verified sources
• Communicating with downstream consumers of your software

Best practices at a glance

Getting started

Building a software supply chain security program is iterative work. The practices in this guide represent the larger picture, but the path there is incremental. Start with the foundation: trusted base images and dependency integrity. Layer in build provenance and SBOMs. Then expand into policy enforcement, developer-integrated scanning, and runtime monitoring as your program matures.

Docker Hardened Images provide a ready-made foundation for teams implementing these practices. Thousands of minimal, continuously rebuilt images ship with SLSA Build Level 3 provenance, signed SBOMs, and OpenVEX exploitability data, giving you a trusted starting point without the overhead of maintaining custom hardening pipelines. An independent assessment by SRLabs validated DHI’s provenance chain, signing model, and vulnerability management workflow, and continuous hardening practices. 

Pair that with Docker Scout for continuous vulnerability analysis integrated directly into your development workflow, and you have the core tooling to support a supply chain security program that scales with your engineering organization.

• Explore our full catalog of hardened images and start replacing your base images today.
• Download our white paper for more on securing your software supply chain.

Frequently asked questions

When security teams scan their container environments for the first time, they often discover hundreds of known vulnerabilities, and almost none of them trace back to application code.

The overwhelming majority come from packages that shipped with the base image: shells, compilers, debug utilities, and libraries the application never calls. In a software supply chain built on containers, the base image is the foundation. If that foundation ships with unnecessary components, every workload built on top of it inherits the risk.

Hardened images address this software supply chain security problem at the source. They are purpose-built base images stripped down to only the runtime components an application needs, continuously patched, and shipped with verifiable metadata that lets security teams confirm exactly what is inside and how it was built.

Why standard container images carry hidden risk

A general-purpose base image like a standard Linux distribution might ship with 400 or more installed packages. A typical containerized application uses 20 to 30 of them. The rest are inherited baggage: package managers, text editors, network diagnostic tools, documentation files, and libraries for use cases the container was never intended to serve.

Each of those unused packages is a potential attack surface. Vulnerability scanners flag them because they are genuinely present in the image, even if the application never imports or executes them. The result is a signal-to-noise problem that burns through security team capacity. When a team faces 200 findings and 80% of them exist in packages no running workload touches, the real vulnerabilities that need immediate attention get buried in triage.

The packages themselves are the other half of the problem. A shell in a production container gives an attacker an interactive environment to work from if they achieve initial access. A package manager lets them install additional tooling. Debug utilities help them map the network and identify lateral movement targets. None of these belong in a production container, but they ship by default in most general-purpose base images, quietly expanding the blast radius of any breach.

What makes a container image “hardened”

So what are hardened images in practice? Minimization gets the most attention, but it’s only one of three requirements. A genuinely hardened image is also continuously maintained and independently verifiable.

Minimized attack surface

The most visible characteristic of a hardened image is minimization. Shells, package managers, and debug tools are removed. Only the runtime components the application needs to function are included. This is more aggressive than simply choosing a slim base image variant. Hardened images are often rebuilt from the package level up, selecting each component deliberately rather than subtracting from a general-purpose distribution.

The result is a dramatically smaller CVE surface. Where a general-purpose image might carry hundreds of known vulnerabilities, a hardened equivalent for the same runtime typically carries single digits or none.

Continuous patching and rebuilds

A hardened image that’s never updated becomes a snapshot of the day it was built. An image hardened on Tuesday can start drifting by Friday: three upstream CVEs published, two library patches released, and the image is already accumulating the kind of exposure it was designed to prevent.

Security requires ongoing maintenance: monitoring upstream projects for fixes, rebuilding images to incorporate patches, and doing this on a defined cadence with clear SLAs. The best hardened images are rebuilt continuously, not on a quarterly or release-driven schedule. That’s what separates production-grade hardened images from one-time efforts to slim down a Dockerfile.

Verifiable supply chain metadata

This is where hardened images connect to the broader supply chain security best practices that organizations are adopting. A truly hardened image ships with:

• Software Bills of Materials (SBOMs) that list every package, version, and dependency in the image
• Build provenance attestations aligned to frameworks like SLSA, providing cryptographic proof of how and where the image was built
• Vulnerability Exploitability eXchange (VEX) data that identifies which CVEs present in the image are not exploitable given how the software is actually configured
• Cryptographic signatures that verify the image has not been tampered with between build and deployment

This metadata is what makes automated policy enforcement possible in CI/CD pipelines. A CI gate that blocks deployments unless the base image has a signed SBOM and valid provenance attestation is only feasible when the image provider builds that metadata into the supply chain from the start. For organizations operating in regulated environments, it’s also what allows security and compliance teams to verify an image without reverse-engineering its contents.

Container hardening vs. VM hardening

The term “hardened image” appears in both container and virtual machine contexts, but the two practices address different layers of the stack.

• VM hardening focuses on OS configuration: disabling unnecessary services, tightening firewall rules, restricting user permissions, and tuning kernel parameters. Defined by frameworks like CIS Linux Benchmarks. Takes a full operating system and locks it down.
• Container hardening operates at the image layer: what is packaged (minimization), how the image was assembled (provenance), and whether the contents are transparent (SBOMs and vulnerability data). Starts from a minimal foundation and builds up only what the application requires.

Both practices are valid and often coexist. Many organizations apply VM hardening to their container host nodes and container hardening to the images running on those nodes. They complement each other, but the techniques, tooling, and evaluation criteria are different. A CIS-hardened AMI and a hardened container base image solve distinct problems at distinct layers.

How to evaluate hardened images

Not all images marketed as hardened meet the same standards. When evaluating options, look for these characteristics:

• Transparency: Can you see every package in the image? Is there a complete, machine-readable SBOM?
• Provenance: Can you independently verify how and where the image was built? Are attestations signed and aligned to a recognized framework?
• Patch cadence: How quickly are upstream security fixes incorporated? Is there a defined SLA, or is patching best-effort?
• Compatibility: Do the images work as drop-in replacements in existing Dockerfiles and CI/CD pipelines, or do they require workflow changes?
• Vulnerability data integrity: Does the provider suppress or filter CVE data to make the image look cleaner, or do they publish full vulnerability transparency with exploitability context?

The answers to these questions separate genuinely hardened images from images that are simply minimal. Minimization is necessary but not sufficient. Without provenance, patching discipline, and transparency, a small image is just a smaller attack surface with less visibility.

What hardened images are not

The term “hardened” is sometimes applied loosely. Because of this, it’s worth clarifying what does not qualify, because each of these approaches solves part of the problem while leaving the rest exposed.

1. Choosing a slim or Alpine variant reduces image size, but it does not address provenance, patching cadence, or supply chain metadata. The image is smaller, not hardened.
2. Running a scanner and manually removing flagged packages produces a point-in-time fix, not a continuously maintained hardened image. The next upstream CVE puts you back where you started.
3. Building a distroless image from scratch achieves minimization but requires significant ongoing effort to maintain patch currency across every image in a portfolio. Without a defined rebuild cadence and verifiable metadata, the maintenance burden scales with the number of images.

Hardening, in the supply chain security sense, means all of these concerns are addressed systematically: the image is minimal, maintained, and verifiable.

Getting started with hardened images

Hardened container images are becoming the standard foundation for secure container deployments. They address the root cause of most container vulnerability findings: unnecessary packages inherited from general-purpose base images. And with verifiable supply chain metadata, they give security teams the transparency and audit trail that modern compliance requirements demand.

Docker Hardened Images provide this foundation across several thousand images spanning runtimes, frameworks, databases, and infrastructure components. Every image ships with SBOMs, SLSA Build Level 3 provenance, VEX data, and cryptographic signatures. The Community tier is free and open under Apache 2.0 with no restrictions on use or redistribution.

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

Frequently asked questions

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