GitHub Release Integrity Checklist
A release is the moment your code becomes someone else's dependency. Score the controls that make the published artifact verifiable — pin the release source to a repo you control, verify tag == artifact, trusted publishing / OIDC instead of long-lived registry tokens, signed releases and attestation, SLSA provenance, reproducible builds and a protected release environment with a human gate on a hardware key. Controls tagged LiteLLM each break a link in the October 2026 LiteLLM-style release compromise. Nothing is uploaded.
Mark each release-integrity control as in place, partial or missing. Controls tagged LiteLLM each break a link in the October 2026 LiteLLM-style release compromise (fork-source release, exfiltrated publish credentials). Scored in your browser — nothing is uploaded.
Release source & provenance
Make sure what ships is built from code you control, not from an attacker-chosen source.
- Pin the release source to a ref in a repo you controlLiteLLMcritical
The release must be built from a protected branch/tag in your own repository — never from a fork, a PR head, or an arbitrary ref an attacker can choose.
- Verify the published artifact matches the signed tagLiteLLMhigh
The artifact that lands on the registry/release must be the one built from the exact reviewed, signed tag — not a side-loaded file.
- Reproducible buildsmedium
A byte-identical rebuild from the same source lets anyone independently confirm the artifact was not tampered with after build.
- Protect release tags against overwrite/deletionhigh
A mutable release tag can be re-pointed at malicious code after review. Tag protection rules stop that.
Trusted publishing & signing
Remove long-lived registry tokens, and make every artifact verifiable.
- Trusted publishing (OIDC) to PyPI / npm — no long-lived tokensLiteLLMcritical
OIDC trusted publishing lets the registry trust a short-lived identity from your CI instead of a static API token that can leak and be reused.
- Signed releases / artifact attestationLiteLLMhigh
Sign artifacts (Sigstore) and publish build provenance / attestations so consumers can verify who built what, from which source.
- Generate build provenance (SLSA)medium
Provenance records the builder, source and parameters, so a release built from the wrong source is detectable, not invisible.
- Publish and verify checksumslow
Published digests let downstream users detect a swapped binary even without full attestation tooling.
Protected environment & human gate
Put a human with a hardware key between "build done" and "published to the world".
- Protected release environment with required reviewersLiteLLMcritical
A GitHub deployment environment with required reviewers forces a human approval before the release job can access publishing secrets.
- Require a hardware security key (FIDO2) for the release approverhigh
A phishing-resistant hardware key on the approver's account means a stolen password or OTP cannot approve a release.
- Scoped, short-lived release credentialsLiteLLMhigh
Publishing credentials should exist only for the release job, be minimal in scope, and expire quickly — not sit in a broadly-readable secret.
- Separate the release pipeline from PR/CILiteLLMhigh
Keeping publishing secrets out of the PR-triggered CI means untrusted contributor code never runs in the same context as release credentials.
Prioritised gaps (12)
- 1.criticalLiteLLMNot assessed
Pin the release source to a ref in a repo you control
Fix: Trigger releases only from protected tags/branches of the canonical repo; reject release builds from forks or unprotected refs.
- 2.criticalLiteLLMNot assessed
Trusted publishing (OIDC) to PyPI / npm — no long-lived tokens
Fix: Configure PyPI/npm trusted publishing (OIDC) from the release workflow and delete the long-lived registry API tokens.
- 3.criticalLiteLLMNot assessed
Protected release environment with required reviewers
Fix: Create a "release" / "production" environment, require reviewers, and scope publishing secrets to that environment only.
- 4.highLiteLLMNot assessed
Verify the published artifact matches the signed tag
Fix: Build the artifact in CI from the tag and publish only that build output; compare the release artifact's digest against the CI build's digest.
- 5.highNot assessed
Protect release tags against overwrite/deletion
Fix: Add tag protection rules (or a ruleset) so release tags cannot be created, moved or deleted except by authorised actors.
- 6.highLiteLLMNot assessed
Signed releases / artifact attestation
Fix: Enable GitHub artifact attestations (or cosign/Sigstore) for each release and publish the attestation alongside the artifact.
- 7.highNot assessed
Require a hardware security key (FIDO2) for the release approver
Fix: Require WebAuthn/FIDO2 2FA for everyone who can approve the release environment, and disallow weaker factors for them.
- 8.highLiteLLMNot assessed
Scoped, short-lived release credentials
Fix: Use OIDC or short-lived tokens scoped to the release environment; never store a long-lived publish token in a repo/org secret readable by all workflows.
- 9.highLiteLLMNot assessed
Separate the release pipeline from PR/CI
Fix: Run releases in a dedicated workflow/environment that PR builds cannot reach; never expose publish secrets to pull_request(_target) jobs.
- 10.mediumNot assessed
Reproducible builds
Fix: Pin toolchains and dependencies, strip non-determinism (timestamps, paths), and document how to reproduce the build.
Scored entirely in your browser — nothing is read or uploaded. Control themes follow GitHub artifact attestations, PyPI/npm trusted-publishing (OIDC) and SLSA provenance guidance. Educational — not affiliated with GitHub.
What this checklist is
- A self-assessment of the controls that decide whether a release people install is really the code you reviewed and signed — not one built from an attacker-chosen source or published with a stolen token.
- Twelve controls across three areas: release source & provenance, trusted publishing & signing, and a protected release environment with a human gate on a hardware key.
- Covers pinning the release source to a repo you control, verifying tag == artifact, trusted publishing / OIDC to PyPI/npm (no long-lived tokens), signed releases and artifact attestation, SLSA provenance, reproducible builds and a protected environment with required reviewers.
- Controls tagged "LiteLLM" each break a link in the October 2026 LiteLLM-style release compromise, where a release was built from a fork source and publishing credentials were exfiltrated from CI.
- Mark each In place / Partial / Missing for a weighted 0–100 score, a per-area breakdown, prioritised gaps and an exportable report. 100% client-side.
Why this matters
The October 2026 LiteLLM GitHub-identity supply-chain compromise reached its victims through a release. As publicly reported, after exfiltrating CI secrets the attacker published a release built from a fork source — code that was never the reviewed, canonical source — using credentials that should never have been reachable from an ordinary pipeline.
Release integrity controls are what make that substitution fail instead of ship. If the pipeline only builds from a pinned source you control, only publishes via a short-lived OIDC identity rather than a stealable token, attests every artifact to its source commit, and requires a human on a hardware key to approve the publish, then a fork-built release has no path to the registry and a stolen secret has nothing to publish with. The point is to remove the standing, reusable capabilities — long-lived publish tokens and unverified, ungated releases — that a CI compromise turns into a downstream one. This is an educational self-assessment referencing a real, reported incident for context; PlayCISO is not affiliated with LiteLLM or GitHub.
Frequently asked questions
What is trusted publishing (OIDC) and why does it matter here?
Trusted publishing lets a package registry like PyPI or npm trust a short-lived identity token issued to your CI run over OIDC, instead of a long-lived API token stored as a secret. Long-lived publish tokens are exactly the kind of credential that gets exfiltrated from CI and reused to push a malicious version. With OIDC trusted publishing there is no standing token to steal — the registry trusts the specific workflow in the specific repository, for that run only.
What does "verify tag == artifact" mean?
It means the artifact you publish must be the one built in CI from the exact reviewed and signed tag — not a file someone uploaded by hand or built from a different source. You enforce it by building in CI from the tag, publishing only that build output, and comparing the release artifact's digest against the CI build's digest (and, better, a signed attestation of it). This is what stops a "release built from a fork source" from passing as the real thing.
What is artifact attestation / SLSA provenance?
Attestation is a signed statement about an artifact — who built it, from which source commit, with which workflow. GitHub artifact attestations and SLSA build provenance let a consumer verify, before they install, that a package really was built by your pipeline from your source. A release built from the wrong source fails verification instead of silently installing.
Why a protected environment with a hardware key?
A GitHub deployment environment with required reviewers forces a human to approve before the release job can touch publishing secrets, and scoping those secrets to that environment keeps them out of ordinary CI. Requiring the approver to use a phishing-resistant hardware security key (FIDO2) means a stolen password or one-time code cannot approve a release. Together they put a real, hard-to-phish human gate between "build done" and "published to the world".
How does this map to the LiteLLM incident?
As publicly reported, the October 2026 LiteLLM compromise included publishing a release built from a fork source after exfiltrating CI secrets. Pinning the release source, verifying tag == artifact, using OIDC trusted publishing instead of a stealable token, attesting the build, and gating publication behind a human on a hardware key are the controls that each would have broken that step. This tool references a real, reported incident for context and is not affiliated with LiteLLM or GitHub.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.