Run it, yes. Scorecard is a free tool that checks repository practices such as branch protection, code review, pinned dependencies and security policy. Use the results to find gaps and fix them. When sharing, show the per check detail and what you changed, not one aggregate score without context.
What Scorecard is
The project describes Scorecard as an automated tool that assesses a number of important heuristics, called checks, associated with software security and assigns each a score from 0 to 10. It was created to help open source maintainers improve their practices and to help consumers judge their dependencies. You can run it as a command line tool or as a GitHub Action, and it outputs an aggregate score plus check scores with reasons and remediation links.
The checks listed in its example output include Binary-Artifacts, Branch-Protection, CI-Tests, Code-Review, Dependency-Update-Tool, Fuzzing, Maintained, Pinned-Dependencies, SAST, Security-Policy, Signed-Releases, Token-Permissions and Vulnerabilities, among others.
What it can and cannot tell you
| Scorecard can show | Scorecard cannot show |
|---|---|
| Whether branch rules and review exist | Whether reviews are careful |
| Whether workflow actions are pinned | Whether your code has bugs |
| Whether a security policy file exists | Whether you respond to reports |
| Whether releases are signed | Whether your product is safe |
Its own documentation describes it as heuristics. A high score means certain good practices are visible to the tool. It is not a safety rating.
Steps
- Install the command line tool or add the GitHub Action to a copy of one repository.
- Run it against your most important repositories first.
- Read the reason column for each low score, not just the number.
- Fix cheap ones: add a security policy file, turn on branch protection, pin workflow dependencies, add a dependency update tool.
- Re-run and keep both outputs with dates.
- Decide which results to share and add context.
Do not game the number
It is possible to raise a score by gestures that do not change risk, such as adding a policy file with no process behind it. A knowledgeable reviewer will notice. Fix the practice, not the metric.
Some checks will not apply
Some checks suit open source projects more than private startup code. Fuzzing may be irrelevant to a small web service. Note which checks you consider out of scope and why, so a low score there is understood.
How to present results
A short table: check, score, what it means for you, action, date. Add a line saying the tool measures practices and is one input among several. Avoid using the aggregate as a headline, since it hides a wide range of situations.
What to do with dependency scores
You can run the same tool against important open source packages you depend on, to see how they are maintained. Treat it as a prompt for questions, not a verdict. Maintainers of small stable libraries may score low on activity and still be fine.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice the kind of rule that would raise your Branch-Protection and Code-Review results in practice: a check that must pass before merge.
Safeguard provides policies and gates for pull requests, SBOM and dependency scanning, and compliance evidence automation. A free scan covers the dependency side that Scorecard does not.
Quick check
What is a good Scorecard score?
There is no pass mark. Look at each check and decide whether the practice fits your situation.
Does Scorecard work on private repositories?
Check the project's documentation for current options. Its public API serves pre calculated scores for public projects.
Sources
Last reviewed: 19 October 2026.
