Skip to content
SSCSB
Find a repository

Supply-chain security · scanned in public

What each
repository can prove

Every listing here is a public record of one scan of one commit — what it could prove, and what it could not.

— and what only its maintainer could.

An unperformed check is never a verdict. It is shown, and never counted.

A check that could not run is never a pass.

Every listing says what the scan saw, what it could not see, and who ran it. The second list is the one nobody usually publishes.

This lists defences the scan found, not weaknesses it found. A missing defence is not a break-in, and a full set of checks is not safety: nine groups and 54 checks do not cover everything. — the rule every list of defences on this site is published under
54 checks in the standard set
16 of the standard 54 only a maintainer's own machine can answer. Ten or eleven are in scope on a typical repository.
3 repositories on the board
6 phases the 54 checks are grouped into
9 attack groups the checks are written against
Checks that defend each attack group, split by where an answer could come from A1 Poisoned commit: 5 of 10 only a maintainer's own machine can answer A1 Poisoned commit: 5 of 10 answerable from outside A2 Stolen publisher identity: 4 of 13 only a maintainer's own machine can answer A2 Stolen publisher identity: 9 of 13 answerable from outside A3 Look-alike or invented package: 3 of 5 only a maintainer's own machine can answer A3 Look-alike or invented package: 2 of 5 answerable from outside A4 A real dependency turns hostile, or stays broken: 8 of 18 only a maintainer's own machine can answer A4 A real dependency turns hostile, or stays broken: 10 of 18 answerable from outside A5 Hijacked build pipeline: 1 of 15 only a maintainer's own machine can answer A5 Hijacked build pipeline: 14 of 15 answerable from outside A6 Compromised developer environment: 7 of 8 only a maintainer's own machine can answer A6 Compromised developer environment: 1 of 8 answerable from outside A7 Leaked credential: 0 of 8 only a maintainer's own machine can answer A7 Leaked credential: 8 of 8 answerable from outside A8 A flaw in the code you wrote: 1 of 5 only a maintainer's own machine can answer A8 A flaw in the code you wrote: 4 of 5 answerable from outside A9 Untrustworthy delivery: 3 of 15 only a maintainer's own machine can answer A9 Untrustworthy delivery: 12 of 15 answerable from outside

Nine ways in, and how many checks answer each.

The groups are drawn from the public catalogues of what has actually gone wrong. Every bar is the number of checks mapped to that group, split by where an answer could come from. A tall bar is not safety. It is how many questions we know to ask, and where the hatched part is most of a bar, an outside scan leaves most of that group’s questions open.

answerable from outside only on a maintainer’s own machine

One record covers the whole lifecycle.

Code moves from a commit to a published package. The 54 checks sit along that road in 6 groups, and one scan reads all 6 at once — including the ones it could not answer. (The tool's own stage model is T1–T7; this site groups the checks into 6 phases.)

The road code travels, from a commit to a published package, through 4 systems, with the 6 groups of checks marked along it 1. Commit integrity 2. Dependencies 3. Build receipts 4. Code & build hardening 5. Ongoing posture 6. Distribution & publishing
  1. 1Commit integrity
  2. 2Dependencies
  3. 3Build receipts
  4. 4Code & build hardening
  5. 5Ongoing posture
  6. 6Distribution & publishing
Three ways a record gets made, ranked: the project's own signed build, a scan from outside, and a maintainer's own machine 1. The project's own build, signed 2. A scan from outside 3. A maintainer's own machine

Three ways a record gets made, and they do not carry equal weight.

A record made in the project's own build is signed there, and the repository, the workflow and the branch are burned into that signature by an issuer neither side controls. A scan from outside proves nothing about who ran it — and anybody can run it again. A maintainer's own machine is the only place the last group of checks can be looked at, and the only lane where the party being measured is the party asserting the result.

Nine ways in

Each group below is a thing attackers have actually done. Open one to see which checks defend it, and one time it happened.

Every incident below links to a primary source — a CVE record, a government alert, or the affected project’s own write-up. Where this site has not opened that document, the line is marked reported.

01 — The record

What a listing holds

One scan, one commit, one date. Every check it ran, every check it could not, and the evidence behind both.

Who can see what

What anyone can read

Three groups of checks answer from things the project itself publishes. Every lane below starts here.

Committed files

26 checks the tree at one commit policy files never executed

Committed build files

6 checks the project's own build files read, never run

Live settings

4 checks branch rules repository settings read live

A scan from outside

Anyone can ask for a public repository to be read.

Nothing more

The shared row, read from outside. Nobody has to take the scanner's word for what it saw — the same files are there to read.

The project's own build

The same scan, run in the project's own CI.

signed

A signature

Which build produced the record burned in by the issuer not asserted by the record

A maintainer's machine

The only place the last group can be looked at.

The maintainer's machine

16 checks signing keys local hooks what no outside scan reaches

Two of the three can be checked by anyone. The third can only be asserted by the maintainer, and is weighted accordingly. How that is checked → + 2 about the tool — never counted. 52 of 54 are scored.

Commit integrity

13 checks belong to this phase.

Maintainer’s machine only

Dependencies

10 checks belong to this phase.

Maintainer’s machine only

Build receipts

10 checks belong to this phase.

Maintainer’s machine only

Code & build hardening

7 checks belong to this phase.

Maintainer’s machine only

Ongoing posture

8 checks belong to this phase.

Maintainer’s machine only

Distribution & publishing

6 checks belong to this phase.

Maintainer’s machine only

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 →

02 — The loop

How a listing is made

Five steps, and one record in the middle of them — signed when the lane can sign it. A scan is a snapshot, so the loop runs again rather than editing what it said last time.

  1. 01 Scan Clone, never run
  2. 02 Record Answered, or left open
  3. 03 Review A person reads it
  4. 04 Answer Run it, then sign it
  5. 05 Rescan One commit, one snapshot
the record scan-record.json signed when the lane can sign it One record. Every stage adds to it.

Nobody has to wait for us. Run it in your own build, or on your own machine, and sign the result.

03 — Every check

All 54, as questions

Pick a phase. Every check in it is a card, and every card is a question you can answer yes or no.

Key what the project commits a live read of its settings only a maintainer's machine about the tool, never counted the phase these checks belong to

Inputs

Checks

Record

committed files Everything in the tree at one commit, read and never run.
live settings A live read of what the project has switched on at GitHub.
the maintainer's machine Reachable from one machine only, and only by its owner.

13 checks belong to this phase. Each card opens the question that check answers.

10 checks belong to this phase. Each card opens the question that check answers.

10 checks belong to this phase. Each card opens the question that check answers.

7 checks belong to this phase. Each card opens the question that check answers.

8 checks belong to this phase. Each card opens the question that check answers.

6 checks belong to this phase. Each card opens the question that check answers.

One listing A grade 6 phase bars every check with its verdict. The words a listing uses: pass did not pass gap no answer out of scope not in this record.

04 — Scan your own

Three ways to start

They see different amounts, and the page always says which one produced a listing.

Run it in your build

The scan runs in your own CI and signs the record there. The signature proves which build made it.

Install the Action →

Run it on your machine

Some checks describe a developer's laptop. You are the only one who can answer those. Sign the result and send it in.

How that is checked →

Ask for a scan

Anyone can ask for any public repository to be read from outside. A person reviews the result before it appears.

Search, or request one →

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 →