The hardened-images space gets better when more people are working on the problem, and Minimus has been a valuable part of that work. That changed this week, when they announced they are ending operations. Though we were competitors, we both believed strongly in the importance of reducing vulnerabilities at the foundation of the software supply chain. Their efforts to bring needed awareness to this challenge will be missed, and our thoughts go out to Minimus employees who are impacted by this decision.

While the human side of this story deserves the most attention, there’s also a practical side: if you’re a customer running Minimus images in production, you’re now facing a migration you didn’t plan for. Their notice commits to a 60-day maintenance window, with images receiving upstream updates until the registry goes offline on October 22, 2026. Images already pulled will keep running after that date, but no further updates will ship to them, and any new CVE stays unpatched from that point on.

If you need a hand, Docker is offering free migration assistance to Minimus customers. Write to minimus@docker.com to walk through your specific image list, your compliance requirements, or questions around your migration plans, and a technical migration expert will get back to you. You don’t need a sales call to start migrating to DHI today.

Docker’s free, open source catalog is available to everyone under Apache 2.0, allows production use, and has no user caps. The migration is about as easy as these things get, a drop-in with minimal workflow changes. It’s more of a swap than a rebuild. It’s easy to find your images’ equivalents in the DHI catalog, and for most of your services, the whole change is updating the FROM line. Use the migration guide for the step-by-step process and the checklist to track each image through the swap and verification. The worked examples show full migrations end to end, and Gordon, Docker’s AI assistant, runs the first pass with you.

Whether you decide to migrate to Docker or somewhere else, we recommend you start that process now, while the maintenance window keeps your current images patched. You can browse the full DHI catalog on Docker Hub, make the first swap, and, of course, reach out to us if you need help.

Docker Hardened Images

Docker Hardened Images are minimal, hardened images built from source and continuously maintained by Docker. The catalog covers 4,000+ images, compatible with Alpine and Debian, so your Dockerfiles and CI keep working as they are. Every image ships near-zero CVEs with full, unsuppressed CVE visibility, and each carries a complete SBOM, SLSA Build Level 3 provenance, and cryptographic signatures. Docker manages the full lifecycle of your image, and teams moving from standard public images see up to 95% CVE reduction and up to 90% attack-surface reduction. Paid tiers add SLA-backed remediation, FIPS and STIG variants, customizations, and up to five years of coverage for versions past end of life.

Everyone has been talking about the OpenAI/Hugging Face incident, and I was initially skeptical that Docker had much to add. After several weeks of customer conversations, I think we do. The useful lesson is not that an AI agent escaped a sandbox. It is what 17,600 actions expose about security systems designed for human tempo.

Hugging Face reconstructed approximately 17,600 attacker actions across a four-and-a-half-day campaign in July, including roughly two and a half days inside its infrastructure.

Put thirty seconds of human review against each action and you get 147 hours of work. Hugging Face grouped those actions into roughly 6,280 clusters; review only those and you still get more than 52 hours. Either way, manual approval and ordinary alert triage were never plausible primary controls for this workload.

This was not a fundamentally new category of attack. If you have any background in incident response, the sequence is familiar: exploit a reachable service, obtain code execution, collect credentials, escalate privilege, and cross the next trust boundary.

What was different was the rate, persistence, and ability to carry authority and state across short-lived environments. The agent could fail, rebuild its tooling, recover its communications channels, and continue from another environment without starting the campaign over. The useful mental model is a capable attacker fused with a fuzzer: it can reason about each result and keep probing without fatigue. That is the AI part of the story.

This is not a commentary on model alignment, and I will offer no opinion here on which model or agent framework you or your organization should use. The security question is familiar: what authority should be given to a workload that can execute code, hold credentials, reach the network, and continue testing paths long after a human would have stopped?

What happened

OpenAI was running internal cyber-capability evaluations against a benchmark called ExploitGym, which tasks agents with finding and exploiting vulnerabilities. The evaluation used reduced refusal behavior and none of the production-grade classifiers a deployed model would normally have.

The agents did not have direct internet access. They were allowed to install packages through an internally hosted package-registry cache. The agents found a previously unknown vulnerability in that permitted service and used it to reach the open internet.

The permitted service was the escape path. That’s the important point in the incident.

From there, the agents escalated privilege inside OpenAI’s research environment, reached a user-hosted CyberGym-style code-execution harness running on an external sandbox, and obtained root inside that harness. The sandbox platform itself was not compromised. Having apparently worked out that Hugging Face might host the benchmark’s reference answers, the agents went after Hugging Face directly, assessing that cheating was the fastest path to a passing score.

