By submitting this form, you agree to our 

This blog contains the takeaways from our webinar "State of the Union: Modern security approaches for the Software Supply Chain." Watch the full discussion 

. Key topics include how to secure your CI/CD pipeline and software artifacts using SBOMs, Docker Hardened Images, and artifact lifecycle best practices.

Software supply chain attacks are on the rise, prompting a critical shift in how we secure modern software. Recent incidents like SolarWinds, XZ Utils, and Log4Shell underscore the urgent need for stronger security measures beyond just protecting production systems. Attackers are now targeting earlier stages of the supply chain, particularly build pipelines, impacting software integrity before it even reaches deployment.

State of the Union: Modern security approaches for the Software Supply Chain

 we brought together industry experts to tackle these challenges head-on. Michael Donovan, VP of Product at Docker, Ralph McTeggart, Principal Engineer at Cloudsmith, and Jack Gibson, Senior Software Engineer at Cloudsmith, shared their insights on how leading teams can defend themselves. During the session, they explored the evolving threat landscape, outlined a secure artifact lifecycle, and discussed strategies such as SBOMs to inject visibility, provenance, and trust into workflows without creating developer friction. While the focus was on container images, the principles discussed were equally applicable to other formats.

Rethinking Software Supply Chain Security

Software supply chain attacks have grown dramatically in both frequency and impact, prompting a fundamental shift in how software is secured. Incidents like SolarWinds, the XZ Utils backdoor attempt, and Log4Shell illustrate a sobering truth: attackers are now aiming upstream. Rather than targeting production systems directly, modern threats exploit vulnerabilities during the software build and integration phases, where visibility and control are often weakest.

As this attack surface expands, it’s no longer enough to harden runtime environments or secure production endpoints. The entire artifact lifecycle - from development to deployment - must be secured. This shift has led organizations to reassess their tooling, processes, and practices around software composition, packaging, and distribution.

The Shift in Emphasis on Software Supply Chain Security

The strategic focus of software security has moved upstream. Major breaches have shown how attackers exploit weaknesses in CI/CD pipelines, source code repositories, and registry infrastructure, areas traditionally outside the purview of security teams.

Events like the SolarWinds compromise in 2020, which leveraged a poisoned build system, or the 2024 XZ Utils incident, where malicious code was inserted by a fake maintainer, underscore how early-stage compromises can lead to widespread downstream impacts. Similarly, Log4Shell revealed the global exposure caused by a single vulnerable dependency, forcing organizations to redirect substantial resources just to locate and patch affected systems.

In response, governments and regulatory bodies have escalated their focus on software supply chain security (SSCS). Executive directives, such as the U.S. Cybersecurity Executive Order, FedRAMP requirements, the EU’s NIS2 directive, and the forthcoming Cyber Resilience Act, demand secure development practices, transparent artifact composition, and provable software provenance.

As attacks increasingly originate at the source, securing the artifact lifecycle is now a foundational requirement - not a future goal.

Modern software development is built around composability and speed. Applications today rely heavily on third-party libraries and frameworks, with open-source components making up as much as 75% or more of a typical codebase. The prevalence of transitive dependencies - indirect libraries brought in through direct ones - adds complexity and opacity to risk assessment.

At the same time, the efficiency of CI/CD pipelines can leave little room for traditional gatekeeping. Code is integrated, tested, and deployed rapidly, often using packages pulled directly from public registries with minimal verification. Unsigned artifacts, missing provenance data, and outdated registry configurations persist across many organizations.

This environment creates ideal conditions for silent, hard-to-detect supply chain threats. In response, software teams must move toward practices that ensure transparency, verification, and control at every phase of the build and release cycle.

Using SBOMs and Establishing Provenance

A foundational step in securing the software supply chain is understanding exactly what is being built and shipped. This is where three elements play a critical role:

SBOMs (Software Bills of Materials): These list all components within a software artifact - names, versions, authors, licenses, and dependency relationships. Tools such as Syft and Trivy support SBOM generation in SPDX and CycloneDX formats. Docker supports SBOMs natively through the docker sbom command. Cloudsmith accepts external SBOM uploads or can auto-generate CycloneDX SBOMs for container images, exposing them via API for automation and policy enforcement.

Digital Signatures: A signature confirms that an artifact originated from a known and trusted source. Tools like Cosign allow developers to sign and verify containers. Signed images enable downstream consumers to confirm authenticity before deployment.

