OpenSSF Scorecard: Opinionated 0 to 10 Security Heuristics, a Weekly Scan of 1.3 Million Repositories and a Retired BigQuery Dataset

Every step of the scoring is opinionated, and the project says so in its non-goals

Scorecard assesses a number of heuristics, called checks, associated with software security, and gives each check a score from 0 to 10. The README is unusually direct about the limits. Its first non-goal is to be a definitive report or requirement that all projects should follow. Every step of making the results is opinionated: which checks are included or excluded, how important each is, and how scores are calculated. The checks are heuristics, and the README states plainly that there are false positives and false negatives.

For a reader, that changes how to use a score. A low number is a prompt to look at which check lost points, not proof that a project is unsafe, and a high number does not prove safety. Different audiences care about different subsets of behavior, so the project accepts that it cannot satisfy everyone.

The aggregate score hides which behaviors a repository has, and it moves when heuristics change

The README warns that aggregate scores tell you nothing about what individual behaviors a repository is or is not doing. Many check scores are combined into a single number, and there are multiple ways of arriving at the same score. Those scores also change as new heuristics are added or existing ones refined.

That has two consequences. A badge showing 7.2 today cannot be compared directly with a figure from a year ago, because the scoring itself may have shifted. And a policy such as only use dependencies scoring above 7 is fragile. With the V5 release, the project points to Structured Results as the better route: instead of relying on an aggregate X out of 10, a consumer can check a specific behavior, for example that a repository is not archived, which the archived probe covers. The OpenSSF takes this approach with its own Security Baseline.

The weekly scan covers over 1.3 million repositories, and the BigQuery dataset is gone

Scorecard scans more than 1.3 million repositories every week, from the ossf/scorecard-infra repository, and the results are available through a REST API at api.scorecard.dev. The README states that the BigQuery public dataset is no longer available and points to an issue titled Scorecard Infrastructure Changes for details.

Anyone whose pipeline used BigQuery for bulk analysis has to move to the REST API, which is built for lookups of pre-calculated scores rather than large dumps. To get a project into the weekly scan, you follow the contributing guide in scorecard-infra, not this repository. The README also notes that scores calculated from the weekly scan omit certain checks, naming CI-Tests and Contributors among them. So an API score and a locally run CLI score for the same repository are not guaranteed to match.

The viewer URL is a template that accepts GitHub or GitLab paths

To see scores for regularly scanned projects, you use the web viewer at scorecard.dev. You can also build a link for a specific repository from a template: the viewer address followed by a uri parameter made of github or gitlab, then .com, then the user or organization and the repository name. The examples given are the ossf/scorecard repository on GitHub and fdroid/fdroidclient on GitLab.

That tells you two things. The hosted viewer is not limited to GitHub. And it only shows projects that are already scanned: for a project not included in the viewer, the README directs you to the command line tool. This matters for private or very new repositories, which will not appear in the weekly scan. The CLI is the route that works on the repositories you can reach with your own credentials, and its documentation covers prerequisites, installation, authentication and basic usage.

The GitHub Action runs on repository changes and reports through the Security tab

The README calls the Scorecard GitHub Action the easiest way to use Scorecard on GitHub projects you own. The Action runs on any repository change and issues alerts that maintainers can see in the repository's Security tab. It lives in its own repository, ossf/scorecard-action, with its own installation instructions.

The wording limits the claim to projects you own on GitHub. For a dependency you do not control, the Action is not the tool; the viewer, the API or the CLI are. The Action is also a continuous check, so it fits maintainers who want regressions flagged when a workflow or setting changes, as opposed to a one-off assessment. The repository also offers badges and an MCP server according to the README's contents list, so scores can be surfaced in a project's README or queried by an agent.

The Go module is v5, but several badges still point at v4

The go.mod module path is github.com/ossf/scorecard/v5 on Go 1.26.5, with dependencies including cobra for the command line, go-git, ghinstallation for GitHub App authentication, go-containerregistry, buildkit and gocloud.dev. The README's pkg.go.dev and Go Report Card badges, however, point at the v4 module path.

If you import Scorecard as a library, use the v5 path, and do not trust the badge links to take you to the current documentation. The repository layout shows how the tool is built: checks, probes, policy, clients, cron, remediation and finding directories, plus a write.md guide for adding a new check. The recent releases are v5.6.0 on 2026-10-12, v5.5.0 on 2026-04-23 and v5.4.0 on 2025-11-14, a cadence of roughly one minor release every few months, so pin a version in CI and read the release notes before upgrading.

Prominent users show adoption, not that the scores are right

The README says Scorecard has been run on thousands of projects and lists TensorFlow, Angular, Flutter, sos.dev and deps.dev among prominent users. That is evidence of use, and it is the project's own statement.

It does not validate individual check results. The same document that names these users also says the checks have false positives and false negatives. So a better reading is that Scorecard is widely used as a signal that people look at, and the right response to a surprising score is to open the detailed check documentation, which describes scoring criteria, risks and remediation. The project also asks you to report problems, and its charter, contributor ladder and governance files in the root show that it runs as an OpenSSF project with a formal structure, which affects how quickly a disputed check can be changed.

Editorial conclusion

Scorecard suits maintainers who want an automated, repeatable list of security practices to improve and consumers who want a first look at a dependency. It does not suit anyone who wants a verdict: the project says its checks are opinionated heuristics with false positives. Use individual checks and probes, not the aggregate number, for decisions.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. ossf/scorecard on GitHub
3. Project website
4. README
5. Releases