Hugging Face’s reconstruction documents local-file disclosure, code execution through a template engine, cloud metadata access, Kubernetes privilege escalation, exposure of a production secret containing 136 keys, access to the corporate network through a stolen credential, and limited write access to source control. It found no evidence that public models, datasets, packages, or released software were modified, and the customer content accessed was limited to a handful of benchmark-related datasets. That is a good outcome relative to what was possible. It is not evidence that the attack path was harmless.

The individual weaknesses were familiar: an unsafe processing path, accessible cloud metadata, broad privileges, long-lived credentials, and a shared administrative identity. A capable human attacker could have chained them, too. The difference was the volume of paths tested, the speed with which a failed path was replaced, and the amount of evidence defenders had to interpret while the campaign continued.

If you want the full blow-by-blow, Hugging Face published a detailed technical writeup and interactive replay. Both are worth reading.

The controls this requires

That arithmetic, not the novelty of the attack, is what changes the operating model. A human cannot sit in the control loop for thousands of actions at machine speed.

There are also two related threat models to account for.

In the first, the agent discovers and exploits a path on its own, as the agents did in this incident. In the second, an external party redirects the agent through a poisoned tool, compromised dependency, malicious document, prompt injection, or attacker-controlled data. In that case, the agent becomes the attack vector.

The same authority is dangerous in either case. The controls therefore have to govern what enters the environment, which capabilities the agent receives, and what happens when its behavior leaves the expected boundary.

The point is not to put human approval in front of every action. That defeats much of the value of using agents and eventually produces approval fatigue. Routine and reversible actions should have very little friction. More sensitive, external, destructive, or unusual actions should receive stronger scrutiny.

Review and sanitization still matter, particularly for packages, tools, and paths where external data could become a command. But sanitization alone is not a reliable answer to prompt injection. Natural-language content is too ambiguous for us to assume we can always identify and remove the malicious part. The stronger boundary is architectural: untrusted content must not be able to grant itself authority, change policy, or create capabilities the agent did not already have.

Done well, governance is not what limits agent autonomy. It is what makes it possible to safely give agents more of it.

Where Docker fits today, and where we do not

We are proud to be founding authors of the Agent Baseline. We worked with other industry experts to distill the problem into six outcomes: Discover, Constrain, Authorize, Observe, Validate, and Respond.

If Docker Sandboxes sit in one specific bucket, it’s “Constrain,” but really, we believe they’re foundational, and where you would instrument or implement all six. They give each agent a dedicated microVM and enforceable boundaries around local compute, filesystem access, and network reach, as well as providing the base (and thus ground truth) layer to observe. That is a real and useful layer.

Docker AI Governance addresses parts of Authorize and Observe by giving organizations a centralized way to define and enforce controls around agent environments, including network and filesystem policies and access to MCP servers and tools.

Together, Sandboxes and AI Governance provide a meaningful part of the answer today: a hardened execution environment and centralized policy enforcement around it. They do not repair a vulnerable service the agent is authorized to contact, narrow a credential issued by another system, or replace the customer’s own security architecture. No vendor, Docker included, can claim its technology would have made this particular incident a non-event.

But a deterministic enforcement boundary is still necessary. It gives an organization one place to apply least capability and least privilege, and one place to observe what the agent was actually allowed to do. If an agent is using a package registry as an egress proxy rather than a package registry, that’s the kind of divergence the telemetry needs to help surface, especially when viewed across a sequence of requests rather than one request at a time.

The broader problem remains difficult. The useful unit of observation is not always one tool call. It may be a burst of activity, a target, a protocol, a credential, or a pattern visible only across systems. A package request can be normal. Repeatedly probing the service behind it, discovering credentials, and using them to reach another system should change the assessment.

That’s the agent-security challenge beyond basic containment. We need to constrain authority, but also observe activity at the right granularity, recognize when it deserves more scrutiny, and respond at the same tempo as the agent. For all of us, Docker included, there is still substantial work ahead across observation, validation, and response.

The operational tradeoff

Security, capability, and autonomy all matter, and they will always be in tension. Said differently, none of this is free.

Short-lived credentials expire during long-running tasks. Narrow egress policies break legitimate package installation. Admission controls reject tools developers assumed they could run. Cross-system detection costs money and produces false positives. A write approval inserted at the wrong point can eliminate most of the productivity the agent was supposed to provide.

Teams will be tempted to loosen each control until the agent works again. That is understandable. The failure mode created by a strict policy is immediate and visible; the failure mode created by excessive authority remains invisible until an incident.

The answer is not to remove the controls or ask a human to approve everything. It is to make friction proportional to consequence, test the failure modes, measure the operational cost, and weigh it against the risk and potential blast radius.

