- Default Scorecard Checks
- Detailed Check Documentation (Scoring Criteria, Risks, and Remediation)
- Report Problems
- Code of Conduct
- Contribute to Scorecard
- Add a New Check
- Connect with the Scorecard Community
- Report a Security Issue
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!"
-
Automate analysis and trust decisions on the security posture of open source projects.
-
Use this data to proactively improve the security posture of the critical projects the world depends on.
Scorecard has been run on thousands of projects to monitor and track security metrics. Prominent projects that use Scorecard include:
To see scores for projects regularly scanned by Scorecard, navigate to the webviewer, replacing the placeholder text with the platform, user/org, and repository name: https://securityscorecards.dev/viewer/?uri=<github_or_gitlab>.com/<user_name_or_org>/<repository_name>.
For example:
- https://securityscorecards.dev/viewer/?uri=github.com/ossf/scorecard
- https://securityscorecards.dev/viewer/?uri=gitlab.com/fdroid/fdroidclient
To view scores for projects not included in the webviewer, use the Scorecard CLI.
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 ASCYou 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.
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.
To query pre-calculated scores of OSS projects, use the REST API.
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.
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:
[](https://securityscorecards.dev/viewer/?uri=github.com/{owner}/{repo})
To run a Scorecard scan on projects you do not own, use the command line interface installation option.
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)
scorecard is available as a Docker container:
docker pull gcr.io/openssf/scorecard:stableTo use a specific scorecard version (e.g., v3.2.1), run:
docker pull gcr.io/openssf/scorecard:v3.2.1To 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).
We generate SLSA3 signatures using the OpenSSF's slsa-framework/slsa-github-generator during the release process. To verify a release binary:
- Install the verification tool from slsa-framework/slsa-verifier#installation.
- Download the signature file
attestation.intoto.jsonlfrom the GitHub releases page. - Run the verifier:
slsa-verifier -artifact-path <the-zip> -provenance attestation.intoto.jsonl -source github.com/ossf/scorecard -tag <the-tag>| 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 |
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.
- Create a classic GitHub personal access token.
When creating the personal access token, we suggest you choose the
public_reposcope. Set the token in an environment variable calledGITHUB_AUTH_TOKEN,GITHUB_TOKEN,GH_AUTH_TOKENorGH_TOKENusing 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>,<your access token2>OR
- Create a GitHub App Installation
for higher rate-limit quotas. If you have an installed GitHub App and key
file, you can use the three environment variables below, following the
commands (
setorexport) shown above for your platform.
GITHUB_APP_KEY_PATH=<path to the key file on disk>
GITHUB_APP_INSTALLATION_ID=<installation id>
GITHUB_APP_ID=<app id>
These variables can be obtained from the GitHub developer settings page.
Scorecard can run using just one argument, the URL of the target repo:
$ scorecard --repo=github.com/ossf-tests/scorecard-check-branch-protection-e2e
Starting [CII-Best-Practices]
Starting [Fuzzing]
Starting [Pinned-Dependencies]
Starting [CI-Tests]
Starting [Maintained]
Starting [Packaging]
Starting [SAST]
Starting [Dependency-Update-Tool]
Starting [Token-Permissions]
Starting [Security-Policy]
Starting [Signed-Releases]
Starting [Binary-Artifacts]
Starting [Branch-Protection]
Starting [Code-Review]
Starting [Contributors]
Starting [Vulnerabilities]
Finished [CI-Tests]
Finished [Maintained]
Finished [Packaging]
Finished [SAST]
Finished [Signed-Releases]
Finished [Binary-Artifacts]
Finished [Branch-Protection]
Finished [Code-Review]
Finished [Contributors]
Finished [Dependency-Update-Tool]
Finished [Token-Permissions]
Finished [Security-Policy]
Finished [Vulnerabilities]
Finished [CII-Best-Practices]
Finished [Fuzzing]
Finished [Pinned-Dependencies]
RESULTS
-------
Aggregate score: 7.9 / 10
Check scores:
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| SCORE | NAME | REASON | DOCUMENTATION/REMEDIATION |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 10 / 10 | Binary-Artifacts | no binaries found in the repo | github.com/ossf/scorecard/blob/main/docs/checks.md#binary-artifacts |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 9 / 10 | Branch-Protection | branch protection is not | github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection |
| | | maximal on development and all | |
| | | release branches | |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| ? | CI-Tests | no pull request found | github.com/ossf/scorecard/blob/main/docs/checks.md#ci-tests |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 0 / 10 | CII-Best-Practices | no badge found | github.com/ossf/scorecard/blob/main/docs/checks.md#cii-best-practices |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 10 / 10 | Code-Review | branch protection for default | github.com/ossf/scorecard/blob/main/docs/checks.md#code-review |
| | | branch is enabled | |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 0 / 10 | Contributors | 0 different companies found -- | github.com/ossf/scorecard/blob/main/docs/checks.md#contributors |
| | | score normalized to 0 | |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 0 / 10 | Dependency-Update-Tool | no update tool detected | github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 0 / 10 | Fuzzing | project is not fuzzed in | github.com/ossf/scorecard/blob/main/docs/checks.md#fuzzing |
| | | OSS-Fuzz | |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 1 / 10 | Maintained | 2 commit(s) found in the last | github.com/ossf/scorecard/blob/main/docs/checks.md#maintained |
| | | 90 days -- score normalized to | |
| | | 1 | |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| ? | Packaging | no published package detected | github.com/ossf/scorecard/blob/main/docs/checks.md#packaging |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 8 / 10 | Pinned-Dependencies | unpinned dependencies detected | github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies |
| | | -- score normalized to 8 | |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 0 / 10 | SAST | no SAST tool detected | github.com/ossf/scorecard/blob/main/docs/checks.md#sast |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 0 / 10 | Security-Policy | security policy file not | github.com/ossf/scorecard/blob/main/docs/checks.md#security-policy |
| | | detected | |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| ? | Signed-Releases | no releases found | github.com/ossf/scorecard/blob/main/docs/checks.md#signed-releases |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 10 / 10 | Token-Permissions | tokens are read-only in GitHub | github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions |
| | | workflows | |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|
| 10 / 10 | Vulnerabilities | no vulnerabilities detected | github.com/ossf/scorecard/blob/main/docs/checks.md#vulnerabilities |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|The GITHUB_AUTH_TOKEN has to be set to a valid token
docker run -e GITHUB_AUTH_TOKEN=token gcr.io/openssf/scorecard:stable --show-details --repo=https://github.com/ossf/scorecardTo use a specific scorecard version (e.g., v3.2.1), run:
docker run -e GITHUB_AUTH_TOKEN=token gcr.io/openssf/scorecard:v3.2.1 --show-details --repo=https://github.com/ossf/scorecardFor more details about why a check fails, use the --show-details option:
./scorecard --repo=github.com/ossf-tests/scorecard-check-branch-protection-e2e --checks Branch-Protection --show-details
Starting [Pinned-Dependencies]
Finished [Pinned-Dependencies]
RESULTS
-------
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
| SCORE | NAME | REASON | DETAILS | DOCUMENTATION/REMEDIATION |
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
| 9 / 10 | Branch-Protection | branch protection is not | Info: 'force pushes' disabled | github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection |
| | | maximal on development and all | on branch 'main' Info: 'allow | |
| | | release branches | deletion' disabled on branch | |
| | | | 'main' Info: linear history | |
| | | | enabled on branch 'main' Info: | |
| | | | strict status check enabled | |
| | | | on branch 'main' Warn: status | |
| | | | checks for merging have no | |
| | | | specific status to check on | |
| | | | branch 'main' Info: number | |
| | | | of required reviewers is 2 | |
| | | | on branch 'main' Info: Stale | |
| | | | review dismissal enabled on | |
| | | | branch 'main' Info: Owner | |
| | | | review required on branch | |
| | | | 'main' Info: 'admininistrator' | |
| | | | PRs need reviews before being | |
| | | | merged on branch 'main' | |
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
To run Scorecard on a GitLab repository, you must create a GitLab Access Token with the following permissions:
read_apiread_userread_repository
You can run Scorecard on a GitLab repository by setting the GITLAB_AUTH_TOKEN environment variable:
export GITLAB_AUTH_TOKEN=glpat-xxxx
scorecard --repo gitlab.com/<org>/<project>/<subproject>For an example of using Scorecard in GitLab CI/CD, see here.
To use a GitHub Enterprise host github.corp.com, use the GH_HOST environment variable.
# Set the GitHub Enterprise host without https prefix or slash with relevant authentication token
export GH_HOST=github.corp.com
export GITHUB_AUTH_TOKEN=token
scorecard --repo=github.corp.com/org/repo
# OR without github host url
scorecard --repo=org/repoFor projects in the --npm, --pypi, --rubygems, or --nuget ecosystems, you have the
option to run Scorecard using a package manager. Provide the package name to
run the checks on the corresponding GitHub source code.
For example, --npm=angular.
To run only specific check(s), add the --checks argument with a list of check
names.
For example, --checks=CI-Tests,Code-Review.
The currently supported formats are default (text) and json.
These may be specified with the --format flag. For example, --format=json.
The following checks are all run against the target project by default:
| Name | Description | Risk Level | Token Required | GitLab Support | Note |
|---|---|---|---|---|---|
| Binary-Artifacts | Is the project free of checked-in binaries? | High | PAT, GITHUB_TOKEN | Supported | |
| Branch-Protection | Does the project use Branch Protection ? | High | PAT (repo or repo> public_repo), GITHUB_TOKEN |
Supported (see notes) | certain settings are only supported with a maintainer PAT |
| CI-Tests | Does the project run tests in CI, e.g. GitHub Actions, Prow? | Low | PAT, GITHUB_TOKEN | Supported | |
| CII-Best-Practices | Has the project earned an OpenSSF (formerly CII) Best Practices Badge at the passing, silver, or gold level? | Low | PAT, GITHUB_TOKEN | Validating | |
| Code-Review | Does the project practice code review before code is merged? | High | PAT, GITHUB_TOKEN | Validating | |
| Contributors | Does the project have contributors from at least two different organizations? | Low | PAT, GITHUB_TOKEN | Validating | |
| Dangerous-Workflow | Does the project avoid dangerous coding patterns in GitHub Action workflows? | Critical | PAT, GITHUB_TOKEN | Unsupported | |
| Dependency-Update-Tool | Does the project use tools to help update its dependencies? | High | PAT, GITHUB_TOKEN | Unsupported | |
| Fuzzing | Does the project use fuzzing tools, e.g. OSS-Fuzz, QuickCheck or fast-check? | Medium | PAT, GITHUB_TOKEN | Validating | |
| License | Does the project declare a license? | Low | PAT, GITHUB_TOKEN | Validating | |
| Maintained | Is the project at least 90 days old, and maintained? | High | PAT, GITHUB_TOKEN | Validating | |
| Pinned-Dependencies | Does the project declare and pin dependencies? | Medium | PAT, GITHUB_TOKEN | Validating | |
| Packaging | Does the project build and publish official packages from CI/CD, e.g. GitHub Publishing ? | Medium | PAT, GITHUB_TOKEN | Validating | |
| SAST | Does the project use static code analysis tools, e.g. CodeQL, LGTM (deprecated), SonarCloud? | Medium | PAT, GITHUB_TOKEN | Unsupported | |
| Security-Policy | Does the project contain a security policy? | Medium | PAT, GITHUB_TOKEN | Validating | |
| Signed-Releases | Does the project cryptographically sign releases? | High | PAT, GITHUB_TOKEN | Validating | |
| Token-Permissions | Does the project declare GitHub workflow tokens as read only? | High | PAT, GITHUB_TOKEN | Unsupported | |
| Vulnerabilities | Does the project have unfixed vulnerabilities? Uses the OSV service. | High | PAT, GITHUB_TOKEN | Validating | |
| Webhooks | Does the webhook defined in the repository have a token configured to authenticate the origins of requests? | Critical | maintainer PAT (admin: repo_hook or admin> read:repo_hook doc |
EXPERIMENTAL |
To see detailed information about each check, its scoring criteria, and remediation steps, check out the checks documentation page.
Two-factor Authentication (2FA) adds an extra layer of security when logging into websites or apps. 2FA protects your account if your password is compromised by requiring a second form of authentication, such as codes sent via SMS or authentication app, or touching a physical security key.
We strongly recommend that you enable 2FA on GitHub and any important account where it is available. 2FA is not a Scorecard check because GitHub does not make that data about user accounts public. Arguably, this data should always remain private, since accounts without 2FA are so vulnerable to attack.
Though it is not an official check, we urge all project maintainers to enable 2FA to protect their projects from compromise.
Follow the steps described at Configuring two-factor authentication
If possible, use either:
- physical security key (preferred), such as Titan or Yubikey
- recovery codes, stored in an access protected and encrypted vault
As a last option, use SMS. Beware: 2FA using SMS is vulnerable to SIM swap attack.
Each individual check returns a score of 0 to 10, with 10 representing the best possible score. Scorecard also produces an aggregate score, which is a weight-based average of the individual checks weighted by risk.
- “Critical” risk checks are weighted at 10
- “High” risk checks are weighted at 7.5
- “Medium” risk checks are weighted at 5
- “Low” risk checks are weighted at 2.5
See the list of current Scorecard checks for each check's risk level.
If you have what looks like a bug, please use the Github issue tracking system. Before you file an issue, please search existing issues to see if your issue is already covered.
Before contributing, please follow our Code of Conduct.
See the Contributing documentation for guidance on how to contribute to the project.
If you'd like to add a check, please see guidance here.
If you want to get involved in the Scorecard community or have ideas you'd like to chat about, we discuss this project in the OSSF Best Practices Working Group meetings.
| Artifact | Link |
|---|---|
| Scorecard Dev Forum | ossf-scorecard-dev@ |
| Scorecard Announcements Forum | ossf-scorecard-announce@ |
| Community Meeting VC | Link to z o o m meeting |
| Community Meeting Calendar | Biweekly Thursdays, 1:00pm-2:00pm PST Calendar |
| Meeting Notes | Notes |
| Slack Channel | #security_scorecards |
Maintainers are listed in the CODEOWNERS file.
To report a security issue, please follow instructions here.
We meet every other Thursday - 4p ET on this zoom link.
You can see the agenda and meeting notes here.
See the FAQ for answers to Frequently Asked Questions about Scorecard.