scorecard

OpenSSF Scorecard - Security health metrics for Open Source

4,378

481

4,378

355

View on GitHub

Top Related Projects

osv-scanner

6,107

Vulnerability scanner written in Go which uses the data provided by https://osv.dev

grype

8,441

A vulnerability scanner for container images and filesystems

trivy

22,801

Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more

Quick Overview

Scorecard is an automated security tool that assesses open-source projects for security risks. It checks various security best practices and generates a score, helping developers and users understand the security posture of a project. Scorecard is part of the Open Source Security Foundation's efforts to improve the security of the open-source ecosystem.

Pros

Automated security checks for open-source projects
Provides actionable insights to improve project security
Integrates with CI/CD pipelines for continuous security assessment
Supports multiple version control platforms (GitHub, GitLab, Bitbucket)

Cons

May produce false positives or miss complex security issues
Requires ongoing maintenance to keep up with evolving security best practices
Some checks may not be applicable to all types of projects
Can be resource-intensive for large repositories or organizations

Getting Started

To use Scorecard, follow these steps:

Install Scorecard:

go install github.com/ossf/scorecard/v4@latest

Run Scorecard on a repository:

scorecard --repo=github.com/ossf/scorecard

View the results in the console output or generate a JSON report:

scorecard --repo=github.com/ossf/scorecard --format=json > results.json

For more advanced usage and integration with CI/CD pipelines, refer to the official documentation at https://github.com/ossf/scorecard.

Competitor Comparisons

osv-scanner

6,107

Vulnerability scanner written in Go which uses the data provided by https://osv.dev

Pros of OSV-Scanner

Focuses specifically on known vulnerabilities in dependencies
Provides detailed vulnerability information and affected versions
Supports scanning multiple package ecosystems (npm, PyPI, Go, etc.)

Cons of OSV-Scanner

Limited to vulnerability scanning, doesn't assess overall project security
Requires a local code or dependency list to scan effectively
May produce false positives if version constraints are not well-defined

Code Comparison

OSV-Scanner:

func ScanArtifacts(ctx context.Context, artifacts []string, options *ScannerOptions) ([]ScanResult, error) {
    // Scan artifacts for vulnerabilities
}

Scorecard:

func RunScorecard(ctx context.Context, repo string, commitSHA string) (*checker.ScorecardResult, error) {
    // Run various security checks and generate a scorecard
}

The code snippets highlight the different focus areas:

OSV-Scanner scans artifacts for known vulnerabilities
Scorecard runs a comprehensive set of security checks on a repository

Both tools contribute to improving open-source security, but they serve different purposes. OSV-Scanner is more focused on identifying known vulnerabilities in dependencies, while Scorecard provides a broader assessment of a project's security practices and infrastructure.

grype

8,441

A vulnerability scanner for container images and filesystems

Pros of Grype

Focuses specifically on vulnerability scanning for container images and filesystems
Provides detailed vulnerability reports with severity levels and fix recommendations
Supports multiple operating systems and package formats

Cons of Grype

Limited to vulnerability scanning, doesn't cover broader security aspects
Requires more setup and configuration compared to Scorecard's automated checks
May have higher resource usage for large-scale scans

Code Comparison

Grype (vulnerability scanning):

match, err := matcher.Match(pkg, vulnerability)
if err != nil {
    return nil, fmt.Errorf("failed to match package: %w", err)
}

Scorecard (security checks):

func RunCheck(checkName string, c *checker.CheckRequest) checker.CheckResult {
    switch checkName {
    case CheckBinaryArtifacts:
        return binaryArtifacts(c)
    // ... other checks
    }
}

The code snippets highlight the different focus areas of the two projects. Grype's code relates to matching vulnerabilities with packages, while Scorecard's code shows its modular approach to running various security checks.

trivy

22,801

Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more

Pros of Trivy

Comprehensive vulnerability scanning for containers, filesystems, and Git repositories
Supports multiple operating systems and package managers
Faster scanning speed and lower resource usage

Cons of Trivy

Focused primarily on vulnerability scanning, less emphasis on overall security posture
May require more manual interpretation of results compared to Scorecard's automated scoring

Code Comparison

Trivy example:

trivy image python:3.4-alpine

Scorecard example:

scorecard --repo=github.com/ossf/scorecard --checks=Maintained,CII-Best-Practices

Summary

