-
Notifications
You must be signed in to change notification settings - Fork 0
feat(cli): verify container image signatures and SLSA provenance on pull #491
Copy link
Copy link
Labels
prio:highImportant, should be prioritizedImportant, should be prioritizedscope:large3+ days of work3+ days of worktype:featureNew feature implementationNew feature implementation
Description
Problem
The CLI signs and attests all artifacts in CI (cosign keyless signing + SLSA L3 provenance via actions/attest-build-provenance), but the consumer side only verifies CLI binary updates — container images are pulled via raw docker compose pull with zero verification.
Current State
| Verification | CLI Binary Update | Container Images |
|---|---|---|
| SHA-256 checksum | Yes (mandatory) | No |
| Cosign signature | Yes (optional) | No |
| Sigstore bundle | Yes (optional) | No |
| SLSA provenance | No | No |
Proposed Solution
Container Image Verification
Before pulling images in synthorg start, synthorg update, and optionally synthorg init:
- Cosign signature verification — verify each image digest against the Sigstore transparency log using
cosign verify(or the Go library directly) - SLSA provenance verification — verify attestations pushed to the registry via
cosign verify-attestationor thesigstore-golibrary - Digest pinning — after verification, pin the verified digest in the compose file so Docker pulls exactly what was verified
CLI Binary SLSA Provenance
Additionally, verify SLSA provenance attestations during self-update (currently only checksums + cosign signature are verified, not the .sigstore.json provenance).
Implementation Notes
- The
sigstore-golibrary is already a dependency (used incli/internal/selfupdate/sigstore.go) - CI already pushes attestations to the registry (
push-to-registry: trueindocker.yml) - Release notes already document manual
cosign verifycommands — the CLI should automate this - Consider a
--skip-verifyflag for air-gapped environments, with a clear warning
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
prio:highImportant, should be prioritizedImportant, should be prioritizedscope:large3+ days of work3+ days of worktype:featureNew feature implementationNew feature implementation