Score a repo with ten yes or no questions that work in any language: is there a lock, does CI use it, are integrity checks on, who owns updates, is there an SBOM, and so on. Count the yeses, but read the noes first. The score is a conversation starter, not a grade to publish.
The questions
Answer each as yes, no or unknown. Unknown counts as no until someone checks.
- Is there a committed lock mechanism for every manifest?
- Does CI install in locked mode and fail on drift?
- Do integrity checks run, where the tool supports them?
- Is there a record of dependencies that run code at install or build time?
- Does every release produce an SBOM stored with the release?
- Is a named person responsible for updates in this repo?
- Were security updates in the last quarter handled within the target time?
- Are dev and build only dependencies labeled so reports can separate them?
- Is every exception written down with an expiry date?
- Can someone find this repo's owner and dependency list in under five minutes?
Scoring and reading it
| Yeses | Reading |
|---|---|
| 0 to 3 | Start with questions 1 and 2, the cheapest wins |
| 4 to 7 | Good base, fill the specific gaps |
| 8 to 10 | Maintain, and re-check quarterly |
Do not average scores across repos and report a single percentage to leadership. Averages hide the worst repo. Instead, list repos by the number of noes and show the worst five.
What each question tests
Questions 1 to 3 test technical controls. Questions 4 and 8 test awareness. Questions 5 and 10 test whether you could answer an incident or customer question quickly. Questions 6, 7 and 9 test whether people and process exist around the tools.
A repo can pass every technical control and still fail question 10, which is the one you will care about on the day a serious advisory lands.
How to collect answers
Start by hand for a handful of repos. Write the answers in a spreadsheet, one row per repo. Then pick the questions you can automate:
- Lock presence: search for the lock files named in your ecosystems.
- Locked install: check the CI config for the locked command.
- SBOM: check release artifacts.
- Owner: check a service catalog or CODEOWNERS file.
Automate a question only once it is stable. If the definition keeps changing, leave it manual.
Caution about gaming
Any score will be gamed. Teams may add a lock file that CI never reads. Guard against that by sampling: each quarter, pick two repos and verify the answers directly. Reward teams for honest noes.
Try it yourself
Open the demo and watch how continuous monitoring turns a one time check into an ongoing one. Look at how a new finding appears without anyone rerunning a scan.
Click through it at your own pace, or open it full screen.
Safeguard can help here: it scans dependencies and generates SBOMs, applies reachability analysis so you can sort findings by what your code can actually call, and enforces policies and gates on pull requests. You can try a free scan on a repository to see what it finds.
Quick check
Should the scorecard be public?
Share it inside the company. A public score invites gaming and can mislead people who lack context.
What if the answer is unknown?
Count it as no until someone verifies it. Unknown usually means nobody owns the question.
Last reviewed: 19 October 2026.
