By submitting this form, you agree to our 

As software supply chain attacks become more sophisticated, organizations have shifted from "why" to "how." We’ve moved past simply discussing the need to protect sources and secure builds. Today, the industry relies on frameworks like 

 Adopting a framework is only the first step. To achieve true 

, you must move from subjective trust to objective measurement. In this final post of our series, we explore seven key 

Why metrics are essential for software supply chain integrity

Security without measurement is guesswork. Many organizations claim to have a secure software supply chain, but struggle to answer basic questions like:

Can we prove where our production artifacts came from?

How quickly do we detect new dependency risks?

Are security policies enforced, or just documented?

 depends on visibility, enforcement, and accountability. Metrics turn those concepts into something observable and repeatable. More importantly, they shift security from a reactive function to a governed system, ideally managed within a 

Quick reference: S2C2F metrics and maturity mapping

The 7 key metrics for a secure software supply chain

 The percentage of production artifacts with verifiable, cryptographically signed provenance. 

 If you can’t prove how an artifact was built, who built it, and what went into it, you’re relying on trust instead of evidence. Provenance is the foundation of 

 High coverage indicates a strong source and builds integrity, while preserving traceability throughout the artifact lifecycle.

 How many artifacts in your repositories are signed and verified before use. 

 Unsigned artifacts are indistinguishable from tampered ones. A 

 depends on cryptographic verification, not naming conventions or environment assumptions. 

 Mature teams enforce signature verification at the 

 Whether Software Bills of Materials (SBOMs) are complete, accurate, and generated per artifact version. 

 An outdated or partial SBOM creates false confidence. SBOMs are only useful when they reflect exactly what was shipped, including transitive dependencies.

 High SBOM completeness supports transparency, auditability, and rapid incident response.

4. Mean time to dependency risk detection (MTDR)

 How quickly new vulnerabilities, malicious packages, or license issues are detected after entering the supply chain. 

 Speed matters more than perfection. The longer a risky dependency lives in your pipeline, the greater the blast radius. 

 Short MTDR indicates continuous verification instead of periodic scanning.

 The percentage of builds, promotions, and downloads governed by enforceable security policies. 

 Security guidelines without enforcement don’t reduce risk. Policy must be automatic, consistent, and unavoidable. 

 High enforcement rates reflect a shift from advisory controls to preventative ones.

 How often teams reuse verified artifacts instead of rebuilding the same components across environments. 

 Rebuilding introduces inconsistency, increases attack surface, and weakens traceability. Reuse strengthens integrity and simplifies audits. 

 Mature organizations promote trusted artifacts through environments rather than recreating them.

7. Exposure window for vulnerable artifacts

 The time between vulnerability disclosure and when affected artifacts are blocked, quarantined, or replaced. 

 Every hour a vulnerable artifact remains available is measurable risk.

 Short exposure windows indicate automated response and strong 

artifact management for supply chain security

 reveal more than individual control gaps. They show whether S2C2F principles are operationalized within the organization.

Organizations with low S2C2F maturity often:

Rely on CI logs instead of artifact metadata.

Detect risk late in the lifecycle (often at deployment).

Enforce security inconsistently across different teams.

Treat the artifact as the system of record:

 All security metadata is attached directly to the artifact.

 to build; they only care what the cryptographic signature 

 as a security gate, not just a storage bucket.

How do you measure software supply chain security?

You measure it by tracking objective data points across the artifact lifecycle, specifically focusing on provenance coverage, cryptographic signing rates, and the speed of vulnerability detection (MTDR).

S2C2F metrics are specific indicators used to track the implementation of the Source-to-Container-to-Factory framework. They include artifact integrity checks, build service security, and dependency trust levels.

S2C2F maturity is measured by the degree of automation and enforcement in your pipeline. Level 1 focuses on basic visibility, while Level 4 requires automated policy enforcement, reproducible builds, and 100% provenance coverage.

How do you track software supply chain integrity?

Integrity is tracked through a combination of SBOMs, cryptographic signatures, and "attestations" stored within a secure artifact repository. These tools provide a verifiable record that the software has not been tampered with.

Closing the series: From framework to outcomes

How S2C2F strengthens open source and build security.

The core principles behind trusted software delivery.

This final step, measurement, is where theory becomes practice. When organizations clearly measure trust, integrity, and risk across their software artifacts, supply chain security stops being aspirational. It becomes operational.

 to learn how Cloudsmith accelerates your path to S2C2F maturity.

Parul Jhawar

Marketing

Security Maturity Assessment Guide

7 Key Metrics to Measure Software Supply Chain Security