Provenance: Provenance data describes the origin of a build, including input sources, build parameters, and environments. Docker Buildx supports automated provenance generation using the --provenance flag, capturing crucial metadata such as build arguments and platforms.

Together, these elements create an auditable trail of software origin and composition. In regulatory contexts, SBOMs are now a standard requirement. But beyond compliance, they provide security teams with the ability to trace vulnerabilities to specific packages, drastically reducing remediation time and effort. Cloudsmith’s Enterprise Policy Management (EPM) leverages SBOM metadata for automated policy actions, such as quarantining risky images or enforcing license compliance based on live dependency data

Tightening Security with Docker Hardened Images

As organizations grapple with securing sprawling software pipelines, Docker Hardened Images (DHIs) offer a straightforward way to integrate trusted, verifiable container artifacts into modern workflows, without slowing down development.

Available on Docker Hub, DHIs are a curated set of container images designed to minimize vulnerabilities out of the box. They are built with a smaller attack surface, and include a full suite of embedded security metadata by default. This makes them ideal for teams looking to adopt zero-trust practices without adding complexity or friction.

VEX (Vulnerability Exploitability eXchange) metadata

These attestations provide comprehensive visibility into the contents and origin of each image. Because they are packaged directly with the artifact, they integrate seamlessly into downstream platforms like Cloudsmith or any private registry. This removes the burden of generating and attaching this metadata later in the pipeline.

The impact is significant: DHIs can reduce vulnerabilities in base images by as much as 95%, offering a hardened starting point for secure application builds. Just as importantly, they help teams meet compliance and audit requirements from day one, with verifiable transparency and traceability.

By building security directly into the image and surfacing critical metadata in machine-readable formats, Docker Hardened Images simplify the process of building secure containers—and make modern supply chain security accessible by default.

Building a Secure Artifact Lifecycle

A secure software supply chain requires continuous validation from development through delivery. This is where centralized artifact management platforms like Cloudsmith become essential.

By configuring repositories to proxy public registries (e.g., Docker Hub, NPM, PyPI), Cloudsmith performs key security checks automatically:

Artifacts are cached and versioned, offering security and development teams full visibility and control over dependencies. When an image is pulled, verification steps - including signature checks and attestation validation - ensure that only known, trusted, and reproducible software is admitted into builds or deployments.

However, the ecosystem still faces gaps. Many widely used packages, particularly in NPM and PyPI, lack signatures or attestations. As of late 2024, only 5% of the top 360 packages on PyPI had provenance data published through the trusted publisher workflow. This makes it difficult to assert origin or integrity for many upstream dependencies.

To address this, teams should introduce a secure intermediary - like Cloudsmith - between developers and public sources. This provides enforcement points for policy, visibility into dependencies, and the opportunity to filter and block unverified packages before they can compromise the build.

Once builds are finalized, signing them and recording those signatures in transparency logs (e.g., Sigstore’s Rekor) ensures traceability and trust. This final step solidifies confidence that artifacts were not tampered with before reaching production.

Security features must be accessible, automated, and non-disruptive to gain widespread adoption. Teams are more likely to maintain best practices when secure workflows mirror familiar development patterns.

 come pre-equipped with SBOMs, digital signatures, and SLSA-compliant provenance. These attributes allow teams to build secure pipelines without requiring additional tooling or custom scripting.

When paired with Cloudsmith, this enables organizations to:

Centrally manage and enforce policies on all artifacts

Control access and visibility across engineering teams

Integrate security checks without altering development velocity

The result is a zero-trust pipeline where software integrity is maintained automatically, and security is treated as a first-class concern throughout the SDLC.

The shift towards modern security approaches is undeniable. SBOMs, signatures, and attestations are becoming fundamental elements in software development. The impending legislation, particularly in the EU with the Cyber Resilience Act, will further mandate these practices.

For a deeper dive into securing your container workflows, check out our companion blog post, "

Securing Containers at Scale: Docker Hardened Images and Cloudsmith

Maia Livingstone

Campaign Manager

Ian Taylor

Tech Content Director

Jack Gibson

Senior Software Engineer

Docker Hardened Images & Cloudsmith: Modern Security for the Software Supply Chain

Kubernetes has become the de facto platform for orchestrating containers. Open standards complement Kubernetes by defining best practices for its implementation. These standards are developed by the open-source Kubernetes community (not a single vendor), ensuring vendor neutrality, easier integration with other tools, and overall system efficiency.

, a Linux Foundation project, was created to establish open, industry-wide standards for container formats and runtimes. It focuses on two core specifications:

