sscsb▮

phase-0 · bootstrap

Supply chain
security,
stamped in.

An unperformed check is never a verdict.

Already listedp4gs/p4gs.github.iop4gs/sscs-bootstrapperp4gs/sscsb-action

3 repositories on the public record · browse them all →

VERIFICATION RECEIPT sscsb 0.3.0
$ sscsb verify
[PASS] secrets · no keys in the code
[PASS] commit-signing · humans sign main
[PASS] branch-protection · PR review
[PASS] slsa-provenance · build receipts
[FAIL] harden-runner · 1 job unwatched
[·····] signing-model · nobody can check
verify: 1 failed, 1 unanswered
PHASE-1
Commit integrity
PHASE-2
Dependencies
PHASE-3
Build receipts
PHASE-4
Code & build hardening
PHASE-5
Ongoing posture

Best scoring

Top rated

The listings that passed the most of what could be checked.

A "best scoring" list needs 12 listings and more than one grade among them. Otherwise it is just a tie, broken by a number this site says not to hold against anyone. There are 3 listings and 1 grade so far.

Browse every listing →

Freshest evidence

Recently scanned

A scan is a snapshot of one commit. These are the newest.

Every listing here was scanned by the same scheduled run, minutes apart, so ordering them by date would be ordering noise. This fills in once projects run their own scans on their own schedules.

Browse every listing →

Across every listing

Still unchecked

The checks that most often have no answer here — and why.

  • Does the project say which vulnerabilities actually apply to it? openvex 3 of 3 only a maintainer's own machine can answer this
  • Does the project publish an OpenSSF Scorecard result? scorecard 3 of 3 no source could answer it
  • Is signing set up the same way in every environment? signing-model 3 of 3 only a maintainer's own machine can answer this
  • Are installed tools and extensions checked against known compromises? bumblebee 2 of 3 only a maintainer's own machine can answer this

3 of these 4 describe a developer's own machine. No scan from outside can see them — a maintainer answers them by running the scan themselves and signing the result. How that is checked →

What the checks are for

Nine ways supply chains get attacked

Every check defends against at least one of these — or says plainly that it defends against none, and only tells outsiders what a project does.

A1Poisoned commit A2Stolen publisher identity A3Look-alike or invented package A4A real dependency turns hostile, or stays broken A5Hijacked build pipeline A6Compromised developer environment A7Leaked credential A8A flaw in the code you wrote A9Untrustworthy delivery
Each one, with what it looked like when it happened →

Scan your own

A scan from outside sees only what anyone can see. Run sscsb in your own build and it sees the rest — through the same review before publishing.

Install the Action How scoring works

Install the tool

54 checks, six phases, one command. It sets them up and then tells you, bluntly, which ones it could not answer.

brew install p4gs/p4gs/sscsb