Software Bills of Materials (SBOMs) are critical for transparency and compliance. Think of them as the ingredients list for software, a simple record of what went in. But as attackers continue to target and exploit software supply chains, that ingredient list plays an increasingly important role in securing your software supply chain.

When you index SBOMs they become an accessible part of day-to-day workflows. They give you a clearer view of what you’re actually shipping and provide enough detail to make decisions earlier, before a risky dependency makes its way further downstream.

This post focuses on the shift in SBOM usage from descriptive document to proactive security tool. We’ll look at how SBOMs support prevention and how teams use SBOM-based policy enforcement to keep risks out of their pipelines.

A container image may look straightforward on the surface, but the real risk often sits several layers deep. The build process can indirectly introduce transitive dependencies and SBOMs expose that level of detail.

Once you have a detailed account of what’s inside an image, you can enforce rules that reflect how you want to build and consume software.

When using SBOMs for prevention, teams can:

Block containers that include components with known vulnerabilities

Apply license policies to the full contents of an image

Catch issues buried multiple levels down the dependency tree

Make security checks consistent across teams and pipelines

Put simply, SBOMs add context to policy decisions by exposing the components inside an image. Alongside metadata, SBOMs make it possible to apply existing rules more precisely when transitive dependencies introduce risk.

How Cloudsmith supports SBOM-driven prevention 

To make SBOM-based policy enforcement dependable, teams need two things: 

Current intelligence about vulnerabilities and malicious packages

A consistent control point that evaluates every container in the same way

Cloudsmith provides both through continuous scanning and automated policy enforcement.

Cloudsmith automatically generates CycloneDX format SBOMs during container image package synchronization. Once created, SBOM data is accessible by the 

 (EPM) schema, allowing you to incorporate them into security policies. You can also retrieve SBOMs via API or download them directly from the Cloudsmith UI.

For non-Docker artifacts, you can store SBOMs directly within packages. More information about how Cloudsmith generates and handles SBOMs is available 

EPM evaluates artifacts automatically whenever they’re pushed, synchronized, or re-checked due to updated intelligence. Built on Open Policy Agent (

) to be highly flexible, EPM enforces policies on both artifact metadata and Cloudsmith-generated SBOM contents, then applies the outcome you define: allow, flag, quarantine, or block.

High-risk or vulnerable component versions

Threat intelligence changes constantly. Risks can emerge through newly published CVEs, the identification of malicious packages, or upstream dependency changes. Cloudsmith keeps this information current by ingesting data from sources like Aqua Trivy, OSV, NVD, the GitHub Advisory Database, and the OpenSSF Malicious Packages project. 

 scoring adds context around how likely a vulnerability is to be exploited in practice.

Cloudsmith’s Continuous Security feature checks these data sources for new vulnerabilities every hour and matches them to artifacts in your Cloudsmith repositories. When Continuous Security detects a threat that affects an artifact in your workspace it triggers an Enterprise Policy Manager policy evaluation with the vulnerability data included in the policy input. This removes the gap between the existence of new information and your system’s ability to act on it.

Because EPM understands SBOMs, Cloudsmith can enforce policies at the component level, not just at the image level. This gives teams fine-grained control without adding friction to developer workflows.

Because of the nature of software supply chain threats and vulnerabilities, developers and security teams need policies that meet threats as they arise. Both proactive and reactive policies play a role in your overall security posture.

These policies help restrict known issues and non-compliant components before they land in a pipeline.

License enforcement: Check transitive dependencies for licenses that don’t meet your organization’s requirements.

Vulnerability thresholds: Define a policy that quarantines any image containing a component with a CVSS score above a specified level.

The pace with which threats emerge makes it impossible to rely solely on proactive policies. Reactive rules can function as an important zero-day stopgap. These rules give teams a predictable way to lock down newly identified risks, before they hit OSV and other data sources, without chasing them manually.

