ci: sign + attest released images and binary (provenance + SBOM, ADR-15)#18
Merged
Conversation
Extend design-principle 5 (signature-verified supply chain) to the artifacts we PUBLISH. The Dockerfile already checksum-verifies binaries it downloads; this adds publish-side provenance + SBOM so a tester can verify integrity and origin. release.yml now, per tag: - captures each per-minor image digest after push and attaches a keyless SLSA build-provenance attestation and an SPDX SBOM attestation (syft) by digest; the :<tag>/:latest aliases share that digest, so one attestation covers all. - attaches provenance + SBOM attestations to the release binary tarball. - self-verifies its own attestations (gh attestation verify) before publishing, so broken signing fails the release rather than reaching a tester. - tightens permissions to least privilege per job (top-level contents: read; images: packages+id-token+attestations; binary: contents+id-token+attestations). - pins the new signing/SBOM actions to commit SHAs. GitHub-native attestations (keyless OIDC, no private key); cosign deferred because ghcr lacks the OCI Referrers API. Verification documented in the release notes, README, and docs/testing.md. Security-architect reviewed the implementation: the SPDX predicate-type is the versioned https://spdx.dev/Document/v2.3 and anchore/sbom-action upload-release-assets is disabled so the scanner never authors Release assets. actionlint clean. Live proof is the first tag (the self-verify step). Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: William Rizzo <william.rizzo@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Sign and attest the artifacts the
Releaseworkflow publishes (ADR-15) -- the publish-side half of supply-chain principle 5. The Dockerfile already checksum-verifies what it downloads; this covers what we ship.Per tag,
release.ymlnow::<tag>/:latestaliases share the digest, so one attestation covers all three tags.gh attestation verify) before publishing -- a broken signing step fails the release, not a tester.contents: read).GitHub-native attestations (keyless OIDC, no private key); cosign deferred (ghcr lacks the OCI Referrers API). Verification is documented in the release notes,
README.md, anddocs/testing.md.Verification
actionlintclean. security-architect reviewed the implementation (CHANGES-REQUIRED -> both fixed): the SPDX predicate-type is the versionedhttps://spdx.dev/Document/v2.3, andanchore/sbom-actionupload-release-assetsis disabled. It confirmedpush-to-registrysucceeds on ghcr, permissions are correctly least-privilege, and the trigger is tag-push-only.Reviewed statically (a release cannot run without a tag); the live proof is the first tag, where the self-verify step exercises the whole chain end to end. CI + docs only; no production code.
🤖 Generated with Claude Code