How I work

I use agents every day, and I assume that a sufficiently capable agent will eventually try something I did not anticipate (perhaps on a daily basis…).

For the most part, I do not run one general-purpose agent with access to everything. I use task-focused agents, each packaged as a separate kit, built on free Docker Hardened Images and run in Docker Sandboxes.

Each kit starts with a specific job, then receives only the software, network access, files, credentials, and external capabilities required for that job.

In most cases, the agent has very few restrictions inside its sandbox. That is intentional. What matters is that god mode inside the sandbox does not become god mode over my laptop, my credentials, or every service I can reach.

I do a lot of desk research. Those agents can access the open internet. They’re not useful if they can’t. But their image has no compilers, package manager, general-purpose network debugging tools, or development toolchain, and it runs with deliberately limited system permissions. They can retrieve and analyze public information, but have very little machinery with which to turn something they encounter into an exploit or act on another system. They have no reason to hold my source code or production credentials.

My production coding agent has a much richer environment. It runs pi, can use multiple models, compile code, run tests, and use the tools required for real engineering work. Its network access is restricted to an explicit allow list of services I use, including Docker, GitHub, Snowflake, and Cloudflare. It does not receive arbitrary internet access or arbitrary tools simply because a coding task occasionally needs the network.

My home kit can interact with an Arduino, but it does not receive direct access to the host or the device. A host-side MCP server brokers the allowed operations. The agent can request a defined Arduino capability through that interface; it cannot turn that permission into general access to every device connected to the machine.

My development kit is where I experiment. It runs with balanced network access, but no ambient host secrets and no unrestricted access to host files. When it needs Google Workspace, Snowflake, or another host service, host-side daemons broker those calls. The agent sees the capability I have chosen to expose, not the underlying credential or the rest of the service. Those brokers can enforce which operations are allowed and which are blocked.

These are deliberately different environments. The research agent would be poor at production coding. The coding agent cannot reach every site the research agent can. The home agent cannot turn an Arduino operation into arbitrary host access. The development agent can query a service without possessing the credential that authorizes the query.

That constraint is the feature.

Conclusion: Security at agent speed

The OpenAI/Hugging Face incident was not the failure of a single boundary. It was a chain of reasonable-seeming permissions and familiar weaknesses that became something very different when an agent could test thousands of paths, preserve state across runs, and carry authority from one system into the next.

We will not anticipate every vulnerability an agent might find or every way it might combine the access we give it. The architecture cannot depend on perfect agent behavior, perfect software, or a human noticing every dangerous action in time.

So, the starting point is still least capability and least privilege: give an agent the narrowest interface, credentials, tools, and network access its task requires. Put those controls at a deterministic enforcement boundary. Make the resulting activity observable, not only as isolated requests, but as sequences and patterns across systems. When the behavior leaves the expected envelope, containment has to happen at agent speed.

Docker Sandboxes and Docker AI Governance provide important parts of that architecture today: hardened execution boundaries and centrally enforced policy around them. They do not secure every service an agent is permitted to contact, and they do not eliminate the need for an organization to decide what authority each agent should have. The broader work across Discover, Constrain, Authorize, Observe, Validate, and Respond is why we helped create the Agent Baseline in the first place.

The goal is not to build an agent that never tries the wrong thing. The goal is to build a system where trying the wrong thing does not give it the keys to everything else.

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.

The EU Cyber Resilience Act (CRA) was officially introduced on December 10th 2024, to protect foundational EU values in the face of rising cyberattack threats. As cyberattacks targeting products with digital elements have grown more frequent and costly, the regulation establishes the first horizontal cybersecurity baseline for all hardware and software products sold in Europe. The urgency is real given that in Omdia’s 2026 software supply chain security report, 77% of organizations reported experiencing a supply chain incident in the last year.

The regulation will take full effect on December 11, 2027, but mandatory vulnerability reporting obligations take effect on September 11, 2026. For teams building and shipping containerized software, the CRA turns practices like SBOM generation, vulnerability disclosure, and image hardening from voluntary best practices into legal requirements.

This guide covers what the EU CRA requires, who it applies to, how its SBOM mandate connects to container build workflows, and what teams need to do before the compliance deadlines arrive.

What is the EU Cyber Resilience Act (CRA)?

Before the CRA, the EU had no single, cross-sector regulation setting cybersecurity baselines for  products with digital elements. A smart thermostat, an enterprise database, and a container runtime were all subject to different (or no) cybersecurity obligations. There was no general obligation to patch vulnerabilities, disclose security incidents, or document the software of products with digital elements launched in the EU market. The CRA closes that gap with a horizontal regulation that applies across several industries, placing the primary burden on manufacturers.

