Software Release Pipeline Integrity Scorecard
Rate the controls that decide whether a tampered release could be pushed into your software — and whether you would catch it before a customer does. Seven weighted dimensions: protected publishing, immutable & signed assets, developer account security, two-person releases, consumer build provenance, detection & monitoring and disclosure readiness. You get a banded 0–100 score, a radar of where you are strong and weak, and the gaps ranked so you fix the ones that close the attack path first. The weighting is a transparent heuristic, nothing is uploaded, and the score is shareable by permalink.
Why this exists. In October 2026, OVHcloud disclosed that a malicious, secrets-stealing binary had been pushed into tagged releases of its CLI. Per that disclosure, a hacker used a developer's GitHub account to publish the tampered releases — the account owner was not the attacker — and a customer flagged the unexpected binary roughly 94 minutes after it appeared. Every dimension below maps to a control that would have blocked that path or caught it internally, rather than leaving detection to a customer. This scorecard does not reproduce the incident or name any individual; it uses it only as the motivating example.
The release path is open to the attack a stolen developer account exercises: a single account could publish a tampered release, it might not be signed or immutable, and nobody internal would likely catch it. Treat protected publishing, signing and account MFA as the first, non-negotiable fixes.
Score per dimension (0–100)
Prioritised gaps
Highest-weight, lowest-scoring controls first — spend remediation effort here.
- Protected publishing · unanswered
Move all release builds into a dedicated CI pipeline and remove the ability to publish from a workstation.
Reference: NIST SSDF
- Protected publishing · unanswered
Run releases in an isolated runner with short-lived, job-scoped credentials; retire long-lived personal tokens for publishing.
- Immutable & signed assets · unanswered
Make published versions immutable so a tag or release cannot be re-pushed with different bytes.
- Immutable & signed assets · unanswered
Sign every release artifact with Sigstore/cosign or an equivalent, and document how consumers verify it.
Reference: Sigstore / cosign
- Developer account security · unanswered
Require phishing-resistant MFA (FIDO2 / passkeys) on all accounts with write or release access.
Reference: FIDO2 / passkeys
- Developer account security · unanswered
Minimise who holds release access and separate scoped machine accounts from human accounts.
- Two-person releases · unanswered
Require a second approver before a release is published; remove any single-actor publish path.
- Consumer build provenance · unanswered
Pin dependencies to exact versions with recorded integrity hashes; stop consuming floating tags or branches.
Reference: pinned checksums
+ 20 more gaps in the full export.
Protected publishing · weight 18
Releases come ONLY from a locked-down, approval-gated CI pipeline — never a developer’s laptop or a direct push. A stolen workstation or personal token should not be able to publish anything.
Release artifacts are produced only by a dedicated CI pipeline; no one can build and publish a release from a local machine.
The release pipeline runs in a hardened, isolated environment using scoped, short-lived credentials — not a long-lived personal access token.
Direct pushes and tag creation on release branches are blocked for everyone; the pipeline is the only publisher.
Publishing secrets (registry tokens, signing keys) exist only inside the release job and are never present on a developer workstation.
Immutable & signed assets · weight 16
Published artifacts cannot be silently rebuilt over an existing tag, are cryptographically signed, and carry build provenance. An attacker should not be able to overwrite a good release in place.
Published artifacts are immutable — an existing version or tag cannot be silently re-uploaded or overwritten with new content.
Every published artifact is cryptographically signed (e.g. Sigstore / cosign or an equivalent).
Signed build provenance / attestation (e.g. SLSA) is generated and published alongside each release.
Checksums are published for every release asset and tied back to the signed provenance.
Developer account security · weight 16
Most supply-chain pushes enter through an account, not an exploit. Phishing-resistant MFA on every account with release access, SSO, least privilege, and prompt offboarding.
Every account with write or release access uses phishing-resistant MFA (passkeys / FIDO2), not SMS or TOTP alone.
Access to the source organisation and the package registry is behind SSO with enforced MFA.
Write / release access follows least privilege — few accounts hold it, and machine / bot accounts are scoped and kept separate from humans.
Offboarding promptly revokes repository, registry and signing access when a contributor leaves or changes role.
Two-person releases · weight 14
No single actor can cut a release. Protected branches, required reviews, and a second approver on publish — so one compromised account is not enough.
A release requires approval from a second person — no single actor can publish unilaterally.
Release branches are protected and require pull-request review before merge; direct commits are disallowed.
The approval is enforced by the platform (e.g. required reviewers on the deployment environment), not left to convention.
Release approvals are logged and attributable, so after the fact you can see who authorised each publish.
Consumer build provenance · weight 13
As a consumer, you install from pinned, verified checksums via a module proxy — not a mutable tag — and you verify signatures before an artifact is used.
Dependencies are pinned to exact versions with verified integrity hashes (lockfile / checksum database), not floating tags or branches.
You install through a module proxy / verifying mirror (e.g. the Go module proxy and checksum database) rather than pulling mutable tags directly.
Artifact signatures and/or provenance are verified before an artifact is installed or promoted.
CI fails closed if a dependency’s integrity hash or signature does not match what was previously recorded.
Detection & monitoring · weight 13
You would notice an unexpected committer, a “dirty” or unexpected build, or a new binary in a release — without relying on a customer to spot it first.
Releases are monitored for unexpected contributors — a commit or tag from a non-member or an unusual account raises an alert.
Build outputs are checked for unexpected contents — a new binary, a “dirty” build, or an artifact that does not match the expected output is flagged.
The package registry / artifact store is monitored for new or changed releases, and alerts reach the team quickly.
You do not depend on a customer or external finder to detect a malicious release; internal detection exists.
Disclosure readiness · weight 10
A private reporting channel exists so finders need not open a public issue, and an incident comms / rotation plan is ready — pull bad assets, revoke signatures, and guide users to rotate exposed secrets.
A private vulnerability-reporting channel exists (e.g. a SECURITY policy with a private contact or coordinated-disclosure process) so finders need not open a public issue.
An incident comms plan is ready: how you notify users and advise them to pull or rotate affected assets.
You can quickly pull or yank a malicious release from the registry and revoke its signatures / tags.
A secret-rotation runbook exists — if a malicious binary could have exfiltrated credentials from users’ machines, you can guide affected users to rotate exposed secrets.
Heuristic self-assessment. The dimension weights are a transparent judgement framework for structured self-reflection, not a measurement, certification or guarantee of outcome. This tool references SLSA, Sigstore, FIDO2, the NIST Secure Software Development Framework and CISA supply-chain guidance by name only; it quotes no invented statistics, performs no scan, and runs entirely in your browser — nothing is uploaded. Your answers are stored only in the shareable link you choose to copy. Not legal advice.
What this scorecard is
- A free, 100% in-browser self-assessment: rate your software-release and developer-account integrity across the seven controls that decide whether a tampered release could be pushed — and whether you would catch it — and get a banded 0–100 score.
- Seven weighted dimensions: protected publishing, immutable & signed assets, developer account security, two-person releases, consumer build provenance, detection & monitoring, and disclosure readiness.
- Each item rates None / Partial / Strong / Verified and maps to a concrete next action; gaps are ranked highest-weight, lowest-score first so you fix the controls that close the attack path soonest.
- The weighting is a transparent HEURISTIC for structured self-reflection, not a measurement or certification. It names SLSA, Sigstore, FIDO2, the NIST SSDF and CISA guidance by name only and quotes no invented statistics.
- Nothing is uploaded. Export to Markdown or CSV, and share the exact scorecard with a permalink (your answers are encoded in the link, base64url).
Integrity is decided by how you release, not just what you ship
A supply-chain compromise rarely needs a clever exploit. More often it needs an account — one with the rights to publish — and a release path that trusts whoever holds it. If a release can be built on a laptop and pushed straight to a tag, if artifacts are not signed or can be silently overwritten, and if nobody internal is watching for an unexpected committer or an unexpected binary, then a single stolen credential is enough. This scorecard turns that attack path into a structured checklist so the gaps are visible while there is still time to close them.
The seven dimensions are weighted on purpose — protected publishing, signed and immutable assets and developer account security carry the most, because they most directly close the path a stolen developer account exercises. That weighting is a heuristic, shown openly so you can argue with it and adjust it to your environment. The scorecard references well-known public guidance — SLSA, Sigstore, FIDO2, the NIST Secure Software Development Framework and CISA supply-chain material — by name, as orientation. It is a self-assessment framework, not a certification, it quotes no invented statistics, and it is not legal advice.
Frequently asked questions
What does the Release Integrity Scorecard measure?
It is a self-assessment of the controls that govern how your software is released and who can release it: whether releases come only from a locked-down CI pipeline, whether artifacts are immutable and signed with provenance, whether every account with release access uses phishing-resistant MFA, whether a release needs a second approver, whether consumers verify what they install, whether you would detect an unexpected release yourself, and whether you are ready to disclose and respond. You rate each item None, Partial, Strong or Verified and the tool produces a weighted 0–100 score with a band and a prioritised gap list.
Why these seven dimensions?
They are the standard supply-chain controls exercised by the attack path where a stolen developer account is used to push a malicious build into tagged releases. In October 2026 OVHcloud disclosed exactly this against its CLI — a hacker used a developer’s GitHub account to publish a secrets-stealing binary, and a customer flagged it. The seven dimensions map to the controls that would block or quickly catch that path: gated publishing, signing/immutability, account security, two-person release, consumer-side verification, detection, and disclosure readiness.
Is the score a real measurement or a benchmark?
No. It is a transparent heuristic framework for structured self-reflection, not a measurement, benchmark, audit or certification, and it does not predict any outcome. The weights (protected publishing, signing and account security carry the most) reflect how directly each control closes the stolen-account attack path, and they are shown openly so you can adjust them to your own environment. The value is the structured conversation and the prioritised to-do list, not the exact number.
Does it scan anything or send my answers anywhere?
No. The scorecard runs entirely in your browser. It performs no scan and touches no repository or registry. Your answers are never uploaded — they live only in the shareable permalink you choose to copy (encoded in the URL) and in any Markdown or CSV file you export yourself.
What frameworks does it draw on?
It is organised around widely published supply-chain guidance — SLSA for build provenance, Sigstore/cosign for signing, FIDO2/passkeys for phishing-resistant authentication, verifying module proxies and checksum databases for consumer-side integrity, and the NIST Secure Software Development Framework and CISA supply-chain guidance for the overall shape. It names these sources for orientation only and does not reproduce or quote figures from them; the question wording is PlayCISO’s own plain-language paraphrase. This is not legal advice.
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.