Where Should Source Attestations Live? Exploring Storage Strategies
summary
Compares three concrete storage patterns for SLSA source attestations: keep attestations inside the git repo using Git notes / ref attestations, push them to provider APIs, or write them to independent storage buckets. Claims: repo refs improve provenance but hit provider permissioning limits and need extra ref-management tooling; buckets avoid repo rights but break discoverability; cosign + OCI referrers API offers a uniform discovery model but GitHub’s attestations API currently only accepts GitHub identities, blocking external builders like Chainguard from uploading.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:03What is an attestation
- 1:44What matters in attestations
- 2:06Attestations in code review
- 3:30Attestations in Git
- 4:56Git storage challenges
- 5:17Storage buckets for attestations
- 6:19API storage and discovery
- 7:00GitHub API limits
- 7:42State and future of storage
- 8:03Q&A
related talks
46mEnhancing Artifact Security with GitHub’s Build Provenance...
10mSource Attestations with Gitsign
39mAuthenticating Supply-chain Metadata: Building Remote Code Attestations on GitHub
21mBeyond SBOMs and SLSA: Build Trust With Custom Attestations for End-to-End Supply Chain Security
36mWhere Does Your Software (Really) Come from?
54mFrom "Trust Me" to "Verify Me"
20mReducing the Risk of Source Tampering With SLSA
20mNot Just Ticking a Box – Establishing Trust in Artifacts with Proven...