Deny rules for specific components: A deny rule for a specific package or version applies both to direct package downloads and to any Docker image that includes that package as a component, ensuring the same restriction is enforced regardless of how the package is consumed.

Turning SBOM visibility into policy enforcement at scale

SBOMs give you insight into the components you’re shipping, but their true value is in the action(s) this insight triggers. Enterprise Policy Manager lets you use that insight to trigger actions that keep known risks out of your pipeline. EPM uses SBOMs to ensure every component in your pipeline meets your organization’s specific security and license requirements, automatically and at scale.

: Put your SBOMs to work. Contact Customer Success to enable Enterprise Policy Manager. 

: See why the world's leading enterprises trust us to automate artifact policy. 

Q: How does SBOM enforcement differ from traditional vulnerability scanning?

Traditional scanning often focuses on the final artifact's metadata. SBOM enforcement looks at the "ingredients" list (the dependencies) of the artifact, allowing you to block specific internal components even if the top-level artifact is marked as safe.

Q: Can Cloudsmith EPM block builds based on OPA policies?

Yes. Cloudsmith EPM uses Open Policy Agent (OPA) to evaluate artifacts at the moment they are pushed. If an artifact violates a Rego policy (e.g., contains a banned license), EPM can quarantine the file immediately and prevent it from being downloaded, keeping non-compliant packages and dependencies out of your builds.

From ingredient list to control point: SBOM-based component-level 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. 

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

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 (

). However, an internal Dockerfile pulls a base image using an implicit path (

 to come from your private Cloudsmith repo, but the FQDN is missing, the build system will instantly default to Docker Hub and try to pull a public image.

This creates a vulnerability if a bad actor pushes a malicious image with the same name (

) to Docker Hub, hijacking your dependency stream (a technique known as Dependency Confusion or Registry Confusion).

If the implicit image exists on Docker Hub 

 in your private Cloudsmith repository, the behavior of which image your build pulls can become non-deterministic, often depending on local client configuration (like 

In one environment, the local client might be configured to prioritize Cloudsmith, pulling your private image. In another CI/CD environment, the client might default to Docker Hub, causing:

 If the image is private on Docker Hub and the environment isn't logged in.

 Pulling the wrong, possibly outdated, public image.

Using implicit paths throughout your build scripts fundamentally locks you into the Docker Hub default. If the Docker client changes its implicit behavior or if network rules block access to Docker Hub, your builds will instantly break.

A fully-qualified path, like one pointing to your Cloudsmith repository, is 

The best practice: adopting the FQDN standard

To maintain the highest level of security, clarity, and reliability in your supply chain, we strongly recommend adopting a strict policy:

Every single image reference, whether it’s a base image in a 

, a deployment manifest in Kubernetes, or a call in a CI/CD script, must include the registry FQDN.

Cloudsmith tip: streamline your base images

To make this explicit policy easier to enforce for common base images (like 

) those images into a dedicated, private Cloudsmith repository

This allows you to control the exact version, scan it for vulnerabilities, and use a consistent, explicit path for all base images:

By making all paths explicit, you transform your dependency graph from a set of ambiguous references into a predictable, auditable, and secure supply chain.

Implicit path naming is a relic of simpler times. In today's landscape of container security and supply chain complexity, ambiguity is a vulnerability. By adopting the standard of always using fully-qualified domain names (FQDNs), you make your builds robust, auditable, and resilient to dependency confusion attacks.

Ready to secure your container supply chain and enforce clarity? 

 and start managing every package with the confidence of an explicit, reliable path.

Cloudsmith Blog

Why cloud migrations are the best time to re-evaluate your artifact management

LLMs on Kubernetes: same cluster, different threat model

AI artifacts: The new software supply chain blind spot

I love Software (in) NI

Protect your software supply chain from typosquatting with Cloudsmith

Securing AI-generated code with Cloudsmith

Securing LLM dependencies against serialisation attacks

Top 10 most popular LLM models on Hugging Face

7 key metrics to measure software supply chain security

From ingredient list to control point: SBOM-based component-level 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