Images are signed using Docker Content Trust or Cosign; verification enforced at deployment
Why it matters
Unsigned container images can be silently replaced in a registry — an attacker who gains push access to a registry can swap a legitimate image for a malicious one with the same tag, and every subsequent deployment pulls the compromised image without any cluster-level detection (CWE-494, NIST 800-53 CM-14, SLSA L3). Image signing with Cosign or Docker Content Trust creates a cryptographically verifiable chain from the image back to the CI system that built it. SSDF 800-218 PS.2.1 requires build provenance. Without admission webhook enforcement, signing alone is advisory — images can still be deployed without verification.
Severity rationale
Low because unsigned image exploitation requires registry write access as a prerequisite, making it a targeted rather than opportunistic attack vector.
Remediation
Sign images during CI/CD with Cosign and enforce verification at admission. In .github/workflows/build.yml:
# Generate key pair once, store private key as CI secret
cosign generate-key-pair
# Sign after push
cosign sign --key cosign.key $IMAGE_REF
Store COSIGN_PRIVATE_KEY and COSIGN_PASSWORD as CI secrets. The public key (cosign.pub) is committed to the repository. For enforcement, deploy Sigstore's policy-controller and create a ClusterImagePolicy referencing your public key — this blocks admission of any pod whose image digest cannot be verified against the policy.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Infrastructure Hardening Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-494 — Download of Code Without Integrity Check
- slsa:1.0 · L3 — Artifact signing and verification
- nist:rev5 · CM-14 — Signed Components
- ssdf:800-218 · PS.2.1 — Use methods for uniquely identifying software releases
- soc2:2017 · CC6.8 — Prevention and detection of unauthorized or malicious software
Taxons
History
- 2026-04-18·v1.0.0·Initial import from infrastructure-hardening·automated
- 2026-07-06·v1.0.1·Add SOC 2 TSC mapping (CC6.8) from the verified compliance crosswalk register (docs/compliance/).·by soc2-mapping-enrichment-ship-2