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

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

At Cloudsmith, we recognize the importance of maintaining control and reliability over every aspect of your organization's software, including its dependencies. That's why we're thrilled to introduce support for 

This means that your organization's developers can effortlessly upload R packages, while Cloudsmith handles the retrieval and caching of its dependencies. Let us reliably and securely be the single point of contact for all your packages.

R is a powerful programming language and environment widely used for statistical computing and graphics.

CRAN, or Comprehensive R Archive Network, serves as the primary repository for R packages, providing a vast collection of resources for R users and developers.

 hosts a vast collection of R packages contributed by developers worldwide, covering a wide range of domains such as statistics, machine learning, data visualization, bioinformatics, and more.

These packages are generally available in both source code and precompiled binary formats. Source packages contain the original R code, documentation, and any necessary dependencies, allowing installation on any platform by compiling them locally. Precompiled binaries may also exist for Windows and macOS platforms, making installation straightforward for users without the need for compilation. These binaries are optimized for their respective platforms, enhancing performance and ease of use.

With Cloudsmith's CRAN upstream proxying, we act as your single point of contact for all R packages and dependencies. By proxying upstream dependencies located in CRAN, we simplify integration by consolidating access to packages through our platform.

This means your organization can ensure reliability and only have to deal with a central place, Cloudsmith, instead of managing multiple connections to external repositories.

When you add a CRAN upstream in Cloudsmith, we’ll do several things behind the scenes that’ll allow you to start pulling R packages (in both source or binary format) right away:

We’ll check what packages are available on the upstream

We do this for all source packages and binaries built for specific versions of R, platforms (macOS or Windows), and architectures (for macOS binaries only).

Once complete, this allows you to take advantage of two powerful features of Cloudsmith, Proxying and Caching.

When you attempt to pull an R package from Cloudsmith and it doesn’t exist within your repository, we’ll check if it exists on the upstream. If it does, we’ll transparently serve it. No more specifying multiple repositories within the R console when installing an R package.

Even better, if you’ve got multiple CRAN repositories, add them as upstreams within Cloudsmith. Specify which repositories Cloudsmith should check, set the precedence or priority between them, and define actions in the event of an upstream failure. You’ll always be in control of your dependency management.

If you’ve configured the upstream to cache any packages you’ve fetched, when you fetch a package it’ll be stored in your Cloudsmith repository. No more fetching from the wild.

This gives you greater visibility and control about what packages are being fetched, access to package scanning and monitoring, and lightning-fast and reliable access to your most important dependencies.

Benefits of CRAN Upstream Proxying and Caching

 Lightning-fast delivery of dependencies from our cached repository no matter where you are in the world.

 Ensure consistent and reliable access to dependencies worldwide.

 Having a secure central location for consuming all your organizations R packages and dependencies. One place to monitor, 

 Consolidate access to R packages through Cloudsmith. Your Cloudsmith repository is the only repository you need to configure.

At Cloudsmith, we're committed to empowering developers with tools that make software development simpler, faster, and more secure. With CRAN upstream proxying and caching, we're taking another step toward achieving that goal.

Ready to streamline your organizations R package management with Cloudsmith's CRAN upstream support? Check out our 

Let's build better software together, with Cloudsmith.

Cloudsmith Blog

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

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

Caching and Upstream Proxying For CRAN's R Packages