A dependency health scorecard for leadership should fit on one page and hold five to seven numbers: days that fixable vulnerabilities stayed open, count of known exploited findings, age of core runtimes against their support dates, majors behind on core frameworks, and share of repositories with a named owner. Add a trend arrow to each. Skip everything else.
What a scorecard is for
Leaders do not need a list of packages. They need to know whether the organization can respond to a new advisory quickly, whether anything is about to lose support, and where to invest. A scorecard answers those three questions without technical detail.
The numbers to include
| Metric | What it answers | Where it comes from |
|---|---|---|
| Known exploited findings open | Are we exposed to attacks seen in the wild? | Inventory matched to CISA's catalog |
| Median days fixable advisories stay open | How fast do we act? | Advisory date versus merge date |
| Runtime age versus support end | Is anything about to lose fixes? | Vendor support pages |
| Majors behind on core frameworks | How big is the next upgrade? | Package manager output |
| Repositories with a named owner | Can anyone act? | Ownership map |
| Update pull requests merged per month | Is the routine running? | Source control |
Choose the ones that fit your context and drop the rest. Six or seven is the ceiling.
Definitions to print on the page
- Known exploited: a vulnerability listed in a catalog of flaws observed to be exploited in the wild. CISA maintains one and recommends using it as an input to prioritization.
- Fixable advisory: a published vulnerability in a version you run where a fixed version exists.
- Major behind: a difference in the first number of the version, which under semantic versioning signals backward incompatible changes.
Design rules
- One page, same layout every month.
- Show trend, not just a snapshot.
- Use time units leaders understand, such as days and months.
- Put the exploited count first, since it is the hardest to argue with.
- Include a plain sentence at the top: "This month, X is better, Y is worse."
Pitfalls
- Vanity totals. A raw count of vulnerabilities mixes noise with signal.
- Goal gaming. If you only target one number, people will bump versions without testing. Pair speed with a quality check such as test pass rate.
- No owner. A metric nobody owns will not move. Put a name beside each.
A short monthly review
Spend fifteen minutes with engineering leads: read the sentence at the top, look at the two worst trends, agree on one action each, and write the action down with a date. That is enough to change behavior.
Where to get the data
Most of it exists already in your package manager, source control and vulnerability tooling. The work is stitching it together on a schedule. An SBOM with versions is a good base, since it gives you the full inventory including transitive packages.
Safeguard's SBOM and dependency scanning lists direct and transitive packages with their versions, and reachability analysis shows which outdated or vulnerable ones your code actually calls. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Notice which summary views would feed a scorecard, such as open items by status and age.
Quick check
How many metrics is too many?
More than seven. If leaders cannot recall the page after reading it, it is too long.
Should the scorecard show individual teams?
Showing teams helps ownership, but frame it as support needs rather than ranking, or people will hide problems.
Sources
- CISA Known Exploited Vulnerabilities Catalog
- Semantic Versioning 2.0.0
- Status of Python versions
- Node.js releases
- OWASP Top 10:2021, A06 Vulnerable and Outdated Components
Last reviewed: 19 October 2026.
