Interpret OpenSSF Scorecard Results
Read individual OpenSSF Scorecard checks in context and turn weak results into targeted supply-chain review tasks.
OpenSSF Scorecard reports checks on a project's public repository practices. A single aggregate number is not a security certificate, and a low check result may reflect missing public evidence rather than a confirmed vulnerability. Read the check definition and raw evidence for the specific repository and date before acting. Match the repository to the package you actually consume.
Result interpretation sheet
| Check area | What to inspect | Possible action |
|---|---|---|
| Pinned dependencies | Workflow references and package resolution | Pin or review release inputs |
| Token permissions | Workflow-level and job-level grants | Reduce unused grants |
| Branch protection | Review and merge settings | Add protected review path |
| Vulnerability handling | Security policy and advisories | Confirm report route |
| Signed releases | Published artifact evidence | Verify identity and digest |
The Scorecard checks documentation explains what each check tests and its limits. Keep the raw result, check version, repository URL, and scan date. A result from a fork or old default branch may not describe the release artifact. A check can also be inapplicable to a project, so record why before treating it as a failure.
Prioritize a concrete response
Choose actions based on the dependency's role. For a privileged production package, weak release controls may justify artifact verification or a replacement review. For a build-only tool, prioritize CI permissions and isolated execution. Do not ask a maintainer to change a project solely to improve your dashboard score. First confirm the evidence and the risk in your own use.
Worked interpretation: synthetic result
Suppose Token-Permissions flags a GitHub workflow with top-level permissions: write-all. Open that workflow at the scanned revision. If the file grants broad default authority, record the affected jobs and ask the maintainer or internal owner for a narrower release path. A job-level publish grant may still be justified; the aggregate score alone does not decide that. If the workflow changed after the scan, mark the result stale and inspect the current revision. Keep the installed package version separate from the repository score.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.