Using OpenSSF Scorecard in a dependency approval process

Use Scorecard as a triage input in dependency approval, not a pass or fail gate on the aggregate score. Require a few specific checks for high exposure packages, allow documented exceptions, and combine results with vulnerability data and maintainer information. The project itself says its checks are heuristics.

Why not a single cutoff

A rule like "reject anything under 6" is easy to write and easy to regret. The Scorecard documentation says aggregate scores do not show which behaviors a repository has or lacks, and that scores change as heuristics are refined. A cutoff will reject good small projects and accept weak ones that happen to hit the weighted checks.

A tiered approach

Sort requests by how much the package matters.

Tier 1: runs in production, handles untrusted input, or sits deep in the build. Look at the detailed checks for Dangerous-Workflow, Token-Permissions, Branch-Protection, Code-Review, Vulnerabilities and Signed-Releases. Ask for an exception note for any failure.

Tier 2: ordinary libraries. Review the aggregate and the Critical and High checks. Accept with a note if there is a clear reason for failures.

Tier 3: dev tools and test helpers. A quick look is enough, unless the tool runs in CI with access to secrets, in which case treat it as Tier 1.

What to check besides the score

• Known vulnerabilities in the version you want, and whether your code can reach them.
• Who publishes. One person, a team, or a CI workflow with trusted publishing.
• Maintenance signals. Read the Maintained check as a question, not an answer. See what the Maintained check tells you.
• License. Scorecard's License check only confirms a recognised license file exists. It does not replace a legal review.
• Replaceability. How hard is it to swap out if the project goes quiet?

Make exceptions cheap and visible

Exceptions are fine if they are recorded. A short note with the reason, an owner and a review date is enough. Without that, exceptions become permanent and invisible.

Automate the boring part

Run the Scorecard CLI in the review pipeline and attach the JSON output to the request. The documentation lists JSON output and a per-check mode for this. Run Scorecard from the command line shows the commands. Remember that outside scans may miss settings that need a maintainer token.

Safeguard policies and gates can enforce your approval rules when a pull request adds a dependency, and its dependency scanning and reachability analysis cover the vulnerability checks above. You can start with the free scan at gold.safeguard.sh/scan.

Quick check

Sources

• OpenSSF Scorecard repository
• Scorecard checks documentation

Last reviewed: 19 October 2026.