: A reference container runtime engine used by most container platforms, including Docker. It serves as the foundation for many modern runtime environments.

: Defines how containers are built, distributed, and executed. While Docker remains widely used, OCI represents the community's commitment to standardized, open container technologies.

, it became possible to use OCI-compliant container registries for storing and distributing chart packages. With the release of 

, OCI support moved from experimental to stable and is now enabled by default.

This shift has driven demand for registries that support Helm chart storage in OCI format. 

Cloudsmith is proud to be one such registry

, fully supporting Helm charts with OCI compliance.

Cloudsmith support moves from EA to GA for OCI

 released today (5th June 2025), we’re announcing full support for Helm OCI. Previously, Cloudsmith offered a Docker registry (

) that was fully compliant with the OCI v1.1 standard. While users could push any OCI artifact to this registry, non-Docker artifacts were still displayed as Docker packages.

This functionality had been marked as Early Access (EA) in our documentation, as the user experience was fully optimized only for Docker. Although users could technically push and pull any OCI artifact, display limitations persisted for non-Docker types.

With today’s update, we’ve significantly improved our support by fully enabling Helm OCI. We've reworked the implementation and introduced a dedicated endpoint (

) which allows users to push and pull Helm charts as OCI artifacts, now correctly identified and displayed as Helm packages.

In addition, we're introducing a compatibility bridge that enables legacy Helm charts and OCI-based Helm charts to coexist. We are now in a unique position to support legacy Helm chart repositories and OCI, allowing our users to push via legacy means and pull via OCI - offering greater flexibility and smoother transitions.

 is a tool that enables pushing, pulling, and managing 

 in OCI-compliant registries. It extends the OCI specification beyond container images, turning registries into general-purpose artifact stores.

 formalizes this approach, allowing for a broader range of artifacts, like SBOMs, Helm charts, and signatures, to be stored and retrieved without being disguised as container images. ORAS has become the 

 highlighted how ORAS is transforming registries into multi-purpose artifact platforms. They demonstrated pushing multi-architecture images along with their security metadata - all as native OCI artifacts.

As the ecosystem matures, there’s a clear trend: 

treating everything (from Helm charts to SBOMs) as first-class OCI artifacts

. At Cloudsmith, we're seeing growing demand for comprehensive support of these use cases, including secure metadata attachments and provenance tracking.

, which allows artifacts to reference related files such as SBOMs, signatures, or provenance records.

Nigel Douglas

Head of Developer Relations

Open Container Initiative (OCI) Support in Cloudsmith

Containers have been with us for a while and are ubiquitous in the Secure Software Development Life Cycle (SSDLC). According to some reports, 

 use containers for most or all of their production applications. It’s no surprise really, as containers provide consistency and standardization across the lifecycle while speeding up delivery pipelines. They revolutionized how we develop and deploy apps in the cloud and there is no sign of this changing anytime soon.

Like any part of the SSDLC, containers have security risks and can be breached. This can be due to misconfiguration of the containers, inherent vulnerabilities in the contained software, like missed OS patches, or vulnerabilities in the runtime code. These can manifest in various ways, but some common ones are vulnerabilities that provide root access to the OS, turn off security features, execute malicious code at run time, or run phantom processes silently in the background. And these breaches do happen. The most famous container breach is still the 2018 Tesla breach, where it was reported that hackers read AWS credentials from the breached containers and therefore gained further infrastructure access, allegedly launching cryptojacking operations using that infrastructure. So, with nearly 60% of organizations using containers in production, it's great to hear about Docker’s Hardened Images being announced last week.

 and records 11 billion pull actions on these images each month. Previously, they released Docker Official Images to provide confidence in the provenance of the images, SBOM support to give transparency on contents and Docker Scout for real-time insights. This focus on security has evolved again into Docker Hardened Images.

A hardened image is a container image prepared to reduce Common Vulnerabilities and Exposures (CVEs).

Ensuring they provide the core functions required

Reducing the target area for attacks by removing up to 95% of the contents

Providing a curation and governance process for images

The provenance and curation of these images should give organizations and developers confidence. Knowing that images will be checked and kept up to date by a reputable source like Docker can only be reassuring. However, the security of containers and images doesn’t stop here. At Cloudsmith, we are delighted to partner with Docker on this launch, as we know we can add more to securing container usage together.