Trivy excels in comprehensive vulnerability scanning across various environments, while Scorecard focuses on evaluating overall security practices and providing an automated scoring system. Trivy offers broader scanning capabilities and faster performance, but Scorecard provides a more holistic view of a project's security posture. The choice between the two depends on specific security assessment needs and the desired level of automation in interpreting results.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

OpenSSF Scorecard

Using Scorecard

Scorecard GitHub Action
Scorecard REST API
Scorecard Badges
Scorecard Command Line Interface

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

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

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.

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.

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 gcr.io/openssf/scorecard:stable

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

docker pull gcr.io/openssf/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:

Install the verification tool from slsa-framework/slsa-verifier#installation.
Download the signature file attestation.intoto.jsonl from 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>

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.

Create a classic GitHub personal access token. 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>,<your access token2>

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 (set or export) 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.

Basic Usage

Using repository URL

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        |
|---------|------------------------|--------------------------------|---------------------------------------------------------------------------|

Docker

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/scorecard

To 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/scorecard

Showing Detailed Results

For 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: 'administrator'   |                                                                           |
|         |                        |                                | PRs need reviews before being  |                                                                           |
|         |                        |                                | merged on branch 'main'        |                                                                           |
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|

Showing Maintainers Annotations

Maintainer Annotations let maintainers add context to display alongside Scorecard check results. Annotations can provide users additional information when Scorecard has an incomplete assessment of a project's security practices. To see the maintainers annotations for each check, use the --show-annotations option.

For more information on available annotations or how to make annotations, see the configuration doc.

Using a GitLab Repository

To run Scorecard on a GitLab repository, you must create a GitLab Access Token with the following permissions:

read_api
read_user
read_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.

Self Hosted Editions

While we focus on GitLab.com support, Scorecard also works with self-hosted GitLab installations. If your platform is hosted at a subdomain (e.g. gitlab.foo.com), Scorecard should work out of the box. If your platform is hosted at some slug (e.g. foo.com/bar/), you will need to set the GL_HOST environment variable.

export GITLAB_AUTH_TOKEN=glpat-xxxx
export GL_HOST=foo.com/bar
scorecard --repo foo.com/bar/<org>/<project>

Using GitHub Enterprise Server (GHES) based Repository

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/repo

Using a Package manager

For 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.

Running specific checks

To run only specific check(s), add the --checks argument with a list of check names.

For example, --checks=CI-Tests,Code-Review.

Formatting Results

The currently supported formats are default (text) and json.

These may be specified with the --format flag. For example, --format=json.

Checks

Scorecard Checks

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

Detailed Checks Documentation

To see detailed information about each check, its scoring criteria, and remediation steps, check out the checks documentation page.

Beginner's Guide to Scorecard Checks

For a guide to the checks you should use when getting started, see the beginner's guide to scorecard checks.

Other Important Recommendations

Two-factor Authentication (2FA)

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 any important accounts where it is available. 2FA is not a Scorecard check because GitHub and GitLab do 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.

Enabling 2FA

For users

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.

For an organization

Scoring

Aggregate Score

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.

Contribute

Report Problems

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.

Contribute to Scorecard

Before contributing, please follow our Code of Conduct.

See the Contributing documentation for guidance on how to contribute to the project.

Adding a Scorecard Check

If you'd like to add a check, please see guidance here.

Connect with the Scorecard Community

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	*APAC-friendly* Biweekly on Thursdays at 1:00-2:00 PM Pacific (OSSF Public Calendar) Video Call: LFX Zoom *EMEA-friendly* Every 4 Mondays at 7:00-8:00 AM Pacific (OSSF Public Calendar) Video Call: LFX Zoom
Meeting Notes	Notes
Slack Channel	#scorecard

Maintainers are listed in the CODEOWNERS file.

Report a Security Issue

To report a security issue, please follow instructions here.

Join the Scorecard Project Meeting

Zoom

APAC-friendly Biweekly on Thursdays at 1:00-2:00 PM Pacific (OSSF Public Calendar)

Video Call: LFX z o o m

EMEA-friendly Every 4 Mondays at 7:00-8:00 AM Pacific (OSSF Public Calendar)

Video Call: LFX z o o m

Agenda

You can see the agenda and meeting notes here.

Stargazers over time

FAQ

See the FAQ for answers to Frequently Asked Questions about Scorecard.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot