Enhancing Artifact Security with GitHub’s Build Provenance...
summary
GitHub’s Build Provenance API produces SLSA-compatible in-toto attestations signed with Sigstore/Fulcio using ephemeral keys (certificates valid ~10 minutes plus third‑party timestamp), stores them in a content-addressable attestation store and can also push attestations to the OCI registry; verification uses the GitHub CLI and is a few lines of YAML in Actions. Minder consumes those attestations to create profiles that enforce and auto‑remediate policies (detecting a malicious build that appends a comment or an out‑of‑band registry push) via reusable workflows and org‑wide rules.
AI-written summary · about
chapters (19)
- 0:00Artifact security with GitHub
- 1:14GitHub artifact attestations
- 3:20Signing versus attestations
- 5:48Open source foundations
- 7:54Signing in GitHub Actions
- 9:37Ephemeral keyless signing benefits
- 12:31Sigstore public vs private
- 15:16Why build provenance matters
- 16:39Attestations in workflows
- 18:45Verify with CLI and Cosign
- 20:11Security beyond signing
- 21:35Demo workflow overview
- 23:57Verify artifacts with CLI
- 27:42Minder introduction
- 29:12Minder features
- 33:05Supply chain threats demo
- 35:51Setup Minder enforcement
- 39:22Custom Minder profile
- 44:52Strengthen security with Minder
related talks
39mAuthenticating Supply-chain Metadata: Building Remote Code Attestations on GitHub
36mWhere Does Your Software (Really) Come from?
54mFrom "Trust Me" to "Verify Me"
20mNot Just Ticking a Box – Establishing Trust in Artifacts with Proven...
40mSLSA with Us: The Dance of AppSec
33mGrowing the Chain: Trusting Build Provenance from Userspace
29mMake Your CI More Secure and Less Spicy with SLSA- 33mGrowing the Chain: Trusting Build Provenance from Userspace