How package scores are calculated
Every package page carries a score card — up to five rows, each a score out of 100, never a count of anything. This page explains where each number comes from, and why some packages show fewer rows.
The five categories
Four categories roll up checks published by OpenSSF Scorecard; the grouping into categories is ours. The fifth, Advisories, is built from our own advisory data.
| Category | What it measures | OpenSSF checks |
|---|---|---|
| Supply chain security | Whether the project's build and release path can be tampered with — dependency pinning, release signing, CI token scope, and workflow safety. | |
| Advisories | Known security advisories affecting this package or anything it depends on at runtime. | Not an OpenSSF check |
| Quality | Engineering practices that catch defects before release — review, static analysis, tests, and fuzzing. | |
| Maintenance | Whether the project is actively looked after — recent commit activity, a published security policy, and contributor breadth. | |
| License | Whether the project publishes a license the tooling can identify. |
Checks we leave out
Three of the checks OpenSSF publishes are left out of every category, so they never affect a score:
- Packaging — not applicable to most packages in this catalog, so it would tell you almost nothing.
- Vulnerabilities — the Advisories row already covers this, from our own advisory data.
- Branch-Protection — it can only be fully read with repository-admin access, so it comes back incomplete for much of the catalog.
From OpenSSF's 0-10 to the card's 0-100
OpenSSF scores each check from 0 to 10, and the card's hover breakdown shows those raw values exactly as OpenSSF reports them. The category score converts them to a single 0-100 value.
A category score is the mean of its usable checks, multiplied by 10 and rounded:
category = round(mean(usable check scores) x 10)
For example: a category holding three checks that score 10, 8 and one that does not apply averages the two usable scores to 9 and shows 90.
Checks that do not apply
When OpenSSF could not evaluate a check it reports -1, and that check is simply left out of the average — a check that could not run is not a failure. When no usable check remains, the category shows —: no signal, rather than a bad score.
How the Advisories score works
The Advisories row is scored from the advisories currently affecting the package — its own and those reaching it through its runtime dependencies. The score is set by the single worst active severity, not by how many advisories there are.
One critical advisory matters more than ten low-severity ones, and a count cannot express that. A package with no active advisories scores 100; otherwise the score follows the worst active severity:
| Worst active severity | Score |
|---|---|
| No active advisories | 100 |
| Critical | 10 |
| High | 25 |
| Medium | 60 |
| Low | 75 |
| Unrated | 70 |
Direct and transitive advisories are scored together, so a package with a clean record of its own still scores low when something it depends on carries a critical advisory. The row's hover breakdown shows the two separately.
What the colours mean
Each score is coloured by the band it falls into. Colour is never the only signal — the number is always shown, and assistive technology reads the band name alongside it.
| Score | Band | Appearance |
|---|---|---|
| 100 | Strong | 100 |
| 80–99 | Strong | 80 |
| 50–79 | Partial | 50 |
| 0–49 | Weak | 0 |
| — | Not scored | — |
A perfect 100 gets a bolder green than the rest of the Strong band. It is a visual emphasis only — both read as Strong.
Why some packages have no scorecard
OpenSSF Scorecard analyses a source repository. We track where each package is published from, and for some sources there is no repository to analyse — so no scorecard can exist, now or later. Those packages show the Advisories row and nothing else.
- Sources a scorecard can cover:
- GitHub repository, GitLab repository
- Sources with no repository to analyse:
- GNU project, SourceForge, Project website
A package from a supported source that still shows no scorecard is a gap in our data, not a judgement on the project — usually the upstream scan has not reached it yet.
The Advisories row is unaffected either way. It is built from our advisory data, not from project metadata, so it renders for every package in the catalog.
How packages enter the catalog
The catalog is a public repository. Every package in it is defined by a Nickel build spec, compiled from source, and built in a hermetically sealed environment.
Every change to the catalog is a commit on that repository: packages added, packages removed, version upgrades, and advisory changes. The catalog changes page lists them, newest first.
A score does not decide whether a package is in the catalog. Nothing in the pipeline admits or removes a package on the basis of its score; the numbers describe what we found, and are published whether they flatter the project or not.
None of the five scores is an editorial judgement. Four are arithmetic over checks OpenSSF publishes, and the fifth follows the advisory table above. Our choices — which checks group into which category, and where the colour bands fall — are all on this page; no package's score is ever set by hand.