Run the Scorecard command line against your own repository and read five checks first: Dependency-Update-Tool, Pinned-Dependencies, Token-Permissions, Vulnerabilities and Security-Policy. Each scores from 0 to 10, and the detailed output explains what to change. Start there, fix the cheapest items, and treat the score as a prompt for questions.
What Scorecard is
OpenSSF Scorecard is an automated tool that assesses open source projects for security practices. It runs a set of checks, each scored from 0 to 10, and combines them into an aggregate weighted by risk. Maintainers can use it to improve their projects, and consumers use it to judge dependencies.
Using it on yourself is the cheap way to see your project the way an outside reviewer would.
Run it
Install via Docker, a release binary, Homebrew or similar. Without a token you hit GitHub rate limits, so set a personal access token in GITHUB_AUTH_TOKEN.
scorecard --repo=github.com/OWNER/REPO --show-details
--checks=Pinned-Dependencies,Token-Permissions runs only named checks, and --format=json changes the output. The project also provides a GitHub Action, a REST API and README badges for ongoing use.
The five checks for dependency hygiene
| Check | What it looks at | A typical fix |
|---|---|---|
| Dependency-Update-Tool | Whether a tool helps keep dependencies updated | Add a Dependabot or Renovate config |
| Pinned-Dependencies | Whether dependencies are declared and pinned | Pin workflow actions to commit SHAs, use lockfiles for builds |
| Token-Permissions | Whether workflow tokens are read-only | Set top level permissions to read and raise per job |
| Vulnerabilities | Whether the project has unfixed known vulnerabilities, via OSV | Merge the fix or document why it does not apply |
| Security-Policy | Whether a security policy file exists | Add SECURITY.md |
Other checks cover code review, branch protection, signed releases and dangerous workflow patterns. They matter, but start with the five above because they map directly to dependency work.
A note on the pinning check
For a library, Pinned-Dependencies can seem to conflict with advice to use ranges. They do not. Library ranges in the manifest are for users. The check is looking at how your build and workflows fetch things, such as unpinned actions and container images. GitHub's own hardening guide recommends pinning actions to a full commit SHA, and says to grant the workflow token only the permissions it needs.
Read the score with care
A score is a conversation starter. Some checks do not fit every project. A new repository may score low on Maintained simply because Scorecard looks for a project that is at least 90 days old. Do not chase 10 on every check. Chase the ones that reduce real risk and write down why you accept the rest.
Equally, a high score does not make you immune. Scorecard measures practices, not the content of your code.
Make it a habit
- Run it once now and save the output.
- Fix the three cheapest items this week.
- Add the GitHub Action so the score updates on its own.
- Re-read the details quarterly.
Quick check
Is a low Scorecard score a vulnerability?
No. It signals missing practices, which raise the chance of problems. Treat it as a to-do list.
Can I run Scorecard on a private repository?
The documentation I reviewed describes GitHub, GitLab and GitHub Enterprise Server, but check the project's page for the access and token setup that applies to you.
Safeguard adds ongoing dependency scanning and policy gates on top of one-off checks like this. Try the free scan.
Sources
- OpenSSF Scorecard: https://github.com/ossf/scorecard
- GitHub docs, security hardening for GitHub Actions: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions
Last reviewed: 19 October 2026.