The regulation defines a product with digital elements as any software or hardware product, including its remote data processing solutions and any components placed on the market separately. That scope is intentionally broad: it covers everything from consumer IoT devices to enterprise software platforms to container images distributed through registries. Manufacturers must design products securely, handle vulnerabilities throughout the product lifecycle, and provide transparency about software composition.

How the CRA relates to NIS2

The CRA is one part of the broader EU cybersecurity strategy that includes other regulatory frameworks, like NIS2 and DORA. Since the CRA and NIS2 both deal with cybersecurity obligations, they’re easy to conflate, but they target different things. The CRA applies to cybersecurity of products with digital elements, while NIS2 applies to the cybersecurity of essential and important entities.

Recital 12 of CRA even affirms that SaaS, PaaS, or IaaS solutions are subject to NIS2, in principle carving them out of its own scope. However, the line is blurry for products depending on cloud infrastructure.

The European Commission’s March 2026 draft guidance introduced a three-part test for determining when a cloud component falls under CRA scope:

1. Does the processing happen remotely?
2. Would the product lose a core function without it?
3. Did the manufacturer design, develop, or is control of that remote component under its responsibility?

If the answer to all three is yes, the cloud component is part of the product for CRA purposes. Where that test pulls a cloud component into scope and the component processes personal data, the GDPR applies on top of the CRA rather than in place of it, so you still need to assign controller and processor roles and confirm a lawful basis.

Who the CRA applies to

The CRA assigns obligations based on your role in bringing a product to market.

Key requirements for the EU CRA

The CRA organizes its requirements into two main areas, both defined in Annex I of the regulation: essential cybersecurity requirements for product properties, and vulnerability handling obligations for the product lifecycle.

Security by design

Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on a risk assessment. In practice, this means shipping with secure default configurations, minimizing the attack surface by removing unnecessary components, protecting the confidentiality and integrity of stored and transmitted data, and providing mechanisms for secure updates.

For container images, the security-by-design requirement maps directly to image hardening:

• minimal base layers
• no unnecessary shells or package managers
• secure defaults out of the box.

The essential requirements also include data minimization: a product should process only personal or other data that is adequate, relevant, and limited to what is necessary for its intended purpose.

Vulnerability handling

Manufacturers must maintain processes for identifying, documenting, and remediating vulnerabilities throughout the support period they define for each product. This includes coordinated vulnerability disclosure policies, timely security updates, and public disclosure of fixed vulnerabilities with enough detail for users to assess impact and apply remediation.

Security updates must be provided free of charge for the duration of the support period. Public disclosures should be limited to the technical detail users need and must not expose personal data, such as the identity of a reporter or of affected users, consistent with the CRA’s expectation that disclosures avoid increasing risk and with GDPR limits on publishing personal data.

Transparency and SBOMs

The CRA also requires manufacturers to include a software bill of materials in the technical documentation for every product with digital elements. The SBOM must be in a commonly used, machine-readable format and must include, at minimum, the top-level dependencies of the product. However, the regulation does not mandate a specific format, but in practice that typically means SPDX or CycloneDX.  Scope the generated SBOM to package and dependency metadata and keep embedded secrets and personal data out of the artifact.

An important nuance: The CRA does not require manufacturers to publish SBOMs publicly. SBOMs must be included in technical documentation and provided to market surveillance authorities on request. Also, the documentation must be retained for ten years after the product is placed on the market, or for the duration of the support period, whichever is longer.

Incident and vulnerability reporting

Manufacturers must report actively exploited vulnerabilities and severe security incidents to the relevant national Computer Security Incident Response Team (CSIRT) and to ENISA through a single reporting platform. The reporting timelines are:

Note for Privacy: These reports can contain personal data, such as a reporter’s identity or affected-user details, so limit each report to the technical information the CSIRT and ENISA actually need and handle any personal data in line with the GDPR.  Notifications should also avoid disclosing information that would increase risk to users.

Conformity assessment

Before placing a product on the EU market, manufacturers must complete a conformity assessment to verify compliance with the essential cybersecurity requirements. The type of assessment depends on how the product is classified under the CRA.

Product categories and conformity assessment

The CRA classifies products into three tiers based on their cybersecurity risk, with each tier subject to increasingly rigorous conformity assessment procedures.

If you’re shipping container runtimes, you likely fall into the Important Class II category and will need a third-party assessment. Products that pass their conformity assessment receive the CE marking, which indicates compliance with the CRA and allows them to be sold on the EU market. Products that fail, or that are found to be non-compliant after placement, can be ordered withdrawn or recalled by national market surveillance authorities.

