By submitting this form, you agree to our 

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

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.

Eliminating ambiguity: The case for explicit Docker image paths

DevOps is hard enough. You really don’t want your tooling to introduce new bottlenecks. You need speed, security, and reliability from your software supply chain—and when things go wrong, you need a support team that actually delivers.

 was born in the cloud. Legacy vendors built their tools for on-premise deployments, and even when these tools are “managed” in cloud environments, they can feel sluggish, fragmented, and reactive. Vendor support often mirrors that—gated to named users only, slow to respond, tiered behind ticket queues, and disconnected from engineering.

 flips the model on its head - not just in the way the product delivers on artifact management, but in the way it enables our team to deliver on customer support.

Cloud-Native by design means support that moves at your speed

. No patchwork of on-prem tools, no outdated architecture. This matters because it creates some really important support-related outcomes:

 Our cloud-native platform means our support team sees what’s happening across environments in real time. Legacy tools often require layers of logs, configs, and manual back-and-forth.

, without any manual intervention or advance planning. Legacy vendors often leave customers waiting for infrastructure adjustments 

 Cloudsmith evolves daily with continuous delivery. Support is never stuck in “which version are you on?” purgatory. That means when you request support, there’s no confusion about what version you’re on, or whether your feature set is “old” or “incompatible.” We’re all running on the same platform, always.

Cloud-native isn’t just a better way to deliver artifacts. It’s what enables customer support teams to be effective, fast, and relevant.

Support as a strategic partner, not a ticket queue

Here’s where the difference really shows. Legacy providers often treat support as an afterthought: slow response times, hidden behind multiple tiers, and “premium” price tags just to get basic help.

Our support is reactive, of course—we’re here when you need us–but it’s also proactive and embedded into how the platform operates.

 From the first interaction, customers speak with dedicated engineers who understand the platform inside out. There are no scripted handoffs, and no wasted time.

 Because we manage a single global service, our team sees trends across customers. If something looks off in your setup, chances are we’ve already solved it elsewhere—and we’ll help you get ahead of it.

 Support isn’t just about fixing today’s issue. Our team feeds insights back into product and engineering, ensuring your needs directly shape the roadmap.

Contrast that with legacy vendors: tickets may vanish into silos, customers often wait days for an initial response, and when answers finally come, they can feel disconnected from the reality of modern DevOps pipelines.

 is about service, and it’s also about getting a competitive edge. With Cloudsmith you get:

 than legacy players bogged down by old architectures.

 from experts who live and breathe supply chain defense.

—we’re invested in your success, not just your subscription.

In software supply chains, speed and reliability are critical. Powered by AI assistants and using modern tooling, teams are moving faster than ever to build and release software. The last thing they need is an artifact management system that slows them down. You really don’t want to have to be navigating outdated interfaces, piecemeal architectures, and frustrating support experiences that feel more like barriers than help.

We believe that cloud-native infrastructure and dedicated support aren’t just “nice-to-haves”—they’re essential for building trust, security, and long-term success.

With competitors, you are a number. At Cloudsmith, you talk to real people who take your problems seriously.

An enterprise-class platform is only as good as the people behind it. Cloudsmith’s dedicated support team ensures that customers have more than a tool—they have a partner invested in their success.

Cloudsmith Blog

Secure containers by default with Cloudsmith and Docker Hardened Images

Eliminating ambiguity: The case for explicit Docker image paths

Cloud-native means better customer support, too