OpenSSF Scorecard

License identification, version specification, dependency tooling, supply chain integrity.


Short name	OpenSSF
Region	International
Country or scope	International
Sector	Open Source
In your workspace	On unless you switch it off in Compliance › Manage.

How Safeguard covers OpenSSF

Scan requirements: 6, all decided by a scan.
Controls: the scan requirements below, plus 14 controls from Safeguard's control catalog for OpenSSF.
Automated tests: none map to it directly. You can link any automated test to its controls yourself (how).
Policy templates: 24: 2 written for OpenSSF and 22 from the standard set.

How each kind of coverage works, and what the readiness score counts: Compliance frameworks.

What a scan checks

Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).

Requirement	What Safeguard checks	Decided by
`OSSF-LICENSE` License Declared	Projects and their consumed components should have a published, identifiable license, mirrored here as license information recorded per component (OpenSSF Scorecard 'License' check)	Scan
`OSSF-PINNED` Pinned Dependencies	Dependencies should be pinned to exact versions rather than floating ranges or 'latest' tags to prevent silent substitution (OpenSSF Scorecard 'Pinned-Dependencies' check)	Scan
`OSSF-PIN-VER` Versions Declared	Pinning presupposes that every dependency has a declared version in the first place (OpenSSF Scorecard 'Pinned-Dependencies' check)	Scan
`OSSF-VULN` Known Vulnerability Matching	Projects are scored on unfixed known vulnerabilities via OSV lookup, which requires components to carry standard identifiers (PURL/CPE) to be matched at all (OpenSSF Scorecard 'Vulnerabilities' check)	Scan
`OSSF-SIGNED` Release Integrity Material	Signed releases and provenance let consumers verify artifacts; at SBOM level this requires integrity hashes recorded for components (OpenSSF Scorecard 'Signed-Releases' check)	Scan
`OSSF-DEPTOOL` Dependency Awareness	Using dependency-update tooling presupposes a documented dependency graph so transitive relationships are known (OpenSSF Scorecard 'Dependency-Update-Tool' check)	Scan

More controls in the catalog

The framework's Controls tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.

Control	Name
`SC-Binary-Artifacts`	Eliminate Binary Artifacts from Source Repository
`SC-Branch-Protection`	Enable Branch Protection on Default and Release Branches
`SC-CI-Tests`	Run Automated Tests on Every Pull Request
`SC-Code-Review`	Require Code Review for All Changes
`SC-Dangerous-Workflow`	Prohibit Dangerous CI/CD Workflow Patterns
`SC-Dependency-Update-Tool`	Automate Dependency Updates
`SC-Fuzzing`	Integrate Fuzz Testing into the Build Pipeline
`SC-License`	Include a Machine-Readable License in the Repository
`SC-Pinned-Dependencies`	Pin All CI/CD Action and Dependency Versions to Hashes
`SC-SAST`	Run Static Analysis Security Testing in CI
`SC-Security-Policy`	Publish a SECURITY.md with Vulnerability Reporting Instructions
`SC-Signed-Releases`	Cryptographically Sign All Release Artifacts
`SC-Token-Permissions`	Minimize GitHub Token Permissions in Workflows
`SC-Vulnerabilities`	Remediate Open Vulnerabilities in a Timely Manner

Policy templates

Written for OpenSSF:

Repository Security Baseline Policy (OpenSSF Scorecard)
Secure Dependency Management Policy (OpenSSF)

And 22 from the standard set, adapted to OpenSSF.