The above image shows a typical example of how this works in practice. An organization’s CI/CD pipeline is configured to use Cloudsmith as a private registry for its artifacts, including container images. When a build is triggered during development, the CI/CD tooling requests the container image(s) it needs.

With an upstream proxy for container images configured, Cloudsmith will fetch the image(s) from Docker Hub. It is at this stage where a verifiable, trusted Docker Hardened Image can be fetched. There is no extra configuration required in Cloudsmith, so users can benefit from using these images right away. Pulling a Docker Hardened Image is the same as fetching any other image from Docker Hub. Maximum security and trust is built into the raw image. For customers that have specific compliance or security requirements, Cloudsmith will also enforce policies around licensing and vulnerabilities. 

See: link to enterprise policy management blog

. This ensures that organizations have the right blend of security at source and the flexibility to map to their own requirements.

How do organizations ensure developers use these images during code creation and the deployment lifecycle? Cloudsmith is already used by organizations worldwide for their Docker registries, and our advanced features provide tools built for global teams.

Our cloud native, global availability means an organization’s registries are available wherever its teams are. Policy creation and enforcement provide granular access to private and public images, ensuring a source of truth for the organization’s images and providing visibility to its security teams. We also support CI/CD workflows, meaning the organization can confidently see what is being promoted to production.

With seamless integration and zero tradeoffs between speed and compliance, combining the peace of mind provided by Docker Hardened Images with Cloudsmith’s Docker registry support and functions can produce even greater governance and confidence.

That's why we are delighted to collaborate with Docker for this launch, securing the software supply chain further than ever before.

Want to learn how to secure your software supply chain end-to-end?

Watch our webinar next week for an in-depth discussion on container security, hardened images, SBOMs, and how to build a zero-trust artifact lifecycle. 

 and get actionable insights from Docker and Cloudsmith experts.

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

Signing Artifacts to Prevent Artifact Poisoning

Breaches in software artifact integrity can have severe consequences. Bad actors poison artifacts by injecting malicious code into software packages, libraries, or container images, tricking developers and users into downloading compromised artifacts. These attacks can lead to data breaches, system takeovers, and widespread supply chain disruptions.

Continued artifact poisoning incidents highlight the increasing risk to software supply chains. A recent 

 let attackers inject malicious code into artifacts, compromising CI/CD pipelines. 

 enabled remote code execution and tampered dependencies. These cases underscore the need for strong artifact verification.

A highly effective defense against artifact poisoning is cryptographic signing, which verifies the authenticity and integrity of software artifacts. By digitally signing artifacts, developers use a private key to generate a cryptographic signature unique to their software. When an artifact is retrieved, the corresponding public key is used to verify the signature, checking that you can trust the source and the artifact hasn’t been tampered with.

Signing can be a complex process due to the expertise required and the various components involved. Developers need knowledge of key management, certificate verification, signing standards, and security policies. A good artifact management system aims to simplify this process.

When signing artifacts, there are two fundamental approaches:

 – Uses the artifact's built-in signing support (e.g., Swift Package Manager’s built-in signing, npm’s signature verification). This integrates well with artifact workflows, ensuring signatures are tied directly to the artifact format and verified automatically by native package managers.

, independent of the package format. While flexible and commonly used, third-party signing requires additional manual steps for verification.

Native signing is automated, built-in, and verifies artifacts within their ecosystem. Third-party signing tools such as GPG offer greater flexibility and compatibility, but they require manual integration and verification.

Native signing plays a role in maintaining compliance with industry and government regulations by ensuring that software artifacts are verifiable, traceable, and tamper-proof. It enforces cryptographic integrity, meeting the requirements of standards like SLSA, S2C2F, and FedRAMP Rev 5.

 enforces stricter security controls for software integrity and supply chain protection. Native signing supports this by ensuring artifacts remain verifiable, untampered, and compliant with cryptographic policies. Integrating native signing into CI/CD pipelines automates verification, simplifies compliance reporting, and aligns with FedRAMP’s Zero Trust principles.

Extending Native Support to Swift, NuGet, and Docker

Cloudsmith supports non-native signing for all package formats. In practice, organizations are making use of native signing for certain formats to improve workflows and reach compliance.

As part of Cloudsmith’s prioritization of security and compliance, three more package formats have been added to the roster for native signing support. Swift, NuGet, and Docker’s native signing tools can now be used in Cloudsmith, streamlining the workflow and eliminating the need for manual verification using GPG. These formats add to existing native signing support for Maven, Gradle, npm, RPM, SBT, Debian, and Alpine.

