OpenSSF Scorecard

What Is the OpenSSF Scorecard?

The OpenSSF Scorecard is an automated tool that evaluates open-source projects against a set of security best practices and assigns a score from 0 to 10. It was created by the Open Source Security Foundation (OpenSSF) to help developers and organizations assess the security posture of the open-source dependencies they consume.

The OpenSSF security scorecard addresses a practical problem: most organizations depend on hundreds or thousands of open-source packages, but have no systematic way to evaluate which ones follow basic security hygiene. A project with no branch protection, no signed releases, and no CI tests is a higher supply chain risk than one that enforces all three. The 

Scorecard makes that distinction measurable and automatable, complementing software composition analysis tools that focus on known vulnerabilities rather than project-level security practices.

How OpenSSF Scorecard Checks Work

The OpenSSF Scorecard tool runs a series of automated checks against a project’s public repository and produces a per-check score along with an aggregate score. Each check evaluates a specific security practice and returns a result between 0 (not implemented) and 10 (fully implemented).

Checks are executed by analyzing publicly available data: repository metadata, CI/CD configuration files, branch protection settings, commit history, dependency update patterns, and release artifacts. The tool does not require access to the project’s private infrastructure or source code beyond what is publicly hosted.

Scores are available through the Scorecard CLI, the Scorecard GitHub Action (which can run checks on every pull request), and the Scorecard API/BigQuery dataset, which provides precomputed scores for over a million open-source projects. Organizations can query this dataset to evaluate their full dependency tree without running checks individually.

The scoring model weights checks differently based on their security impact. Checks related to code review, branch protection, and dependency updates carry more weight than checks related to packaging or license metadata.

Key Security Checks in the OpenSSF Scorecard

The Scorecard evaluates projects across multiple dimensions. The most security-relevant checks include:

• Branch protection: Whether the default branch requires code review, status checks, and prevents force pushes. This is one of the highest-weighted checks because unprotected branches allow unauthorized code to enter the project.
• Code review: Whether changes are reviewed by someone other than the author before merging. Projects without code review have a higher risk of introducing vulnerable or malicious code.
• Dependency update tool: Whether the project uses automated tools (like Dependabot or Renovate) to keep dependencies current. Outdated dependencies are a primary supply chain risk vector.
• Signed releases: Whether the project signs its release artifacts, enabling consumers to verify integrity. Unsigned releases are vulnerable to substitution and tampering.
• CI tests: Whether the project runs automated tests in CI. Projects without CI tests have less assurance that changes do not introduce regressions or vulnerabilities.
• Vulnerabilities: Whether the project has known, unpatched vulnerabilities in its dependencies.
• Token permissions: Whether CI/CD workflows use least-privilege token permissions, reducing the blast radius of a compromised workflow.

These checks collectively assess whether a project follows the dependency management and development practices that reduce software supply chain security risk.

How to Use OpenSSF Scorecard to Evaluate Open Source Dependencies

Organizations can integrate the Scorecard into their dependency evaluation process at multiple stages.

During dependency selection, teams can query the Scorecard API before adding a new dependency. A low score does not automatically disqualify a package, but it flags projects that may require additional review or compensating controls.

During CI/CD, the Scorecard GitHub Action can run checks on the organization’s own repositories to ensure internal projects meet the same security bar expected of external dependencies. This is especially useful for organizations publishing open-source projects.

For portfolio-level assessment, the BigQuery dataset enables teams to score their entire dependency tree in bulk. This produces a risk-ranked view of which dependencies pose the greatest supply chain risk based on project-level security practices rather than known CVEs alone.

The Scorecard works best as one input into a broader evaluation framework. Combine it with SBOM data, vulnerability intelligence, and maintainer activity metrics to build a complete picture of dependency risk.

Limitations of the OpenSSF Scorecard

The open source security scorecard is a useful signal, but it has real limitations that teams should understand. These include:

• Public data only: The Scorecard can only evaluate what is publicly visible. Private security practices (internal security reviews, private vulnerability disclosure processes, threat modeling) are invisible to the tool.
• Practice, not outcomes: A high score means the project follows good practices. It does not guarantee the code is free of vulnerabilities. A well-maintained project with branch protection and CI tests can still contain critical bugs.
• Gaming potential: Some checks can be satisfied superficially. A project can enable branch protection without meaningful code review, or add a CI pipeline that runs trivial tests.
• Snapshot in time: Scores reflect the project’s current state. A project’s security practices can degrade after an initial assessment, especially if key maintainers leave.
• Weighting assumptions: The scoring model’s weights reflect the OpenSSF’s priorities, which may not align with every organization’s risk model.

The Scorecard is most valuable as a screening tool and a trend indicator, not as a definitive security assessment.

FAQs

Is a high OpenSSF Scorecard score a guarantee that a package is secure?

No. A high score indicates good security practices but does not guarantee the absence of vulnerabilities or malicious intent. It is one signal among several.

How often are OpenSSF Scorecard scores updated?

Precomputed scores in the BigQuery dataset are updated weekly. Running the Scorecard CLI or GitHub Action produces a real-time score based on current repository state.

Which OpenSSF Scorecard checks have the most impact on overall security posture?

Branch protection, code review, signed releases, and dependency update tooling are the highest-impact checks. They address the most common supply chain attack vectors.

How can maintainers improve their OpenSSF Scorecard score?

Enable branch protection, require code reviews, add a dependency update tool, sign releases, and configure CI workflows with least-privilege token permissions.

How does the OpenSSF Scorecard relate to SLSA compliance?

The Scorecard evaluates project-level practices. SLSA focuses specifically on build integrity and provenance. A project can score well on the Scorecard and still lack SLSA-compliant provenance.