Quick wins are changes you finish in a day that reduce risk and leave a number behind. Good ones are a committed lockfile, protected main branch, enabled alerts, pinned actions, two factor on key accounts and a pull request check. Measure each with a count or a date, not a made up benchmark.
What makes a metric useful
A useful metric answers a question someone will ask. It comes from data you already have, it moves when you do work, and nobody can game it easily. Avoid industry comparisons you cannot source. Your own trend over three months is a better benchmark than someone else's average.
Six wins and their measures
| Win | Measure | How to read it |
|---|---|---|
| Commit lockfiles | Repositories with a lockfile, out of repositories that ship | Aim for all of them |
| Protect main | Repositories requiring review and checks | Count, then check the admin bypass setting |
| Turn on alerts | Repositories sending alerts to a watched place | Count |
| Pin actions | Workflow files with unpinned third party actions | Should trend to zero |
| Two factor on key accounts | Accounts without it | Should be zero |
| PR dependency check | Pull requests that changed dependencies and were checked | Share of those pull requests |
Add three outcome measures
Counts of settings tell you effort. You also want outcomes.
- Time to decision. For each new alert, how many days until someone chose fix, defer or dismiss? You are not measuring time to fix, only that alerts do not sit.
- Open exploited findings. How many findings on the CISA exploited catalog are open in shipped code? The target is zero, and any number above zero needs an owner.
- Age of the oldest open finding. One number that is easy to explain at a leadership meeting.
CISA recommends all organizations monitor the exploited catalog and prioritize listed vulnerabilities, which is why that count earns a place.
How to collect the numbers cheaply
Most of this is already available. GitHub's documentation describes a dependency graph, alerts and a way to export a software bill of materials. For setting counts, a short script against your code host's settings, or a manual check once a month in a small team, is enough. Record the date next to every number.
Be careful with two measures. First, total alert count rises when you add repositories or when new advisories appear, so it can go up while your practice improves. Second, a falling count after you dismiss alerts in bulk means nothing. Pair counts with a note on what changed.
How to report them
Put the six settings counts and three outcomes on one slide or one page. Add one sentence on what you did last month and one on what is next. Leadership wants a trend and a plan, and a customer wants evidence you review regularly.
Safeguard continuous monitoring and SBOM scanning can feed the counts from a single view across repositories. You can start with a free scan at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Should we report the total number of vulnerabilities?
Report it, but do not lead with it. It moves with advisories and repository count. Lead with open exploited findings and time to decision.
Is there an industry benchmark we should hit?
Avoid unsourced benchmarks. Track your own trend and compare it against your own targets.
Sources
- CISA, Known Exploited Vulnerabilities
- GitHub Docs, Dependency graph
- GitHub Docs, About protected branches
- GitHub Docs, Secure use reference for Actions
Last reviewed: 19 October 2026.
