What are hardened images?
Hardened images are VM or OCI container images that are purpose-built or pre-configured to adhere to specific security standards. The process of hardening an image includes removing unnecessary utilities and libraries, implementing configuration baselines, scanning for vulnerabilities, and implementing patches.
Hardened images give you peace of mind that your workload is following security best practices right out of the box. You can be confident that a hardened image minimizes your attack surface and known vulnerabilities at release time. Hardened images undergo thorough scanning against CVE databases before distribution, though new vulnerabilities may emerge over time—which is why continuous scanning and patching matters. Some vendors, including Wiz, maintain SLAs around vulnerability remediation in their hardened image offerings, handling the burden of patching so customers can maintain their security posture.
Remember: It’s easier to prevent issues from the start, instead of fixing vulnerabilities once containers and VMs are running in production. That’s why hardened images bring tangible rewards: Removing vulnerabilities up front reduces vulnerability noise, exposure, and risk of a breach.
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.
Types of hardened images and where to find them
There are two distinct types of hardened images, categorized by their architecture and how they interact with your host environment.
Hardened VM images
Hardened VM images are self-contained artifacts that include the entire operating system, a dedicated kernel, and all necessary drivers. Hardening these images involves stripping the OS to its essential services and applying strict configuration benchmarks—such as CIS Benchmarks or STIGs. They are designed to run on a hypervisor (such as Hyper-V or KVM) to provide strong hardware-level isolation.
Hardened container images
Hardened container images are lightweight artifacts containing only the application and its user-space dependencies; they share the host’s kernel at runtime. Hardening here focuses on reducing the image size, using minimal base images to eliminate unnecessary binaries. By reducing the image to the bare-functional minimum, you reduce the attack surface. Container image hardening also focuses on removing vulnerabilities. “Secured” images take image hardening a step further by providing guarantees around CVE remediation. These secured images are continuously maintained at near-zero CVEs under SLAs backed by a vendor.
Once you’ve determined your architecture, you can source images from several channels:
Cloud service provider marketplaces: All popular cloud platforms host marketplaces where you can obtain pre-hardened images that are continuously maintained. Keep in mind that using them might incur additional costs, billed per hour of VM usage or per instance per month.
Private hardened-image maintainers: Vendors like the Center for Internet Security (CIS Benchmark-compliant images) offer pre-hardened images from public or private registries.
Secured image/Managed hardened image providers: Vendors like Wiz build and maintain hardened images with strict, vendor-backed SLAs for CVE remediation. This goes a step further than traditional hardened images by removing the burden of patching and maintenance from customers, helping them maintain their hardened security posture over time.
Make your own: If you’d like to have complete control over the entire hardening process, you can make a hardened image yourself. This is the most labor-intensive choice. Aside from the build process, you’ll also have to put effort into maintaining your hardened image to keep up with the evolving threat landscape.
Building a secure image pipeline from source to deployment
Next, let’s look at a general flow for building a secure image pipeline. Even though your exact steps depend on the kind of image you’re creating and the purpose it will serve, these stage-by-stage tips will set you up for success:
Develop
Write out your requirements and goals.
Choose a good base image—either minimal (for both VMs and containers) or Distroless (containers only)—from trusted, dependable sources. Distroless images lack shells, package managers, and common utilities but aren't automatically hardened—they still need security configuration and scanning.
Configure internal security mechanisms and tools that align with the framework of your choice (e.g., CIS Benchmarks or DISA STIG).
Shrink the attack surface further with architecture-specific controls:
For VMs: Configure host firewalls (
iptables, nftables) to implement a default-deny policy, ensuring only strictly necessary ports are open.For Containers: Avoid "bloating" images with in-container firewalls. Instead, configure the container to run with a read-only root filesystem. This is one of the most effective ways to prevent an attacker from downloading malware or achieving persistence if they gain initial access.
For both: Switch the default user to non-root, drop unnecessary Linux capabilities (like
CAP_NET_RAW or CAP_SYS_ADMIN), and ensure that security profiles (like AppArmor or Seccomp) are utilized to restrict the kernel's attack surface.
Keep your secrets safe during this stage! Hard-coding them into the image undermines all the effort you’ve invested into the hardening process so far.
Build
Use CI/CD for building images: Automated hardening will significantly decrease the amount of effort required, save a lot of time, and provide you with a fresh source of well-tested images.
For containers, use up-to-date, security-conscious build tools (e.g., BuildKit or Buildpacks).
For VMs, codify the build process using Packer or cloud-native tools (like Azure Image Builder).
Scan
Scan the image and all its contents for vulnerabilities, and replace flawed packages and libraries with trusted, safe versions (or alternatives).
Tools such as Trivy, Grype or Wiz can come in handy at this stage.
New vulnerabilities are discovered every day—remember to periodically re-scan images you’ve already built to make sure they stay resilient.
Add provenance
Establishing the image’s origin, modification history, and the standards enforced on it allows for easy security and compliance checks later and also prevents tampering.
Generate an SBOM to keep track of the exact contents of your base image. SBOMs come in different formats—SPDX (from the Linux Foundation) and CycloneDX (from OWASP) are the two industry standards. Make sure that you pick a format compatible with the rest of your security, compliance, and supply chain protection ecosystem.
Sign the image to allow for later integrity checks. You can sign images with solutions such as Sigstore Cosign, Notary, or Docker Content Trust. Cloud-native services such as AWS Signer can help too. Here’s an example: Using Cosign, you can sign a container image with a single command:
cosign sign --key <private key> <image>. This signature can be verified later withcosign verify --key <public key> <image>.Attest the image by producing cryptographically signed statements (using SLSA provenance or in-toto attestations) about build origin, SBOM contents, and security scan results. These signed attestations allow downstream consumers to verify that the image hasn't been tampered with and meets security policies.
Verify
In this step, you’ll take a look back at all the work you’ve done.
Validate the image against your chosen benchmarks. Investigate your scans, justify any exemptions, and report on the final result.
Test if the image works as you expected. Some security measures, especially the most strict ones, can break things. For instance, a very thorough minimization could strip libraries you actually needed. The verification step is your last chance to make sure everything is in working order before your image heads towards deployment.
Promote and deploy
The image is done. Now, it can become a part of your environments—after passing the last-mile checks, of course.
Configure promotion gates to allow only images that meet policy thresholds—for example, no critical or high-severity CVEs with available fixes, mandatory image signatures and attestations, and compliance with CIS Benchmarks. Define risk acceptance workflows for vulnerabilities without patches.
Set up admission control using OPA Gatekeeper, Kyverno, or Kubernetes Pod Security Admission (PSA) to accept only signed, attested, tested, and compliant container images as deployment candidates. For example, a Kyverno policy can verify Cosign signatures and block unsigned images at deploy time.
Security teams often struggle with fragmented tools—one scanner for CI, another for registries, a third for runtime—each with different policies and thresholds. Consider implementing a single policy engine instead. Aim for just one policy throughout the entire workflow: from development, through CI and environment promotions to admission. This way, you can maintain a uniform, consistent, and robust security posture without unnecessary tool fragmentation and the overhead it causes.
Watch 12-min demo
See Wiz identifies exposed containers, visualizes the full attack path, and fixes the issue directly in code.
Common hardening pitfalls that break cloud operations
Insecure configurations
One of the most important parts of hardening? Secure configuration. Problems with images frequently stem from simple mistakes. We’re talking about leftover permissive firewall configurations, built-in security tools that are disabled, and SELinux/AppArmor/seccomp misconfigurations on the VM/container host. Unfortunately, these mistakes severely affect the reliability of the resulting image.
Dependencies and additions
Hardened images are designed to be safe straight out of the box, but that doesn’t mean they will always stay safe. If you’re using a hardened image as a base image for your application, its dependencies and build process can introduce (or re-introduce) vulnerabilities. When you add anything to a hardened image in any way, shape, or form, you must scan it again.
Runtime misconfigurations
Runtime misconfigurations, such as overprivileged access or skipped critical software updates and patches will make even a well-hardened image susceptible to issues. This is especially true for containers; running them in privileged mode, using the root user inside the container, excessive kernel capabilities, or write permissions over the root filesystem can be just the leverage a malicious actor needs for a container escape.
Trying to eliminate all these pitfalls without deep, specific context (e.g., internet-exposure + a privileged container + sensitive data), will force your team to chase after noise. Focus on a risk graph approach instead to prioritize what really matters and deploy targeted, precise fixes.
Step-by-step roadmap for implementing hardened images
If you want to shift left (and trust us, you do), implement hardened images at the very beginning of your project. Here’s how:
Select standards and policies that are the best fit for your organization. If you’re not sure, CIS Benchmarks can be a great starting point.
Identify the workloads in need of hardening, and assign priorities. Some workloads are more important than others, so carefully select which ones need your attention the most. You can worry about the rest later.
Decide on the appropriate remediation approach. Do you want to build an image yourself, use a baseline image and add the application on top, or go with a fully pre-built solution?
Integrate the images of your choosing into your workflows. Adjust your CI/CD pipelines to play a crucial part in the process: for example, configure periodic scans or automatic builds when a patch pops up.
Monitor your environment and maintain the golden standard—review your security posture periodically, continuously monitor for any new vulnerabilities, and re-assess the quality of your images to keep them clean and safe.
Aim for bidirectional traceability: When an issue is found in the cloud, you should be able to effortlessly trace it back to the base image and pipeline that produced it; when fixing flaws in the code/build, validate the drift in the affected cloud. Automatically gathering additional context reduces mean time to remediation (MTTR) from days to hours by eliminating manual investigation and ticket handoffs. Here’s the context you’ll want to collect:
Cloud resource: ECS task, Kubernetes pod, VM instance
Container image: Registry, tag, digest, build timestamp
CI/CD pipeline: Jenkins job, GitHub Actions workflow, GitLab pipeline
Source code: Repository, Dockerfile, commit SHA, author
Owner: Team Slack channel, on-call rotation, JIRA project
How Wiz identifies and prioritizes hardened image opportunities
Obtaining hardened images is just the beginning of a long journey towards protecting your organization. Luckily, you don’t have to go through all the steps, obstacles, and the constant struggle for security all by yourself. There’s a better, simpler way: Wiz.
WizOS images provide a secure, production-ready foundation for containerized applications, offering hardened, minimal images with a near-zero CVE profile. Every release is signed and includes an SBOM to ensure provenance. Images are continuously managed by Wiz under SLA, removing the remediation burden from your developers.
The Wiz Security Graph correlates image CVEs with network exposure, identities, and data sensitivity, helping you spot unsafe images at a glance and prioritize the most pressing fixes first. Bidirectional code-to-cloud traceability provides everything your team needs to establish which service builds the image, who owns it, and how policies are enforced before it’s deployed.
Wiz’s container image inventory ensures that every image across all your code, cloud, and registries will be accounted for. Teams can quickly identify the most vulnerable images and prioritize them for migration to a hardened alternative like WizOS.
Ready to learn more? Register for a demo to see for yourself how Wiz can protect everything you build and run in the cloud!
Get a container security demo
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.