Software supply chain security has moved from a niche concern to a board-level priority. While source code receives much of the focus, significant risk lies in the "grey area" between build and production, where developers store, share, and consume software artifacts.

artifact management for software supply chain security

 becomes foundational. When implemented correctly, a secure repository acts as the connective tissue that turns the Secure Supply Chain Consumption Framework 

 from a theoretical model into an operational reality.

Why artifacts are the "unit of trust" in S2C2F

Every software delivery pipeline produces artifacts: packages, container images, binaries, and 

. These are what actually run in your production environment.

Yet, many organizations treat repositories as passive storage. To achieve 

, you must treat your artifact repository as security-critical infrastructure.

 Only scanned and approved artifacts move to production.

 Artifacts cannot be altered once stored.

 Every binary is linked back to its build and source.

 focuses on the secure ingestion of open-source software (OSS). Artifact management provides the enforcement layer for these core practices:

1. The secure "front door" (ingest and control)

S2C2F requires a controlled point of entry for OSS. A secure artifact repository acts as a proxy, caching external dependencies so they can be scanned before they reach a developer’s machine.

You cannot secure what you can’t see. Advanced artifact management automatically generates and stores metadata, providing a "living" inventory of every dependency in your ecosystem – a key requirement for the 

 allows you to set automated "gates". For example, if a package in your repository has a critical CVE, the management system can automatically block it from being pulled into new builds.

Mapping artifact management to the S2C2F maturity model

 requires evolving your artifact strategy from simple storage to an intelligent control plane.

Artifact repository security: Beyond storage

 is about maintaining a "chain of custody" for your software. To advance your 

 Preventing "hidden" updates to existing versions.

 Using tools like Cosign to sign artifacts, ensuring they haven't been tampered with in transit.

 A complete log of who accessed what and when, which is essential for incident response.

Why it’s a differentiator for supply chain integrity

 doesn't add friction; it adds velocity. By centralizing security controls at the repository level, developers can move fast, knowing that the "ingredients" they are vetted against the 

When secure artifact management is embedded in the pipeline:

 Vulnerabilities are caught at the repository level, not in production.

 Every artifact has a "digital passport" (metadata and signatures).

What is artifact management in software supply chain security?

It is the process of securely storing, governing, and distributing binaries and packages. It ensures that the software being deployed is exactly what was built and hasn't been tampered with.

How does artifact management enable S2C2F?

It operationalizes the framework by providing a central location to ingest OSS, store SBOMs, scan for vulnerabilities, and enforce consumption policies.

What is the S2C2F maturity model for artifacts?

It is a 4-level progression where an organization moves from using public registries directly (Level 0) to rebuilding and verifying every OSS component internally (Level 4).

Why is artifact repository security critical for supply chain integrity?

Because the repository is the final gate before production. If the repository is compromised, an attacker can swap a safe artifact for a malicious one, bypassing all previous source-code security checks.

S2C2F provides the blueprint, but artifact management is the foundation. By strengthening your 

, you turn supply chain integrity from a goal into a reality.

If you haven’t explored the foundations of S2C2F yet, we recommend starting with the previous post in this series:

Understanding these principles will help you see exactly how artifact management fits into the broader S2C2F journey and why it is such a critical enabler of supply chain integrity.

How Artifact Management Enables S2C2F Maturity

Choosing a secure container base image has historically been a game of compromise between costs, tooling, and operational overhead. You either pay for premium images, struggle with the “tooling gap” of minimalist distroless builds, or drown your team in the manual labor of constant patching.

Docker is changing this equation by making its 

Docker Hardened Images (DHI) catalog–over 1,000 minimal, high-integrity images–freely available

. But while the images are free, operationalizing them at scale across a massive engineering org is not.

That is where the combination of Docker and Cloudsmith becomes a cheat code for developers and security teams working at enterprise scale.

The developer advantage: Better ingredients, less prep

For a developer, a Docker Hardened Image isn't just more secure. It’s an evolutionary step forward that better protects against software supply chain threats and risks. DHIs arrive pre-patched and stripped of the bloatware found in typical images. They offer developers:

: These images are smaller, meaning they move across the network fast and start up in seconds.

: Docker handles the continuous patching of DHIs, monitoring upstream sources so you don’t have to.

 Level 3 provenance. You get traceable security data from the very first layer of your build.

The Cloudsmith difference: One endpoint, zero sprawl

Most other artifact managers force you into repository sprawl. If you want to add a new source like DHIs, you’re stuck creating a new remote repository, a new local cache, and a new virtual repository to tie them together. Then, you have to hunt down every CI pipeline and developer config to update the endpoints.