Cloudsmith is the first artifact management platform to offer Swift native signing. This positions Cloudsmith as a leading contender for enterprises engaged in Apple’s development ecosystem.

When working with Docker images, Cloudsmith uses Sigstore’s Cosign to automatically add a signature on upload. This uses an ECDSA (Elliptic Curve Digital Signature Algorithm) private key which is a type of public-key cryptography. An ECDSA key is generated automatically when you create a repository.

Cloudsmith automatically signs an image when it is uploaded using the repository’s ECDSA private key.

Anyone using the image can verify that it is trusted by downloading the matching ECDSA public key.

Alternatively, you can upload your own Cosign signature using 

Cloudsmith now supports native signing for all NuGet packages 

, a digital certificate that uses public key infrastructure (PKI) to verify the authenticity and integrity of signed artifacts. This allows consumers to verify repository signatures directly within native tooling or the NuGet CLI.

Native signing is enabled for the Cloudsmith repository, which issues a unique X.509 certificate.

When a NuGet package is uploaded or resynced, a repository signature is generated, and the signing certificate is included in the NuGet repository 

If a NuGet package contains an author signature, Cloudsmith will countersign the package.

Users can verify a package’s repository signature locally using native tooling or the NuGet CLI, confirming that the package originated from Cloudsmith.

Swift packages are signed using ECDSA private key in combination with an X.509 certificate, which holds the corresponding public key.

 consist of a source archive and a manifest file. The source archive contains the package’s sourced code and the manifest defines package details, dependencies, and configuration.

The manifest signature is an ‘attached’ signature - it is stored directly in the manifest file.

The source archive signature is a ‘detached’ signature - it is included in the metadata response when fetching a package by scope, name, or version. Swift verifies package signatures by checking the signing attribute in the metadata response. The source archive signature is generated after signing the manifest.

Swift signing in Cloudsmith works as follows:

Swift packages are signed with the X.509 certificate when a package is uploaded or synchronized.

Existing packages need to be resynchronized to append the signature to the manifest and generate one for the source archive.

To ensure secure artifact validation, Swift CLI uses a registry security configuration, defined in a JSON file for each user.

Take a look at the following documentation pages for more detailed information on how to use signing in Cloudsmith:

Native Signing Support In Cloudsmith Extended To Docker, NuGet, And Swift

As containerized environments evolve, effective artifact management is crucial for any organization using Kubernetes or similar ecosystems. Cloudsmith’s container registry now fully complies with the Open Container Initiative (OCI) distribution specification, allowing customers to store, secure, and distribute images and artifacts with greater efficiency.

This release marks an evolution in how Cloudsmith supports organizations, enabling streamlined workflows while ensuring compatibility with current and future industry standards.

With this update, Cloudsmith offers robust support for the OCI storage protocol and API format, including:

: Cloudsmith now supports the OCI storage protocol and API format, bringing greater flexibility and alignment with industry standards for artifact management.

Early Access for OCI Images and Artifacts

: With early access support, Cloudsmith customers can store, secure, and distribute generic OCI images and artifacts, including Helm V3 charts. Using ORAS, users can push and pull artifacts like SBOMs and attestations, strengthening control over containerized workflows.

: The Referrers API allows you to query an OCI registry for artifacts linked to a specific image or artifact, typically through reference or association. This feature is especially helpful for retrieving metadata such as attestations, SBOMs, signatures, or other security-related artifacts, offering a streamlined way to manage dependencies and related security information.

Key Benefits of Cloudsmith’s OCI-Compliant Registry

With Cloudsmith’s OCI-compliant container registry, organizations can unlock the following advantages:

: Integrate seamlessly with any OCI-compliant tools and services, enabling you to choose the right tools to fit your workflows and achieve optimal outcomes without compatibility issues.

: Rely on industry-standard specifications for container formats and image distribution, providing greater consistency, reliability, and peace of mind as you scale operations.

: As more technologies and ecosystems adopt the OCI specification, Cloudsmith’s platform will continue to support them, ensuring your workflows stay relevant and adaptable.

As we continue expanding support for OCI, expect updates on advanced Helm capabilities and additional security features for all supported artifact types.

Cloudsmith Blog

Docker Hardened Images & Cloudsmith: Modern Security for the Software Supply Chain

Open Container Initiative (OCI) Support in Cloudsmith

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

Native Signing Support In Cloudsmith Extended To Docker, NuGet, And Swift

Securely Store and Distribute OCI Artifacts