CRA timeline: 3 Deadlines that matter

The CRA entered into force on December 10, 2024, but its obligations phase in over three years. Each milestone introduces a distinct set of requirements.

The key detail most teams miss: the September 2026 reporting obligation is applicable to products that are already in the market. It retroactively applies to products already on the EU market, not just new releases. If you are selling container images to EU customers today, your 24-hour reporting clock starts in months, not years.

Penalties for non-compliance

Article 64 of the CRA establishes three penalty tiers for non-compliance, with fines set at the member-state level but capped by the regulation:

• Up to €15 million or 2.5% of global annual turnover (whichever is higher) for failure to comply with essential cybersecurity requirements and other core obligations (Art. 64 (2)) 
• Up to €10 million or 2% of global annual turnover (whichever is higher) or failure to comply with other CRA obligations (Art. 64 (3))
• Up to €5 million or 1% of global annual turnover (whichever is higher) for supplying incorrect, incomplete, or misleading information to authorities (Art. 64 (4))

Beyond fines, market surveillance authorities can order product withdrawals, recalls, or outright bans from the EU market. For organizations selling software products into the EU, losing market access is often a more significant consequence than the fine itself.

Open-source software and the CRA

The CRA’s treatment of open source was one of the most debated aspects during the legislative process. The final text draws a clear line based on commercial activity.

Free and open-source software that’s not used in the course of a commercial activity, either directly or through support, is outside the CRA’s scope. Individual developers and volunteer maintainers are not classified as manufacturers under the regulation, as long as they operate outside a commercial activity. And the CRA explicitly does not apply to open-source software supplied for distribution outside the scope of a commercial activity.

However, the regulation introduces a new role: the open-source software steward. 

A “steward” is a legal person (a company or foundation, not an individual) that systematically supports the development of open source software intended for commercial activities. The CRA applies a light-touch regime for stewards with limited obligations. They must mainly:

1. Maintain a cybersecurity policy.
2. Report actively exploited vulnerabilities.
3. Cooperate with market surveillance authorities. 

Critically, stewards are not subject to financial penalties for CRA infringements.

Organizations that distribute open-source software under a commercial model, whether through paid support or commercial container image registries, are classified as manufacturers, not stewards. The distinction matters because manufacturers carry the full weight of CRA obligations, including conformity assessment and CE marking.

What the CRA means for container teams

Everything above applies to the full universe of digital products. Here’s where it gets specific. Container images and runtimes distributed commercially into the EU qualify as products with digital elements under the CRA. If your organization publishes container images in a registry that EU customers can pull from, and those images are part of a commercial offering, the CRA applies and you may be considered a manufacturer. This is true regardless of where your organization is headquartered.

The practical implications span the entire container lifecycle:

• Image composition transparency: Every image needs a machine-readable SBOM that documents at least the top-level dependencies. Image-layer SBOMs generated at build time, which capture OS packages, runtime libraries, and transitive dependencies, go further than the CRA’s minimum.
• Vulnerability management: Organizations must have processes to track, remediate, and report vulnerabilities in the components their images contain. Starting September 2026, all vulnerability and incident reporting obligations listed in Article 14 come into effect.
• Security by design: Images should ship with minimal attack surfaces, secure default configurations, and no unnecessary components. Hardened base images with shells, package managers, and debug tools removed satisfy this requirement more directly than standard community images.
• Provenance and integrity: The CRA’s essential requirements include protecting the integrity of the product and verifying that components have not been tampered with. Cryptographic signatures and provenance attestations address this directly.
• Support periods: Manufacturers must define and communicate a support period during which they will handle vulnerabilities. For container images, that means committing to a patch and rebuild cadence for the lifecycle of each supported image tag.

Compliance starts at the image layer

The CRA raises the bar for every organization that ships software into the EU. For container teams, the requirements map directly to practices the industry has been moving toward: hardened images, build-time SBOMs, provenance attestations, vulnerability monitoring, and defined support lifecycles. The difference is that these practices are no longer optional.

Thankfully, Docker Hardened Images ship with the artifacts the CRA demands: complete SBOMs, SLSA Build Level 3 provenance with non-falsifiable attestations, OpenVEX exploitability data, and cryptographic signatures. The images are minimal by default, continuously rebuilt against upstream fixes, and backed by defined support periods. Pair that with continuous vulnerability monitoring against SBOM data limited to package and component metadata and excluding personal data and embedded secrets, and the CRA’s 24-hour reporting clock starts with a known blast radius rather than a manual triage.

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

Frequently asked questions

Source

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.

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