This isn't just an operational challenge, it’s a security bottleneck. When the path to better security requires a manual overhaul of your internal infrastructure, adoption stalls. This friction often forces organizations to stick with "good enough" images, leaving them unnecessarily exposed to vulnerabilities that DHIs are designed to eliminate.

We architected Cloudsmith differently. Our repositories are natively multi-format and upstream-aware. Adding Docker Hardened Images isn't a migration project. It’s a natural extension of your current setup.

 DHI as an authenticated upstream source in Cloudsmith. Developers and build agents continue pulling from the same Cloudsmith URL they already use.

: Keep your existing Docker Hub upstream in place. Cloudsmith handles the authentication, caching, and routing behind the scenes.

: Continue using the same Cloudsmith repository URL you already have. You can keep your existing Docker Hub upstream active alongside DHI. Cloudsmith acts as the single, intelligent integration point between your stack and the outside world.

Cloudsmith lets you treat DHIs as just another upstream source rather than a special case project. From a developer and CI perspective, nothing changes. That means you eliminate the friction that usually kills security initiatives because behind the scenes, Cloudsmith handles the authentication, caching, and routing automatically. You get to enforce a hardened organizational standard without touching a single developer’s 

Turning hardened images into an organizational standard

When DHIs flow through Cloudsmith, they become part of your controlled software supply chain. By supplying developers with base images via Cloudsmith, in addition to recommending better security, you provide a default environment that includes:

: Every team builds from the same approved, cached base images.

: You know exactly which images developers use and where they originated.

: Security teams can apply policies that govern image usage without breaking the build.

Solving the coordination tax and rate-limit surprises

While DHIs are free of charge, they require authenticated access. For a single developer, this is a non-issue. At an organizational level, managing credentials for hundreds of build agents and thousands of CI pipelines is a nightmare.

The secret handshake: Centralized authentication

Cloudsmith becomes the single integration point between your organization and Docker Hub.

: You store your organization’s Docker Hub credentials in Cloudsmith once. Your developers and build agents then authenticate directly to Cloudsmith.

: You avoid pushing configuration changes and tokens out to every individual client.

Docker Hub enforces strict pull rate limits. In a large CI/CD environment, you can hit these limits in minutes, breaking your builds.

: Cloudsmith automatically caches requested DHIs.

: Once an image is in your private repo, Cloudsmith serves future pulls directly from our global edge network. This should reduce or eliminate rate limiting issues.

DHI and Cloudsmith both offer significant intrinsic benefits, and even more power lies in the ease of their integration. Because Cloudsmith handles DHIs like any other upstream source, developers can configure their pipelines once and deploy at scale without disrupting their existing workflows. In short, Docker makes DHIs secure; Cloudsmith makes them easier to consume across an enterprise.

The result is a 'security win' by default that serves the entire engineering organization. By adopting these stronger defaults with zero added operational drag, teams can finally align their velocity with their security standards. Developers get to work with faster, higher-quality tools, while the organization gains a hardened, verifiable security posture. Together, we’re building a more trustworthy ecosystem where security isn't an external hurdle–it’s a built-in feature of the craft.

Achieving a secure supply chain shouldn't require a total re-architecture of your artifact repositories. See how Cloudsmith’s upstream-aware repositories can consolidate your Docker Hub, DHI, and internal images into a single, high-performance endpoint. 

Colin Moynes

Senior Support Engineer

Secure containers by default with Cloudsmith and Docker Hardened Images

If you're running workloads in AWS, you're already managing IAM credentials. Wouldn't it be great if those same credentials could authenticate your services with Cloudsmith without creating, storing, or rotating yet another API key?

. Your AWS workloads can now exchange their IAM identity for short-lived Cloudsmith tokens on the fly. No long-lived secrets sitting in environment variables. No API keys to rotate. Just cryptographically signed, time-limited credentials.

, which can now issue signed JSON Web Tokens (JWTs) that external services like Cloudsmith can verify and trust. Here's the flow:

Your AWS workload calls STS and asks for an OIDC token, specifying Cloudsmith as the intended audience

STS returns a cryptographically signed JWT containing your AWS identity information

You pass this token to Cloudsmith's OIDC endpoint

Cloudsmith fetches AWS's public verification keys and validates the token's signature

If everything checks out, Cloudsmith hands back a short-lived JWT you can use for API calls

You're authenticated, no API key required

There are three pieces to configure: AWS permissions, AWS external identity federation, and Cloudsmith OIDC settings. Let's walk through each.

Your AWS role or user needs permission to call the 

 API. Add this policy to any IAM principal that needs to authenticate with Cloudsmith:

Enable Outbound Identity Federation in AWS

Before your account can issue these external identity tokens, you need to flip the switch. Head to the 

, and enable outbound identity federation.

