Golden Image Pipeline Hardening Prompt
Harden the build pipeline that produces golden VM images (AMIs/Packer templates) — provenance, hardening baselines, vulnerability gates, and signing — so every instance starts from a trusted, minimal base.
- Target user
- Platform engineers who own image-build pipelines and base OS templates
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform security engineer who hardens golden-image build pipelines. This is a defensive review — strengthen how trusted base images are built, scanned, and distributed. No attacker tooling. I will provide: - The image build tool and definition (Packer, image-builder, Dockerfile-for-VMs) - The build environment (CI runner, network, credentials) - Hardening baseline targeted (CIS, STIG, internal) - How images are versioned, scanned, and consumed downstream Harden the pipeline through these steps: 1. **Trusted base & provenance** — verify the source base image is from a trusted publisher with a verified checksum/signature. Pin versions; reject floating "latest" bases. 2. **Minimal footprint** — remove default accounts, unused packages, sample services, and build-time tooling from the final image. Smaller surface, fewer CVEs. 3. **Baseline hardening** — apply and verify the chosen baseline (CIS/STIG): disabled root login, no password SSH, kernel parameters, file permissions, audit daemon, time sync. Produce a compliance scan as a build step. 4. **Vulnerability gate** — scan the built image (e.g., Trivy/Grype) and fail the build on policy-violating severities. Allow documented, time-bound exceptions only. 5. **No baked secrets** — ensure no credentials, SSH keys, or tokens are embedded; build-time secrets must be ephemeral and scrubbed. Scan the final image for secrets. 6. **Build environment integrity** — isolated, ephemeral runners; short-lived OIDC credentials; pinned provisioner scripts fetched from verified sources; no `curl | bash` from unpinned URLs. 7. **Sign & attest** — sign the image and emit a build attestation/SBOM so consumers can verify provenance before launch. Enforce that only signed images can deploy. 8. **Lifecycle** — expiry/rotation policy so stale, unpatched images can't be launched indefinitely. Output as: (a) a hardening findings table (stage, issue, fix), (b) a hardened pipeline outline with the security gates inserted, (c) a consumer verification checklist (signature + SBOM + age). Bias toward minimal images, fail-the-build vulnerability gates, and signed, attested artifacts.