What is a golden image in the cloud?
A golden image is an authorized template that you use to launch consistent and secure computing resources in modern cloud environments. This template serves as a blueprint for immutable infrastructure across two distinct layers:
The host layer (VMs): These are virtual machine images (e.g., AWS AMIs, Azure Compute Gallery images) used for your underlying servers or Kubernetes nodes. Hardening here focuses on the OS kernel, SSH access, and system-level logging.
The workload layer (containers): These are OCI-compliant images (e.g., Docker images) used for Kubernetes pods or serverless tasks. Hardening here focuses on minimal runtimes, application libraries, and removing unnecessary shells.
Although they share the same name, VM golden images and container golden images are different artifacts with different lifecycles and patching strategies. VM images are long-lived, stateful disk images that are rebuilt and rotated periodically. Container images are ephemeral, application-scoped artifacts that are rebuilt and redeployed frequently.
Secured Images 101
Secure your container ecosystem with this easy-to-read digital poster that breaks down everything you need to know about container image security.
Lifecycle and patching model differences:
VM golden images: Rebuilt on a scheduled cadence (typically monthly, with emergency rebuilds for critical CVEs) and rolled out by replacing instances
Container golden images: Rebuilt frequently (daily or weekly) and rolled out via application redeployments rather than in-place patching
Without a golden image program, organizations often fall into the trap of manual configuration (sometimes called "mutable infrastructure"). This model leads to…
Configuration drift: Servers start identical but diverge over time as different engineers apply manual hotfixes, change settings, or install "temporary" debugging tools. These unique, undocumented systems are known as snowflakes.
The patching treadmill: Instead of a single image update, security teams must run patching scripts across thousands of live instances. If a single script fails on a small percentage of the fleet, you’re left with a silent, exploitable gap.
Unreliable scaling: When your application needs to scale up during a traffic spike, you risk launching new instances that don't match your current production environment, leading to "it works on that server but not this one" bugs.
Shadow IT: Without a "blessed" image, developers often pull unverified images from public registries (like Docker Hub), unknowingly introducing malware or critical vulnerabilities into the corporate network.
Container Images Demystified: Structure, Security, and Best Practices
Learn how container images work, their role in deployment, security risks, and best practices to streamline and protect your cloud-native applications.
En savoir plus
Why golden images matter for cloud security
A golden image program transforms security from a manual gate into an automated guardrail. By moving security upstream, you ensure every asset is born secure.
1. Reducing the attack surface
For VMs (host layer): Strip out unnecessary background services, disable default SSH access, and apply kernel-level hardening (sysctl) before the OS is ever deployed.
For containers (workload layer): Move toward Distroless or minimal bases, removing shells and package managers (like apt or yum) so an attacker has no pre-installed tools to use if they gain entry.
2. Eliminating configuration drift
For VMs: Move away from snowflake servers. Every node in your fleet is an exact clone, ensuring that critical logging and monitoring agents are consistently active and configured correctly.
For containers: Ensure every microservice is built from the same "blessed" runtime. This prevents environment-specific bugs and ensures security policies remain consistent from dev to production.
3. Drastic vulnerability reduction
For VMs: Catch CVEs in the build pipeline rather than finding them on a server that has been running for 200 days. This prevents vulnerability debt from accumulating on your host OS.
For containers: Mandate minimal bases to reduce the vulnerability count in a typical image from hundreds down to near-zero by simply excluding the libraries where CVEs usually live.
4. Software supply chain integrity
For VMs: Ensure every agent (monitoring, logging, security) is the version approved by the security team, preventing shadow versions from entering the environment.
For containers: Enforce the use of SBOMs (software bills of materials). With every container coming from a "gold" factory, you have a complete manifest of every library to instantly identify exposure during new library exploits.
5. Improved mean time to recovery (MTTR)
For VMs: Embrace immutable infrastructure. If a server is compromised, don't waste hours cleaning it. Terminate it and launch a fresh, known-good instance from the golden image.
For containers: In a cluster-wide crisis, redeploy your entire application suite with confidence that the underlying configurations are secure and verified.
Deployment strategies: The VM golden image pipeline (host layer)
For virtual machines, the goal is to produce a hardened disk image that can be used for auto-scaling groups or Kubernetes worker nodes.
Source (the foundation): Start with a "minimal" or "core" version of a trusted OS from a verified provider (e.g., Ubuntu Pro, RHEL, or Windows Server Core) found in the Cloud Marketplace. Avoid using "standard" desktop-style images that include high-risk UI components or pre-installed bloatware.
Define: Use HashiCorp Packer or EC2 Image Builder to define the OS configuration in code (HCL/YAML).
Harden: Automate the removal of legacy protocols (SMB, Telnet) and apply CIS Benchmarks.
Distribute: Share the "blessed" AMI or VHD with specific cloud accounts/subscriptions.
Enforce: Use service control policies (SCPs) or Azure Policy to block the launch of any VM that does not originate from an approved image ID.
Deployment strategies: The container golden image pipeline (workload layer)
For containers, the goal is a minimalist, scanned, and signed artifact that can be deployed across any OCI-compliant orchestrator.
Define: Start with a minimal and hardened base image (such as a WizOS image) in your Dockerfile.
Scan: Integrate vulnerability and secrets scanning directly into the CI/CD runner (GitHub Actions, GitLab CI).
Sign: Use Sigstore/Cosign to create a digital signature once the image passes all security gates.
Enforce: Use a Kubernetes Admission Controller (like Kyverno) to verify the signature before the pod is allowed to run.
Watch 12-min demo
See how Wiz integrates container security into the wider cloud ecosystem to isolate critical risks and harden your entire environment from one central platform.
How to enforce golden images in Kubernetes
One quick note before we discuss strategies: It’s important to separate workload enforcement (container images) from host enforcement (VM-based Kubernetes nodes). Kubernetes controls the former directly, while the latter is enforced at the cloud infrastructure layer.
A golden image program is only effective if you can prevent "non-gold" images from entering your environment. In Kubernetes, this enforcement happens at two distinct layers:
1. Enforcing the workload layer (containers)
This prevents developers from running unvetted or shadow images (like a random version of Nginx pulled from a public registry).
Admission controllers: Use tools like Kyverno or Gatekeeper (OPA) to create a policy that says: "Only allow pods to start if the image comes from my-company.ecr.aws/..." *
Signature verification: Use the ImagePolicyWebhook to check for a cryptographic signature (via Sigstore/Cosign). If the image wasn't signed by your golden pipeline, Kubernetes will reject the deployment.
2. Enforcing the host layer (VM nodes)
This ensures the actual servers (nodes) that make up your cluster are built from your hardened VM image.
Cloud-native policies: This is actually enforced outside of Kubernetes using AWS service control policies (SCPs) or Azure Policy. You set a rule at the cloud account level that prevents any EC2 instance or Scale Set from launching unless it uses a specific, approved "golden AMI" ID.
Node auto-repair: Modern managed services (like GKE or AKS) can be configured to automatically "roll" your nodes. If a node drifts from the golden baseline, the cluster kills it and replaces it with a fresh instance from the current golden image.
Container Security Scanning: From Detection to Deployment
Container security scanning detects vulnerabilities early for an efficient DevSecOps process. Discover how it safeguards containers throughout the lifecycle.
En savoir plus
Challenges & implementation considerations
Transitioning to a golden image program is as much about process as it is about technology. Here’s how to navigate the common roadblocks at both layers of your stack:
Challenges for the host layer (VMs)
The "long-lived host" trap: In VM environments, it’s tempting to let a server run for months, applying patches manually. This leads to configuration drift, where the running server no longer matches the golden source.
The fix: Implement a strict TTL (time to live) for your instances. Force a recycle of your fleet every 14–30 days to ensure every node is running the latest gold version.
Secrets persistence in snapshots: Traditional VM snapshots often accidentally capture sensitive data (like logs, temp files, or credentials) that were active during the golden build.
The fix: Use automated build tools like HashiCorp Packer to build from scratch every time, and use Instance Metadata Services (IMDS) or key vaults to inject secrets at runtime rather than baking them into the VHD/AMI.
What is container image scanning?
Container image scanning is the automated process of analyzing container images for security vulnerabilities, misconfigurations, and compliance violations.
En savoir plusChallenges for the workload layer (containers)
Stale inherited risk: A container image is only as secure as its parent. If you build your gold app on a "bronze" base image that hasn't been updated in months, you inherit every CVE in that base.
The fix: Use digest pinning (referencing images by their SHA256 hash) to ensure your builds are reproducible, and automate your CI/CD to trigger a rebuild the moment the upstream base image is updated.
Supply-chain trust & verification: In a fast-moving container environment, it’s easy for unverified third-party libraries to slip in.
The fix: Generate an SBOM (software bill of materials) for every build. Use Sigstore Cosign to sign your images and a Kubernetes Admission Controller to block any container that lacks a valid signature. This ensures only "authorized gold" runs in your cluster.
The universal challenge: Secrets at runtime
Regardless of the layer, hard-coded secrets are a critical failure point.
The challenge: Secrets leaked during image creation are visible to anyone with access to the registry or the image layers.
The fix: Never use ENV or ARG for sensitive data in Dockerfiles. Instead, use CSI drivers (for K8s) or native cloud secret managers (AWS, Azure, GCP) to retrieve encrypted secrets only when the workload is actually executing.
How Wiz operationalizes the golden image lifecycle for containers
A golden image program is only as strong as your ability to enforce it and detect when it fails. Wiz provides a unified platform to secure your containers from code to runtime.
1. A secure foundation with WizOS
If you want to skip the patching treadmill for container images, you can start with WizOS images.
Managed baselines: WizOS provides a catalog of minimal, hardened container base images that are maintained at near-zero CVEs by Wiz experts.
SLA-backed patching: Wiz commits to remediating vulnerabilities within 7 days for Criticals and 14 days for Highs/Mediums, allowing your developers to focus on their code rather than OS maintenance.
2. Shift-left enforcement with Wiz CLI
Wiz integrates directly into your CI/CD pipelines (GitHub Actions, GitLab, Jenkins) to act as the automated quality gate for your golden images.
VM & container scanning: Use the Wiz CLI to scan images for vulnerabilities, secrets, and misconfigurations before they’re ever published to your catalog.
Policy as code (PaC): Automatically fail builds that don't meet your "gold" standard, preventing vulnerable or non-compliant images from reaching your container registries or cloud marketplaces.
3. Kubernetes admission control
In production, the Wiz Admission Controller acts as the final enforcement point for your workload layer. It prevents shadow IT by blocking or auditing any deployment that doesn't meet your trust requirements:
Registry allow-lists: Only allow images from your verified golden repositories.
Signature verification: Verify that images were signed by your build pipeline (e.g., via Cosign).
Policy enforcement: Block images with unresolved critical vulnerabilities or those that haven't been scanned in the last 24 hours.
4. Continuous visibility
Security doesn't end at deployment. Wiz continuously monitors your cloud environment (AWS, Azure, GCP).
Inventory & mapping: Automatically link every running VM and container back to its source image. Wiz identifies stale assets that are still running on deprecated or vulnerable golden images.
The Security Graph: By correlating image vulnerabilities with real-world exposure (like internet-facing ports or high-privilege identities), Wiz helps you prioritize which golden image updates need to be rolled out first.
Ready to see how Wiz can protect everything you build and run in the cloud? Schedule a demo today.
Agentless Container Security
Get a hands-on look at how Wiz scans your containers for vulnerabilities, and how WizOS base images can cut your CVE count down to near zero.