Once enabled, AWS generates a unique issuer URL for your account. This URL hosts the OIDC discovery endpoints that external services use to verify your tokens. It looks something like 

. Keep this URL handy since you'll need it for the Cloudsmith configuration.

 which allowed Cloudsmith to fetch the required metadata to verify received tokens.

Now tell Cloudsmith to trust tokens from your AWS account. Navigate to your Cloudsmith organization settings at 

Settings > Authentication > OpenID Connect

With everything configured, here's how to actually authenticate from your AWS workloads.

 must match what you configured in Cloudsmith's required claims. We used 

Now swap that AWS token for Cloudsmith credentials:

 with your Cloudsmith service account slug, and 

 with your Cloudsmith organization identifier.

If everything's configured correctly, you'll see something like:

aws-pipeline

This pattern works anywhere you have an AWS IAM identity. The short-lived nature of both tokens keeps things secure, and you're leveraging identity you're already managing.

 can use their instance profile to request OIDC tokens. Add the token exchange to your startup scripts or application initialization.

 work the same way through task roles. Grab a token during container startup or lazily when you first need Cloudsmith access.

 can request tokens during cold start or on-demand within your function code. The overhead is minimal because both API calls are quick.

CodeBuild, CodePipeline, and other AWS services

 with an IAM role attached can participate. Build pipelines become much cleaner without injected API key secrets.

AWS outbound identity federation combined with Cloudsmith's OIDC support is a clean solution for a common problem. You're extending trust from identity you already manage, exchanging it for short-lived credentials exactly when you need them, and eliminating the operational overhead of API key management.

No more secrets in environment variables. No more key rotation schedules. No more "who has access to that API key?" conversations.

AWS outbound identity federation documentation

Ian Duffy

Site Reliability Engineer

Authenticate to Cloudsmith with your AWS identity

The danger of implicit naming in container security

At Cloudsmith, we believe in building a secure, transparent, and reliable software supply chain. When teams migrate their container workflow to a private, unified registry like Cloudsmith, one subtle habit often carries over from the days of exclusively using Docker Hub: implicit image path naming.

Relying on implicit names is dangerous because it introduces ambiguity, undermines security, and can lead to unexpected build failures.

This article explores what implicit naming is, why it's a risk, and why you should adopt a policy of using fully-qualified domain names (FQDNs) for every single container image reference.

Implicit vs. Explicit: build with confidence

Whether you are building a new image or deploying an existing one, you need absolute confidence that you are requesting the correct source from the correct registry, repository, and base image, with the right dependencies, and without any unverified or malicious components. Trust in your pipeline means knowing every artifact comes from a verified source, every dependency is accounted for, and nothing has been silently altered along the way. Without that assurance, you’re not just building software – you’re building in potential vulnerabilities.

When you interact with a Docker image using the standard Docker CLI, the client makes an assumption if you omit the registry namespace. This assumption is known as an implicit path.

The Docker client automatically prefixes the image name with the default registry and library namespace, which is 

The explicit standard (The Cloudsmith way)

The explicit approach requires you to specify the 

 of the registry as a prefix. This removes all ambiguity.

When you use Cloudsmith as your private registry, your images must be pulled or pushed using a path that looks like this:

Starting with Kubernetes 1.34, distributions powered by the CRI-O runtime (including OpenShift and 

) enforce precise image name resolution. The rule is simple: Kubernetes no longer pulls container images unless you explicitly define the source.

With Kubernetes 1.34, CRI-O removes the implicit path assumption. To ensure deterministic builds and deployments, every image reference must now include its fully qualified registry path. Without it, the pull request is rejected, and the deployment fails.

This shift validates a long-argued point by security experts: ambiguity is a vulnerability.

The critical risks of relying on implicit paths

Why is this subtle difference a massive liability in a software supply chain?

Risk 1: Supply chain confusion and hijacking

In complex build scripts, Dockerfiles, or Kubernetes manifests, it’s easy to mix explicit and implicit references.

 You push your application image to Cloudsmith using the FQDN (

Cloudsmith Blog

7 Key Metrics to Measure Software Supply Chain Security

How Artifact Management Enables S2C2F Maturity

Secure containers by default with Cloudsmith and Docker Hardened Images

Authenticate to Cloudsmith with your AWS identity

Eliminating ambiguity: The case for explicit Docker image paths

The 8 core principles of S2C2F

Cloudsmith 2025: By the Numbers

Access Control & Permissions for Multi-Format Repositories

Understanding S2C2F: How it strengthens OSS security

What is Software Supply Chain Integrity?

Extend EPM policies to Hugging Face artifacts

Slopsquatting and Typosquatting: How to Detect AI-Hallucinated Malicious Packages