SSCSB

Supply-chain scans, on the record

Methodv2 Schemav1

The public record

A check that could not run is not a pass.

Every listing here says what the scan saw, what it could not see, and who ran it. A check nobody could answer is shown, and counted for nobody.

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

3 repositories on the board · open the directory

54
checks, each answered or left unanswered
3
ways a scan can be run
A+
means every answered check passed
0
unanswered checks are counted against anyone

The board so far

Not enough listings yet

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.

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 →

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 →

Who runs it

Three ways a scan gets run

From outside

Anyone can ask for any public repository to be scanned. The scan sees only what anyone can see. It says which checks it could not answer.

How scoring works

From your build

Run sscsb in your own build and it sees settings an outside scan cannot. It then signs the result, so the signature proves where it came from.

Install the Action

From your machine

About a dozen checks describe a developer's own laptop. No scan reaches there. A maintainer answers them by running the scan and signing it.

How that is checked