Discover / Security

OpenSSF Scorecard

by ossfGo

Automated tool that assesses open source projects for security risks and best practices.

Toolstable

Maturity: stable because 6y old, v5.5.0 released 102d ago. Derived from release and commit history, not a rating.

Stars
5.6k
Forks
688
Downloads / mo
Last commit
2026-08-01
License
Apache-2.0
Open issues
438

Market and trust evidence

Edition not yet matched

No exact skills.sh identity match is available for this repository. Repository adoption and freshness remain visible above; install momentum is not inferred.

Trust analysis is a screening signal, not a security warranty. Read the ranking and trust methodology.

In practice

Written by AI from this repository’s README · medium confidence

A maintainer or consumer has no automated way to judge whether a dependency follows basic security practices.

Use it when

Use it when you want repeatable security posture metrics on your own project or on dependencies you are evaluating.

Not the right pick when

The README states it is not a one-size-fits-all solution and that the checks are heuristics with false positives and false negatives.

Capabilities

  • automated security heuristic checks scored 0-10
  • GitHub Action for continuous scoring
  • REST API for scores
  • score badges for repositories
  • command line interface for local runs
  • public data on scanned projects

Cost: Free and open source

Video walkthroughs

Third-party YouTube uploads matched to this tool by title, channel and repository name on 2026-08-03. Not made, reviewed or endorsed by SkillPilot. View counts and publish months are as of the match date and the month is approximate. Nothing loads from YouTube until you press play.

What the repository ships

Has docsDocker imageSecurity policyCI configured

Detected from the actual files in the repository root.

Latest release v5.5.0

Published 2026-04-23

What's Changed

General

  • The official Scorecard docker images are hosted on GitHub Container Registry starting with v5.5.0.

