A new report from Omdia focuses on security issues in the software supply chain, how organizations are responding, and where the biggest gaps remain 

In the heat map of cybersecurity vulnerabilities today, among the most intense hot spots is the software supply chain. In fact, it was the shift of the modern attack surface away from isolated systems to the software supply chain that connects them—and Docker’s role in safeguarding that interconnected reality—that first drew me to Docker.

So when Omdia recently released a report, with Docker among its sponsors, that laid out in detail the extent to which the software supply chain is under siege, I wanted to share some highlights.

Key data points

Here are some data points that caught my attention:

• Over three-fourths of organizations experienced a software supply chain incident in the preceding 12 months.
• AI tech was the top-ranked supply chain risk (40%), ahead of third-party and open-source code (39%), and software dependencies (38%). 
• Nearly half (45%) of orgs do not feel they have robust software supply chain security, compared to 55% who do.
• More than half of orgs (51%) rate secure containers as very effective in securing third-party and open-source code components.
• Shifting security left so that developers can secure their code is a high priority for 98% of organizations—and for 32% of those, it’s their top application security priority.

Third-party code and AI usage expand attack surface

A key finding was that increasing usage of third-party code and AI adoption pose security risks that organizations need to address.

Building applications using third-party libraries, open source dependencies, and AI-generated code saves developers a ton of time, so it’s no surprise this trend is on the rise. But it’s code they didn’t write, and as these time-saving inputs keep growing, so do the attack surfaces they expose.

• 77% of organizations reported experiencing a software supply chain incident in the 12 months prior to the survey (carried out in February 2026). 
• Notably, the most common attacks (38%) involved exploits that took advantage of known vulnerabilities in third-party software.

Source: Omdia Research Report, Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption, April 2026

Third-party code usage trending upward

Third-party code usage, including open-source software, isn’t going away. In fact, it’s gaining momentum.

• 38% of organizations report that more than half of their total software code comes from third-party sources—expected to jump to 58% of organizations in 12 months. 
• Similarly, 31% of orgs report more than half of their code is comprised of OSS—expected to jump to 51% of orgs in 12 months.

The report found that OSS is vital to developers and must be supported, and that orgs are either confident (50%) or completely confident (31%) that their developers are only using secure OSS.

AI tops security concerns

It should come as no surprise that, as devs increasingly use AI tech to develop software, AI tops the list of concerns around software supply chain risks (40%), ahead of third-party code (39%) and software dependencies (38%).

In the rapidly evolving threat landscape, new types of cyber attacks are emerging that are very different from CVEs (Common Vulnerabilities and Exposures). Take the Shai-Hulud campaign pioneered by TeamPCP, which automates and scales software supply chain attacks using stolen credentials to weaponize well-known packages and inject infostealers deep into the ci/stack or developer laptops.

Using third-party software including OSS is problematic for orgs on multiple fronts. The most common challenges are around vulnerability management.

• Orgs worry about vulnerability remediation (39%) and/or identifying vulnerabilities in the code (36%). 
• And, because AI tools often pull from third-party and OSS code, 35% worry about AI increasing or generating vulnerable code.

Current solutions often fall short

There appears to be a fair degree of awareness around the need to secure the software supply chain. While many orgs are looking to bolster their software supply chain security, nearly half (45%) do not feel they have robust security in this area, compared to 55% who do. 

At the risk of tooting our own horn, secure container services or libraries of hardened container images was the highest-rated tool for being “very effective” in securing third-party and OSS code components. In fact, out of 11 security tool categories, it was the only one rated as very effective by a majority of organizations (51%).

SBOMs play key role in boosting security

Another key finding was that effective inventory and SBOM (software bill of materials) tools can lead to measurably better security outcomes. 

SBOMs are essential because they eliminate structural blindness, providing transparency into the hundreds of third-party components that form the “ingredients” of a modern application. They are even more effective when paired with a VEX statement (Vulnerability Exploitability eXchange), which tells customers whether flagged vulnerabilities pose a risk or not—potentially saving security teams thousands of hours spent chasing “ghost” vulnerabilities.

According to the report, SBOMs help orgs manage software supply chain risk in a range of ways, including more efficient vulnerability mitigation (73%), implementing security controls and processes to mitigate risk (72%), and helping meet compliance regulations (68%).

However, among organizations that generate an SBOM as part of their application development processes, less than half (42%) do so as a mandatory part of the process for all applications. More than half (55%) generate SBOMs on a case-by-case basis.

Producing SBOMs and understanding code composition ranked fourth among challenges orgs face with using third-party software including OSS.

Action needed—fast

The report underscores the need for preventative measures and rapid response in the face of a quickly evolving threat landscape. Among the impacts of software supply chain incidents are the following:

• Nearly half of orgs (46%) faced unauthorized access to applications and data.
• More than one-third had SLAs impacted by remediation steps (37%) and/or experienced stolen developer credentials, secrets, or keys (35%). 
• Organizations also suffered loss of data, introduction of malware and ransomware, and fines for noncompliance.

These impacts underscore the need to mitigate risk as early as possible in the development lifecycle—ideally catching and remediating issues before applications are deployed. 

Investment plans and shifting security left

When asked about their spending plans in the face of these risks, orgs responded as follows:

• Nearly two-thirds (62%) expect to make significant investments in software supply chain security. 
• 37% anticipate making more modest investments. 

A final key finding was that investment plans prioritizing AI require collaboration across teams. That’s largely because the job of securing the software supply chain increasingly falls to those on the front line: developers.

In fact, shifting security left so that developers can secure their code is a high priority for 98% of organizations—and for 32% of those, it’s their top application security priority.

The need to support development 

One of the more resonant issues surfaced in the report was the need to support developers on the front lines. Despite the support for shifting security left to eliminate the security team as a bottleneck for remediating security issues, nearly half (45%) of security teams have only moderate or less influence over security products and processes for developers.

