Golden Image

A golden image is never patched in place. Any change triggers a new build and a new semantic version or digest. This guarantees that the image running in production is identical to the one tested in staging.

• Content-addressable: Identified by a SHA256 digest, not a mutable tag.
• Eliminates drift: Prevents 'works on my machine' scenarios by forbidding runtime modifications.
• Rollback ready: Instantaneous reversion to a previous known-good digest.

The image is stripped of all non-essential binaries, package managers, and shells. This minimalist footprint drastically reduces the potential vectors for a breach.

• Distroless base: Often built from scratch or distroless images containing only the application runtime.
• No root: Runs as a non-privileged user by default, enforcing the principle of least privilege.
• Read-only filesystem: The root filesystem is mounted as read-only to prevent malicious writes.

Every OS package, library, and runtime component is curated and scanned before inclusion. The golden image serves as a gatekeeper for the software supply chain.

• Curated SBOM: A Software Bill of Materials is generated and attested for every build.
• Vulnerability-free: Scanned with tools like Trivy or Grype; high or critical CVEs block the build pipeline.
• Licensing compliance: Only packages with approved open-source licenses are included.

Environment-specific variables are strictly externalized. The image contains zero secrets and relies on runtime injection for configuration.

• Env-var driven: All dynamic behavior is controlled via environment variables, not baked-in config files.
• Secrets management: Integrates with external vaults; never stores API keys or certificates in layers.
• Uniform logging: Ships with a pre-configured agent that outputs structured JSON to stdout/stderr.

The image is signed using a tool like Cosign as part of the CI/CD pipeline. This creates a tamper-proof attestation that the image was produced by a trusted builder.

• Keyless signing: Uses OIDC-based identities to sign without managing long-lived private keys.
• SLSA provenance: Attests to the build environment, source code, and build commands used.
• Admission control: Kubernetes admission controllers enforce that only signed images can be deployed.

A single semantic tag resolves to a manifest list containing platform-specific images for amd64 and arm64. This abstracts hardware complexity from the deployment process.

• Unified tag: Developers pull app:1.0.0 without specifying architecture.
• Edge to cloud: The same golden standard applies to both massive GPU clusters and tiny edge nodes.
• OCI-compliant: Built to the OCI Image Specification for maximum runtime portability.

A unique, content-addressable SHA256 hash that immutably identifies a specific container image manifest or layer. Unlike mutable tags, the digest provides cryptographic verification of integrity—pulling by digest guarantees you deploy the exact same bytes every time.

• Example: sha256:abc123...
• Generated from the manifest content, not the tag
• Essential for deterministic deployments and golden image enforcement

A Software Bill of Materials is a nested inventory of all components, libraries, and dependencies packaged within a golden image. It provides supply chain transparency by enumerating every package, version, and transitive dependency.

• Formats: SPDX, CycloneDX
• Enables rapid vulnerability triage when CVEs are disclosed
• Increasingly mandated by Executive Order 14028 and federal compliance frameworks

A minimal container image containing only the application and its runtime dependencies—no package managers, shells, or standard OS utilities. This dramatically reduces the attack surface of a golden image.

• No apt, yum, bash, or sh
• Attackers cannot spawn shells even if they achieve code execution
• Produced by Google's Bazel build system for language-specific runtimes

A tool under the Sigstore project used to cryptographically sign container images and OCI artifacts. Signatures are stored alongside the image in the registry, enabling keyless signing via OpenID Connect identities.

• Verifies the image was built by an authorized CI/CD pipeline
• Stores signatures as OCI artifacts in the same repository
• Integrates with Kyverno and Admission Controllers for enforcement

A security framework providing a tamper-proof, attestable record of the build process and origin of a golden image. SLSA (Supply-chain Levels for Software Artifacts) defines progressive levels of trust.

• Level 1: Build is scripted and documented
• Level 3: Build runs on hardened, isolated platforms with non-falsifiable provenance
• Level 4: Requires two-person review and hermetic, reproducible builds

A deploy-time security control that enforces strict signature validation before a container image can be deployed. It ensures only golden images signed by trusted authorities during the build process reach production.

• Implemented via Kubernetes Admission Controllers
• Validates attestations including SBOMs and vulnerability scan results
• Prevents deployment of unsigned or unauthorized images even with valid pull credentials