Older releases will be brought over from Google Container/Artifact Registry, before being discontinued.(@spencerschrock in https://github.com/ossf/scorecard/pull/4885)

  • Scorecard will now skip checks that don't apply to the current repo type by @JamieMagee in https://github.com/ossf/scorecard/pull/5000.

If any checks no longer run that previously ran, and you think are supported by the underlying forge please file an issue.

Checks

Branch-Protection

  • :seedling: Use rulesets if one exists when classic branch protection rule is inaccessible by @trask in https://github.com/ossf/scorecard/pull/4853

CII-Best-Practices

  • :sparkles: Support custom CII_Best_Practices_URL via environment variable. by @kash2104 in https://github.com/ossf/scorecard/pull/4882

Dangerous-Workflow

  • :bug: detect toJSON(github.event) in Dangerous-Workflow check by @heathdutton in https://github.com/ossf/scorecard/pull/4898

Contributors

  • :bug: Skip CODEOWNERS file in contributors check if there is a parsing error by @juanis2112 in https://github.com/ossf/scorecard/pull/4851

Dependency-Update-Tool

  • :sparkles: Removing pyup checks by @colinosullivan-ie in https://github.com/ossf/scorecard/pull/4877

Fuzzing

  • :sparkles: Detect .NET property-based fuzz testing by @martincostello in https://github.com/ossf/scorecard/pull/4860

Docs

  • :book: Add Security Insights file and update maintainer affiliation by @justaugustus in https://github.com/ossf/scorecard/pull/4863
  • :book: doc: add CDN design to repository by @spencerschrock in https://github.com/ossf/scorecard/pull/4932
  • :book: Scorecard v6: OSPS Baseline conformance proposal and 2026 roadmap by @justaugustus in https://github.com/ossf/scorecard/pull/4952

Other

  • :seedling: cron: remove error wrapping workaround by @alexandear in https://github.com/ossf/scorecard/pull/4864
  • :seedling: deps: switch from gopkg.in/yaml.vX to go.yaml.in/yaml/vX by @scop in https://github.com/ossf/scorecard/pull/4895
  • :seedling: ci: use smaller repo for gitlab e2e tests to avoid timeouts by @spencerschrock in https://github.com/ossf/scorecard/pull/4924
  • :seedling: Bump go-github to v82 by @Kielek in https://github.com/ossf/scorecard/pull/4923
  • :seedling: ci: remove all e2e test references to gitlab.com/gitlab-org/gitlab by @spencerschrock in https://github.com/ossf/scorecard/pull/4927
  • :seedling: cron: Add ability to purge cached results from a CDN by @spencerschrock in https://github.com/ossf/scorecard/pull/4928
  • :seedling: cron: enable CDN purging in prod weekly scans by @spencerschrock in https://github.com/ossf/scorecard/pull/4931
  • :seedling: Set OSV User-Agent for scorecard cli and cron workers. by @kash2104 in https://github.com/ossf/scorecard/pull/4883
  • :seedling: Fix PR verifier by replacing deprecated Docker action by @justaugustus in https://github.com/ossf/scorecard/pull/4972
  • :seedling: e2e: add Azure DevOps tests by @JamieMagee in https://github.com/ossf/scorecard/pull/4993
  • :seedling: Fix PR template formatting by @martincostello in https://github.com/ossf/scorecard/pull/5003
  • :seedling: Add Jamie Magee as a maintainer for Azure DevOps by @JamieMagee in https://github.com/ossf/scorecard/pull/5024

New Contributors

  • @juanis2112 made their first contribution in https://github.com/ossf/scorecard/pull/4851
  • @alexandear made their first contribution in https://github.com/ossf/scorecard/pull/4864
  • @colinosullivan-ie made their first contribution in https://github.com/ossf/scorecard/pull/4877
  • @kash2104 made their first contribution in https://github.com/ossf/scorecard/pull/4882
  • @heathdutton made their first contribution in https://github.com/ossf/scorecard/pull/4898
  • @Kielek made their first contribution in https://github.com/ossf/scorecard/pull/4923

Full Changelog: https://github.com

Tags

README

OpenSSF Scorecard

OpenSSF Scorecard

OpenSSF Best Practices

build

CodeQL

Go Reference

Go Report Card

codecov

SLSA 3

Slack

<img align="right" src="artwork/openssf_security_compressed.png" width="200" height="400">

Overview

  • What Is Scorecard?
  • Prominent Scorecard Users
  • View a Project's Score
  • Scorecard's Public Data

Using Scorecard

  • Scorecard GitHub Action
  • Scorecard REST API
  • Scorecard Badges
  • Scorecard Command Line Interface
  • Prerequisites
  • Installation
  • Authentication
  • Basic Usage

Checks

  • Default Scorecard Checks
  • Detailed Check Documentation (Scoring Criteria, Risks, and

Remediation)

  • Beginner's Guide to Scorecard Checks

Other Important Recommendations

  • Two-factor Authentication (2FA)

Scoring

  • Aggregate Score

Contribute

  • Report Problems
  • Code of Conduct
  • Contribute to Scorecard
  • Add a New Check
  • Connect with the Scorecard Community
  • Report a Security Issue

FAQ

  • FAQ

Overview

What is Scorecard?

We created Scorecard to help open source maintainers improve their security

best practices and to help open source consumers judge whether their dependencies

are safe.

Scorecard is an automated tool that assesses a number of important heuristics

("checks") associated with software security and assigns

each check a score of 0-10. You can use these scores to understand specific

areas to improve in order to strengthen the security posture of your project.

You can also assess the risks that dependencies introduce, and make informed

decisions about accepting these risks, evaluating alternative solutions, or

working with the maintainers to make improvements.

The inspiration for Scorecard’s logo:

"You passed! All D's ... and an A!"

Project Goals
  1. Automate analysis and trust decisions on the security posture of open source

projects.

  1. Use this data to proactively improve the security posture of the critical

projects the world depends on.

  1. Act as a measurement tool for existing policies

If OSS consumers require certain behaviors from their dependencies,

Scorecard can be used to measure those. With the V5 release, we see

Structured Results as a way of doing this if there is a supported analysis.

Instead of relying on an aggregate score of X/10, or a Maintained score of

Y/10, an OSS consumer may want to ensure the repo they're depending on

isn't archived (which is covered by the archived probe). The OpenSSF

takes this approach with its own Security Baseline for projects.

Project Non-Goals
  1. To be a definitive report or requirement that all projects should follow.

Scorecard is not intended to be a one-size-fits-all solution. Every step of

making our results is opinionated: what checks get included or excluded,

the importance of each check, and how scores are calculated. The checks

themselves are heuristics; there are false positives and false negatives.

Whether it’s due to applicability, or feasibility, or a matter of opinion,

what's included or excluded from Scorecard results leads to a lot of

discussion. It’s impossible to create a Scorecard that satisfies everyone

because different audiences will care about different subsets of behavior.

Aggregate scores in particular tells you nothing about what individual

behaviors a repository is or is not doing. Many check scores are aggregated

into a single score, and there’s multiple ways of arriving at the same

score. These scores change as we add new heuristics or refine the existing

ones.

Prominent Scorecard Users

Scorecard has been run on thousands of projects to monitor and track security

metrics. Prominent projects that use Scorecard include:

View a Project's Score

To see scores for projects regularly scanned by Scorecard, navigate to the webviewer. You can also replace the placeholder text (platform, user/org, and repository name) in the following template link to generate a custom Scorecard link for a repo:

https://scorecard.dev/viewer/?uri=<github_or_gitlab>.com/<user_name_or_org>/<repository_name>

For example:

To view scores for projects not included in the webviewer, use the Scorecard CLI.

Public Data

We run a weekly Scorecard scan of the 1 million most critical open source

projects judged by their direct dependencies and publish the results in a

BigQuery public dataset.

This data is available in the public BigQuery dataset

openssf:scorecardcron.scorecard-v2. The latest results are available in the

BigQuery view openssf:scorecardcron.scorecard-v2_latest.

You can query the data using BigQuery Explorer by navigating to Add Data > Star a project by name > 'openssf'.

For example, you may be interested in how a project's score has changed over time:


SELECT date, score FROM `openssf.scorecardcron.scorecard-v2` WHERE repo.name="github.com/ossf/scorecard" ORDER BY date ASC

You can extract the latest results to Google Cloud storage in JSON format using

the bq tool:


# Get the latest PARTITION_ID
bq query --nouse_legacy_sql 'SELECT partition_id FROM
openssf.scorecardcron.INFORMATION_SCHEMA.PARTITIONS WHERE table_name="scorecard-v2"
AND partition_id!="__NULL__" ORDER BY partition_id DESC
LIMIT 1'

# Extract to GCS
bq extract --destination_format=NEWLINE_DELIMITED_JSON
'openssf:scorecardcron.scorecard-v2$<partition_id>' gs://bucket-name/filename-*.json

The list of projects that are checked is available in the

cron/internal/data/projects.csv

file in this repository. If you would like us to track more, please feel free to

send a Pull Request with others. Currently, this list is derived from **projects

hosted on GitHub ONLY**. We do plan to expand them in near future to account for

projects hosted on other source control systems.

Using Scorecard

Scorecard GitHub Action

The easiest way to use Scorecard on GitHub projects you own is with the

Scorecard GitHub Action. The Action

runs on any repository change and issues alerts that maintainers can view in the

repository’s Security tab. For more information, see the Scorecard GitHub

Action

installation instructions.

Scorecard REST API

To query pre-calculated scores of OSS projects, use the REST API.

Scores calculated from our weekly scan omit the CI-Tests,

Contributors, and Dependency-Update-Tool checks due to the API costs

associated with running them at scale.

API results are cached with a CDN (thanks to Fastly and their Fast Forward program). Results are purged from the CDN when new results are available, but if you notice issues with stale data, please open an issue.

To enable your project to be available on the REST API, set

publish_results: true

in the Scorecard GitHub Action setting.

Data provided by the REST API is licensed under the CDLA Permissive 2.0.

Scorecard Badges

Enabling publish_results: true

in Scorecard GitHub Actions also allows maintainers to display a Scorecard badge on their repository to show off their

hard work. This badge also auto-updates for every change made to the repository. See more details on this OSSF blogpost.

To include a badge on your project's repository, simply add the following markdown to your README:


[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/{owner}/{repo}/badge)](https://scorecard.dev/viewer/?uri=github.com/{owner}/{repo})

Scorecard Command Line Interface

To run a Scorecard scan on projects you do not own, use the command line

interface installation option.

Prerequisites

Platforms: Currently, Scorecard supports OSX and Linux platforms. If you are

using a Windows OS you may experience issues. Contributions towards supporting

Windows are welcome.

Language: You must have GoLang installed to run Scorecard

(https://golang.org/doc/install)

Installation
Docker

scorecard is available as a Docker container:


docker pull ghcr.io/ossf/scorecard:latest

To use a specific scorecard version (e.g., v3.2.1), run:


docker pull ghcr.io/ossf/scorecard:v3.2.1
Standalone

To install Scorecard as a standalone:

Visit our latest release page and

download the correct zip file for your operating system.

Add the binary to your GOPATH/bin directory (use go env GOPATH to identify your directory if necessary).

Verifying SLSA provenance for downloaded releases

We generate SLSA3 signatures using the OpenSSF's slsa-framework/slsa-github-generator during the release process. To verify a release binary:

  1. Install the verification tool from slsa-framework/slsa-verifier#installation.
  2. Download the signature file attestation.intoto.jsonl from the GitHub releases page.
  3. Run the verifier:

slsa-verifier -artifact-path <the-zip> -provenance attestation.intoto.jsonl -source github.com/ossf/scorecard -tag <the-tag>
Using package managers

Package Manager | Supported Distribution | Command

---------------------------------------------------------- | ---------------------- | -------

Nix | NixOS | nix-shell -p nixpkgs.scorecard

AUR helper | Arch Linux | Use your AUR helper to install scorecard

Homebrew | macOS or Linux | brew install scorecard

Authentication

GitHub imposes api rate limits

on unauthenticated requests. To avoid these limits, you must authenticate your

requests before running Scorecard. There are two ways to authenticate your

requests: either create a GitHub personal access token, or create a GitHub App

Installation.

When creating the personal access token, we suggest you choose the

public_repo scope. Set the token in an environment variable called

GITHUB_AUTH_TOKEN, GITHUB_TOKEN, GH_AUTH_TOKEN or GH_TOKEN using the

commands below according to your platform.


# For posix platforms, e.g. linux, mac:
export GITHUB_AUTH_TOKEN=<your access token>
# Multiple tokens can be provided separated by comma to be utilized
# in a round robin fashion.
export GITHUB_AUTH_TOKEN=<your access token1>,<your access token2>

# For windows:
set GITHUB_AUTH_TOKEN=<your access token>
set GITHUB_AUTH_TOKEN=<your access token1>,<y

Truncated. Read the full README on GitHub ↗

Related tools