OpenSSF Scorecard Documentation

Scorecard provides coverage analysis against the OSPS Baseline v2026.02.19. This analysis maps Scorecard's probes and checks to specific OpenSSF security controls across three levels of maturity.

Coverage Status Legend

When reviewing coverage, use the following status indicators:

• COVERED: Scorecard has probes that fully satisfy the control.
• PARTIAL: Scorecard has probes that provide evidence but do not fully satisfy the control.
• GAP: No existing probe provides meaningful evidence for this control.
• NOT_OBSERVABLE: The control requires data Scorecard cannot access (e.g., organization-level admin permissions).

The OpenSSF Scorecard project is a community-driven effort to automate security posture analysis for open source projects. Participation is open to anyone who follows the project's Charter and policies. The community is organized into two primary technical roles:

• Contributors: Anyone who contributes code, documentation, or other technical artifacts.
• Committers: Contributors who have earned the ability to modify source code, documentation, or other technical artifacts in the repository. A Contributor can become a Committer through a majority approval of existing Committers.

Scorecard v6 transitions from a scoring tool to an open source security evidence engine. It uses a probe-based architecture to collect, normalize, and package security evidence in interoperable formats.

Key architectural components include:

• Probes: The core mechanism that executes automated analysis (e.g., GitHub API calls, file analysis) to collect evidence.
• Evaluation Layer: A new layer that maps probe findings to specific framework controls (like the OSPS Baseline) to determine status (PASS/FAIL/UNKNOWN/NOT_APPLICABLE).
• Output Formats: Structured evidence is exported in formats such as JSON, SARIF, in-toto, Gemara, and OSCAL Assessment Results.
• Downstream Consumption: Scorecard is designed to provide evidence to tools like AMPEL, Minder, Privateer, Darnit, and Allstar, which then use that evidence for policy enforcement, remediation, or auditing.

Scorecard's conformance model for frameworks like OSPS Baseline relies on probe composition.

• Probes: The fundamental unit of evaluation. They are framework-agnostic and provide raw findings.
• Controls (Baseline): A framework control (e.g., OSPS-XX-XXX) maps to one or more probe compositions.
• Composition: A control can be satisfied by a single probe or a specific set of probes (e.g., OSPS-XX-XXX can be [probe X] or [probe set 1]).

This architecture allows the conformance engine to remain framework-agnostic, supporting arbitrary frameworks or organizational profiles by defining new composition mappings over existing probes.

Scorecard follows a hybrid architectural model for OSPS conformance. This design prioritizes architectural independence while ensuring interoperability with the wider ORBIT ecosystem:

• Self-Contained Evaluation: Scorecard owns all probe execution, mapping logic, and the conformance evaluation engine (PASS/FAIL and applicability logic). It does not depend on external engines like Privateer for its core evaluation.
• Output-Layer Interoperability: Interoperability with other tools (like Privateer) is achieved strictly at the output layer. Scorecard exports results in formats that other tools can consume (Gemara, in-toto, SARIF, OSCAL), but the evaluation logic remains decoupled.

The Scorecard conformance layer is responsible for both evaluation logic and output formatting. It composes probe findings into control verdicts (similar to how checks compose findings into 0-10 scores).

Scorecard supports multiple output formats through this layer, including:

• Enriched JSON
• in-toto
• Gemara
• OSCAL

Note that the conformance layer is designed to be additive. The existing in-toto statement with predicate type scorecard.dev/result/v0.1 (which wraps check-based JSON output) is preserved. A new evidence predicate, scorecard.dev/evidence/v0.1, is also available. Users can choose between these predicates via CLI flags.

Scorecard uses a three-tier architecture to process project signals. It separates raw measurements from high-level assessments, allowing a single run to produce both traditional scores and framework-specific conformance results.

1. Probes: Atomic, boolean measurements (the foundation).
2. Checks: Traditional scoring (0-10) derived from probes.
3. Conformance: Framework-specific evaluation (PASS/FAIL/UNKNOWN) derived from the same probes.

Both Check scores and Conformance labels are parallel interpretations of the same probe evidence and can appear in the same output format.

Scorecard uses a parallel evaluation model. It provides both individual check scores (e.g., Maintained) and conformance results (e.g., OSPS Baseline) in a single run.

Key characteristics:

• Parallel Evaluation: Check scores and conformance labels are separate layers. Existing checks are preserved and are not deprioritized or elevated based on their OSPS coverage.
• Framework Agnostic: The conformance engine is designed to be framework-agnostic. While OSPS is a primary focus, the architecture allows for evaluating against other frameworks or internal variants via mapping definitions. A --framework CLI option is planned for future versions.

Scorecard v3 introduced several key improvements over previous versions:

• Numeric Scoring: Replaced plain Pass/Fail results with numeric scores and risk categories.
• Aggregate Scores: Provides overall scoring for the repository.
• New Repo Interface: A new interface designed to ease integration with various code versioning systems.

When deciding how to strengthen your security posture, consider the following roles for these OpenSSF projects:

• Scorecard: Acts as a "measuring stick" or a home for various analyses. It provides a CLI, GitHub Action, API, monitor, and visualizer. It can run checks locally on private repositories.
• Allstar: Useful for configuring security policies on a per-repository or per-organization basis, though it has limited reporting capabilities compared to Scorecard Monitor.
• Minder: Focuses on remediation and security posture management.

Scorecard is often viewed as a "linter" for software supply chain security, providing structured results that can be ingested by other tools.