And while the majority of respondents believe their developers are mostly (38%) or completely (45%) comfortable taking on security responsibilities, orgs whose developers are less comfortable need to remove as much friction as possible from the process—for example, by making sure security tasks are not disruptive to the development process, and that security tools roll out consistently across development teams and work within development workflows.

The software supply chain isn’t getting simpler, and neither are the threats targeting it. If you’re evaluating how your organization can better secure third-party code, AI-generated code, and open source dependencies, the full Omdia report offers a deeper look at the trends, data, and practical recommendations shaping software supply chain security. Download the report to see where your organization stands and where to focus next.

Eliminate Stored Credentials in Your CI/CD Pipelines

TL;DR: Docker now supports OpenID Connect (OIDC) for GitHub Actions. Your workflows can authenticate with short-lived, per-run tokens instead of stored PATs or OATs. No secrets to rotate, no credentials to leak. 

GitHub OIDC connections are available to organizations with Docker Team, Docker Business, or Docker Hardened Images (DHI) subscriptions, as well as organizations enrolled in the Docker Sponsored Open Source Program (DSOS).

Table of contents

• The problem with stored credentials
• Who should use this
• How OIDC connections work
• Getting started
• What doesn’t change
• Learn more

OIDC token exchange flow between GitHub Actions and Docker

The problem with stored credentials

Every GitHub Actions workflow that pushes or pulls images from Docker Hub authenticates with a personal access token (PAT) or organization access token (OAT) stored as a GitHub secret. These credentials are long-lived. Someone has to remember to rotate them. A leaked token grants access to your registry — pulling private images, pushing malicious ones — and that access persists until someone discovers and revokes it. Rotation is manual and does not scale. As pipelines multiply, so do the credentials that need tracking, and stale tokens are a common audit finding.

Who should use this

1. GitHub issues a signed identity token (a JWT) that encodes the repository, branch, environment, and other metadata about the workflow run.
2. The workflow calls docker/login-action, which presents this token to Docker.
3. Docker verifies the token’s signature against GitHub’s public key registry and checks it against rulesets configured in the Admin Console.
4. If the token matches a ruleset, Docker returns a short-lived access token scoped to the resources defined in that ruleset.
5. docker/login-action uses this token to authenticate to Docker Hub. From there, docker pull, docker push, and docker build commands work as usual.

The entire exchange happens without any stored secrets, API keys, or access tokens. The short-lived Docker access token expires in minutes and cannot be reused.

This is the same pattern that AWS and GCP already use for cloud resource access (AWS OIDC for GitHub Actions, GCP Workload Identity Federation). Docker is applying it to container registry access.

Getting started

Setup is a one-time connection in Docker Home plus a small update to your workflow YAML.

Step 1: Create a connection

Sign in to Docker Home, select your organization, and navigate to OIDC connections. Select Create OIDC connection and configure the rulesets that control which repositories, branches, and workflows can access which Docker Hub resources. You can create up to five rulesets per connection. When a workflow triggers an OIDC exchange, Docker checks the token against every ruleset defined in your connection. If a ruleset’s conditions are satisfied, Docker grants access based on the parameters set by that ruleset.

Rulesets use OIDC subject claims to match incoming tokens. You can pin to specific repos and branches as a recommended security best practice:

• repo:my-org/my-repo:ref:refs/heads/main — only the main branch of a specific repo
• repo:my-org/my-repo:ref:refs/heads/release-* — all release branches
• repo:my-org/my-repo:* – all branches of this repo
• repo:my-org/* — any repo in the organization (not recommended)

Copy the connection ID when you are done.

Note: GitHub repositories created after July 15, 2026 use immutable identifiers for default subject claims. For example: repo:octocat@123456/my-repo@456789:ref:refs/heads/main. See the GitHub changelog for more details.

Step 2: Update your workflow

Update your GitHub Actions workflow. Replace <YOUR_CONNECTION_ID> with the ID from the previous step and <YOUR_ORG_NAME> with your Docker organization name:

permissions:
  contents: read
  id-token: write

steps:
    - name: Docker login                                                                                                                                                                 
      uses: docker/login-action@v4 # v4.5.0+                                                                                                                                                                
      with:                           
        username: <YOUR_ORG_NAME>
      env:                                                                                                                                                                               
        DOCKERHUB_OIDC_CONNECTIONID: <YOUR_CONNECTION_ID>

The id-token: write permission lets the workflow request a GitHub OIDC token. The docker/login-action handles the token exchange and Docker login in a single step when DOCKERHUB_OIDC_CONNECTIONID is set. From there, docker pull, docker push, and docker build commands work as usual.details of the incoming claim sub value, which you can use to diagnose why the connection failed.

Step 3: Verify the OIDC connection works

Run your workflow and confirm it completes successfully. If you encounter an error, the Failures tab of the OIDC connection page will show the details of the incoming claim sub value, which you can use to diagnose why the connection failed.

Step 4: Remove the stored credential

After verifying your workflow runs successfully with OIDC, remove the old PAT or OAT from your GitHub repository secrets. You no longer need it.

Migration Checklist

• Create a connection
• Update your workflow
• Verify the OIDC connection works
• Remove stored credentials

What doesn’t change

• Existing PATs and OATs keep working. Organizations can migrate workflows to OIDC connections at their own pace.
• Images, registries, and build workflows are unchanged. OIDC connections only replace the authentication step; everything downstream is the same.
• Local development and non-GitHub CI still use PATs and OATs. OIDC connections are the recommended replacement for GitHub Actions specifically. Other CI providers will follow based on demand.

Learn more

• Learn more about OpenID Connect
• Visit Docker Home to get started
• Read the documentation

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

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