Container Image Provenance Verification Checklist Builder

You are a DevSecOps engineer helping a team verify container image provenance before production deployment. Build a checklist for:

Application context: [SaaS app, internal platform, open source service, regulated workload, Kubernetes service]
Container registry: [GHCR, ECR, GCR, ACR, Docker Hub, Harbor, other]
Build system: [GitHub Actions, GitLab CI, Buildkite, Jenkins, Cloud Build, Tekton, local builds]
Image types: [app images, base images, sidecars, jobs, operators, third-party images]
Current controls: [signed images, SBOMs, attestations, pinned digests, policy controller, vulnerability scanner]
Provenance goals: [SLSA level, audit evidence, deployment gate, customer assurance, incident response]
Trust boundaries: [internal builders, self-hosted runners, forks, release branches, third-party actions]
Deployment target: [Kubernetes, ECS, serverless containers, VM runtime, air-gapped environment]
Known risks: [mutable tags, untrusted base images, privileged builder, unsigned third-party images, registry compromise]
Tools available: [cosign, Rekor, in-toto, Syft, Grype, Trivy, Kyverno, OPA Gatekeeper, Sigstore policy-controller]
Compliance needs: [SOC 2, ISO 27001, FedRAMP, internal policy, customer questionnaire]

Create:
1. Image inventory with owner, source repo, registry, tag, digest, base image, and deployment target.
2. Provenance requirements for build trigger, source commit, builder identity, workflow file, branch protection, and artifact digest.
3. Signature and attestation verification checklist with example commands or policy checks.
4. Base image and third-party image trust review process.
5. SBOM and vulnerability evidence package tied to the exact image digest.
6. CI/CD release gate design for signed, attested, scanned, and approved images.
7. Kubernetes or runtime admission policy recommendations.
8. Incident response steps for revoked signatures, compromised builders, or suspicious image drift.
9. Rollout plan from report-only monitoring to enforcement.
10. Exceptions template with owner, expiry date, risk, compensating control, and approval.

Do not assume a tool is installed. Mark tool-specific commands as examples that must be adapted and tested in the team's environment.