Full Report
WizOS is now available in private preview for Wiz customers. It’s a key part of how we help teams start secure and stay secure with hardened, minimal container images.
Analysis Summary
# Best Practices: Hardened Minimal Container Base Images for Software Supply Chain Security
## Overview
These practices focus on mitigating inherited risk within the software supply chain by adopting hardened, minimal container base images (like WizOS, Distroless, or Wolfi) to drastically reduce the attack surface and vulnerability noise originating from underlying operating system layers.
## Key Recommendations
### Immediate Actions
1. **Inventory Base Image Usage:** Identify all distinct base images (e.g., Ubuntu, Debian, Alpine) currently used across all services and repositories.
2. **Establish Zero-Critical CVE Policy:** Immediately enforce a strict policy mandating zero critical CVEs for all production and staging container images entering the pipeline.
3. **Review and Prioritize Migrations:** For services currently using bloated or unmanaged base images, prioritize migration paths for the most frequently breaking or highest-risk deployments.
### Short-term Improvements (1-3 months)
1. **Pilot Hardened Image Adoption:** Select a set of non-critical services currently using Alpine or similar lightweight distros and migrate them to a hardened, minimal base image replacement (e.g., WizOS compatibility layer or equivalents like Distroless/Wolfi).
2. **Validate Build Pipeline Integrity:** Perform security reviews across the entire CI/CD chain for migrated services, specifically validating image provenance, signing mechanisms, and deployment workflows using the new base.
3. **Update Developer Tooling:** Ensure vulnerability scanners, logging agents, and audit tools are correctly configured to detect and report on the new minimal base image layers and associated provenance data.
### Long-term Strategy (3+ months)
1. **Standardize Base Image Foundation:** Select and mandate a single, hardened, minimal base distribution (e.g., WizOS or equivalent) as the standard foundation for all new service development to enforce configuration consistency.
2. **Automate Base Image Upgrades:** Implement automated testing and validation pipelines to facilitate intelligent, frequent upgrades of the base image rather than relying on chasing the "latest" unstable tag, ensuring stable and secure delivery at scale.
3. **Expand Image Hardening Scope:** Work toward expanding the hardening efforts beyond the OS layer to include common application-layer images (e.g., language-specific runtimes) built on the standardized base foundation.
## Implementation Guidance
### For Small Organizations
* **Focus on Simplicity:** Start by adopting well-established minimal images like Alpine or Google's Distroless for greenfield projects.
* **Vendor Trust:** Leverage the security efforts of major vendors or community projects where rebuilding from source is impractical (e.g., using signed, official Red Hat UBI images).
* **Documentation Review:** Require every new service to explicitly document its base image in the `Dockerfile` and justify its security posture.
### For Medium Organizations
* **Phased Migration:** Run parallel environments where services are tested against the reference hardened image before fully switching production deployments.
* **Package Manager Shift:** Plan for the necessary refactoring when migrating from package-manager heavy environments (like Ubuntu/Debian) to minimal images, focusing on replacing dependency installation scripts (e.g., migrating reliance on `apt`/`yum` to bundled dependencies or static linking).
* **Internal Visibility:** Utilize tools to track adoption across repositories and flag non-compliant base images proactively.
### For Large Enterprises
* **Reproducible Build Mandate:** Mandate that the base image must employ a reproducible build pipeline with signed components and verifiable provenance for all layers.
* **Compatibility Layer Development:** If custom legacy dependencies exist, invest in developing a customized, hardened distribution (like an internal WizOS clone) compatible with existing application contracts (e.g., switching libc if necessary, like Alpine's musl to glibc).
* **Policy Enforcement:** Use cloud-native security tools (like admission controllers in Kubernetes) to automatically block deployments that rely on undeclared or non-compliant base images.
## Configuration Examples
* **Dockerfile Reference Update:** Replace existing base image declarations:
* *Before:* `FROM ubuntu:22.04` or `FROM alpine:latest`
* *After (Example):* `FROM internal-registry/wizos:2.1` or `FROM gcr.io/distroless/static`
* **Package Manager Removal:** In Dockerfiles, remove all steps related to package installation (`RUN apt-get update && apt-get install...`) if migrating to a minimal, pre-packaged runtime image.
* **Provenance Validation:** Configure CI/CD steps to check for specific metadata (e.g., Sigstore/SLSA attestations) upon pulling the base image to ensure it meets source verification requirements.
## Compliance Alignment
* **NIST SP 800-218 (Secure Software Development Framework - SSDF):** Directly supports the Protect (P8: Protect Software) and Identity (ID.AM-3: Ensure components have identity and provenance) functions by hardening foundational layers.
* **ISO/IEC 27001/27034:** Addresses Annex A controls related to system acquisition and development, specifically by managing and reducing third-party component risk (vulnerability in base images).
* **CIS Benchmarks:** Supports practices related to minimizing software footprint and limiting the installed operating system components on container hosts and within containers.
* **FIPS Compliance:** Adopting hardened distributions that support FIPS-compliant cryptographic foundations saves manual validation effort during regulated environment audits.
## Common Pitfalls to Avoid
* **Chasing "Latest":** Avoid continuously upgrading to the absolute latest distribution tag without functional validation; this leads to instability. Upgrade based on tested, named versions.
* **Ignoring Third-party Dependencies:** Assuming a minimal base image solves all problems; developers must still rigorously scan and secure application-layer dependencies installed on top of the base.
* **Skipping Migration Testing:** For services moving from large distributions (Ubuntu), assume necessary refactoring (package manager replacement, configuration file locations) will be required; do not treat it as a simple drop-in replacement.
* **Inconsistent Standardization:** Allowing different teams to adopt various minimal images; standardization is key to efficient vulnerability management and policy enforcement across the organization.
## Resources
* Google’s Distroless initiative (for resource context on minimal images)
* Red Hat’s Universal Base Images (UBI) (for enterprise-grade base image alternatives)
* Chainguard’s Wolfi OS (for open-source, security-focused distribution information)