Every container inherits its base image. If that image carries unpatched CVEs, your application does too – before you've written a line of code. Hardened images fix the baseline: compiled from source with SLA-backed patching that keeps them clean after day one.
Distribution of these hardened images becomes a challenge. Security teams can pick a better image source, but making that image the default for every developer and build agent means new registry credentials per team and changes to how they pull. Adoption rollout becomes its own project, and it compounds across every team building containers. That's where adoption stalls.
Together, WizOS and Cloudsmith address the security and distribution aspects of using hardened images. WizOS compiles hardened container base images from source in an auditable pipeline, backed by strict remediation SLAs and cryptographic provenance. Cloudsmith puts those images behind the registry URL your teams already use, authenticated with credentials they already have.
Wiz doesn't pull pre-built packages from upstream public repos and assemble them. Wiz compiles its WizOS images from source in a controlled, auditable pipeline they own. You benefit from strict remediation SLAs that guarantee near-zero CVEs: 7 days for criticals, 14 days for highs and mediums. These builds also produce cryptographically verifiable provenance and signatures, so you can confirm exactly what shipped and where it originated. WizOS images have a minimal footprint, using only the components an image actually needs and glibc for broad compatibility with existing applications.
Hardened images writ large have the same goal: trust a maintained baseline instead of public open source upstreams. Wiz backs its WizOS hardened images with its own vulnerability and runtime data.
Cloudsmith treats the WizOS Registry like any other upstream (e.g., Docker Hub, npm, PyPI), as a source you proxy and cache behind your existing Cloudsmith repository URL. Developers don’t need to change how they pull images.
1. Add WizOS as an upstream. In your Cloudsmith repository's Upstream Proxying settings, create a new Docker-format upstream pointing at https://registry.os.wiz.io, set your priority, and choose Cache and Proxy.
2. Connect your WizOS credentials once. Grab your Wiz Registry credentials from your WizOS tenant (Profile > Tenant Info > Wiz Registry Credentials) and configure them on the upstream. From here, Cloudsmith handles authentication on behalf of every developer and build agent, so nobody else needs a WizOS login.
3. Pull like normal. Developers docker login docker.cloudsmith.io and pull images using their existing Cloudsmith repository path, for example:
docker pull docker.cloudsmith.io/ORGANIZATION/REPOSITORY/wizos-base:latestCloudsmith resolves the image, caches it on the first pull, and serves it from Cloudsmith's edge network on every subsequent pull.
Full setup steps are in Cloudsmith’s WizOS integration docs.
Once you configure WizOS in Cloudsmith the one remaining manual step, docker login docker.cloudsmith.io, becomes optional. The Cloudsmith CLI's new Docker credential helper (added in v1.19.0) lets Docker authenticate to Cloudsmith registries automatically, using credentials your CLI already has.
Run this once per machine:
cloudsmith credential-helper install dockerThis installs a docker-credential-cloudsmith launcher binary and registers it in ~/.docker/config.json. From that point on, docker pull and docker push against your Cloudsmith registries, WizOS included, just work. You don’t need to worry about a login step, copying a token into CI secrets, or risk having credentials sitting in a config file that can expire or leak.
The helper also discovers any custom Cloudsmith registry domains on your account via the API and caches them locally, so it isn't limited to the default docker.cloudsmith.io host. If you need to point it at additional hostnames, pass --domain (repeatable); use --dry-run to preview what it would change before it changes anything; and skip the auto-discovery step with --no-discover if you'd rather manage the domain list yourself. When you need to back the help out, cloudsmith credential-helper uninstall docker removes it. Run cloudsmith credential-helper list to verify what's currently installed.
The Cloudsmith credential helper gives you one line in your provisioning script for all your build agents instead of a docker login call (and a credential) in every pipeline.
What the WizOS/Cloudsmith combination gives you is a pattern, not just a configuration. Your WizOS credentials live in Cloudsmith's upstream config once. No developer or build agent ever handles them directly. The credential helper removes the last manual authentication step, so pipelines authenticate using CLI credentials they already have. The initial base image pull caches in Cloudsmith, so every build after that comes from your own repo and upstream availability stops affecting your pipeline.
The credential handling and image caching are the operational wins. The broader payoff is that Cloudsmith becomes the control plane across your entire software supply chain. The same policy engine that applies to your application dependencies applies to WizOS images sitting in the same repository. Vulnerability scanning, environmental policies, and access controls run consistently from the base image through to the finished artifact, without separate tooling at each layer.
When your upstreams converge on a single Cloudsmith endpoint (e.g., WizOS, Docker Hub, npm, PyPI), security teams have one governed URL to apply policy to, and development teams have one URL to pull from. Nobody manages a separate credential per upstream, and policy coverage doesn't have gaps between the container layer and the application layer.
WizOS gives you a hardened starting point: images compiled from source, with SLA-backed patching that protects from CVEs. Cloudsmith makes that starting point the default across your org. Developers pull from the same URL with the same credentials. The secure path is also the easiest one.
Want to see how WizOS hardened images and your existing registries can all sit behind one Cloudsmith endpoint? Book a technical deep-dive.
