CVE-2026-33634
The Trivy scanner was turned into a credential thief: 76 of 77 trivy-action tags force-pushed to malicious commits. The thing scanning your images was the compromise.
Supply-chain security · GitHub-native
The digest is the release.
In 2026 the supply chain stopped being abstract. Scanners shipped malware, tags moved under running pipelines, and signed attestations described artifacts that never reached production. attested-delivery makes one promise legible: the thing you verified is the thing that runs — signed, SLSA-attested, and refused at the door if it can't be proven.
# anyone can re-check a release from a clean workstation $ gh attestation verify ./app --repo attested-delivery/rust-template ✓ verified SLSA provenance · CycloneDX SBOM · digest sha256:2d0586…
Mutable tags
A git tag is a pointer, not an identity. A force-push silently re-points it at new bytes. Nothing in your workflow changes; the next run just pulls different code.
Orphaned attestations
You sign a provenance in CI, then promotion rebuilds the image. Production runs a different digest. Your signature is genuine — and describes bytes that never shipped.
How it works 1 2 3 4 5 6
Six guarantees, all on GitHub-native tooling
No new control plane to run. The backend is GitHub Actions with OIDC, Sigstore/cosign, the Rekor transparency log, and SLSA provenance — wired so that immutable identity is the only thing in the trust path.
Pin every action by commit SHA
A tag can be force-pushed; a commit SHA cannot. Every third-party action is pinned to its immutable commit, and a required pin-check job fails the build if anything slips back to a tag.
uses: actions/checkout@<full-40-char-sha> Build once, get provenance
One build in CI produces one content digest. GitHub Actions OIDC mints a short-lived identity — no long-lived signing keys — and emits SLSA provenance bound to that exact digest.
predicateType: https://slsa.dev/provenance/v1 Attest what it contains
A CycloneDX SBOM and test-result attestations are signed keyless with Sigstore/cosign and recorded in the Rekor transparency log. Every claim is a statement about the digest.
cosign attest --type cyclonedx --yes $IMAGE Promote the digest, never rebuild
Promotion copies the same digest forward — dev to staging to prod — and re-verifies it. Because the bytes never change, the provenance and SBOM keep applying to what actually runs.
cosign copy $IMAGE@sha256:… $PROD@sha256:… Fail closed at admission
At the deploy boundary, an unverifiable artifact does not deploy. Verification is enforced at admission, not by convention — a missing or mismatched attestation is a hard stop.
gh attestation verify $ART --repo $OWNER/$REPO Anyone can re-check it
The whole chain is public and content-addressed. A reviewer, an auditor, or a downstream consumer re-verifies the release independently from a clean workstation — no trust required.
gh attestation verify ./artifact --repo $OWNER/$REPO Quickstart
Verify a release in two minutes
You don't need the org's permissions or its secrets to check its work. Every published release re-verifies from a clean machine. Start by proving an existing one, then adopt the pipeline.
Verify an existing release
- Install the GitHub CLI and authenticate (
gh auth login). - Download a published artifact from a template repo.
- Verify its SLSA provenance and SBOM — offline-checkable against the digest.
terminal
# 1 · pull a signed release artifact gh release download v0.1.0 \ --repo attested-delivery/attested-pipeline-template \ --pattern '*-linux-amd64' # 2 · verify build provenance (SLSA L3) gh attestation verify ./app-linux-amd64 \ --repo attested-delivery/attested-pipeline-template # 3 · verify the bill of materials gh attestation verify ./app-linux-amd64 \ --repo attested-delivery/attested-pipeline-template \ --predicate-type https://cyclonedx.org/bom ✓ verification succeeded — digest sha256:2d0586…
Adopt the pipeline in your repo
- Start from a template repo (it ships the gates pre-wired).
- Turn on SHA-pinning enforcement and the required pin-check job.
- Tag a release; CI signs, attests, and publishes — keyless.
terminal
# 1 · create your repo from the attested template gh repo create my-org/my-service \ --template attested-delivery/attested-pipeline-template \ --private --clone # 2 · cut a release — the workflow does the rest git tag v0.1.0 && git push origin v0.1.0 # 3 · CI signs keyless via OIDC + Sigstore, then logs to Rekor # no long-lived keys; identity is the workflow itself cosign attest --type cyclonedx --yes \ ghcr.io/my-org/my-service@sha256:…
Prefer Rust? Start from attested-delivery/rust-template — five-platform build,
SBOM, and the same gates.
Community All org discussions →
Raise your posture with people doing the same
attested-delivery is a public reference org, not a product pitch. The workflows, templates, and docs are open so your team can adopt them, audit them, and improve them.
Read the reference docs
Concepts, ADRs, and full pipeline specifications — the why behind every gate, with sources you can follow.
Open the docs →Start from a template
Language-agnostic and Rust attested templates, both publishing independently-verifiable v0.1.0 releases today.
Browse templates →Join org discussions
Ask how a gate works, propose a hazard worth defending against, or share how you adopted attested delivery in your org — all in one org-wide space.
Open discussions →Contribute
Issues, reusable workflows, and the docs are open. Good first issues are labeled; every change ships through the same attested pipeline it describes.
Read CONTRIBUTING →Talk it through in the open
Questions, proposals, and adoption stories live in the org-wide discussion space — one place across every attested-delivery repo. Comment below or open a thread.