Track six things: how much of what ships is in the register, how many SDKs you carry, how far behind latest they are, how fast you respond to advisories, how many exceptions are open and how many reviews happened on time. Report them quarterly, with trends rather than single numbers.
The six metrics
| Metric | How to compute | What it tells you |
|---|---|---|
| Register coverage | SDKs found in builds that are also in the register, divided by SDKs found in builds | Whether the process sees reality |
| SDK count per app | Direct SDKs in each shipping app | Size of the attack surface and review load |
| Age behind latest | Releases or months between pinned and latest version | Upgrade discipline |
| Advisory response time | Time from advisory affecting a shipped SDK to a decision | Readiness |
| Open exceptions | Count and oldest age | Whether the policy is livable |
| Reviews on time | Reviews done by due date divided by reviews due | Whether the calendar holds |
Write the formula next to each metric. A number nobody can recompute gets argued about.
Why these and not others
Coverage comes first because everything else depends on it. If the register covers half of what ships, the other numbers describe half the picture. The data comes from comparing builds with the register, which the register post and CI allowlist support.
Age behind latest matters because Android's documentation warns that outdated dependencies could eventually prevent publishing to the Play Console. A rising age is an early sign of that kind of risk. Measure in releases or months, not just version numbers, because numbering schemes differ.
Advisory response time measures a decision, not a patch. The aim is to know quickly whether you are affected and what you will do. Patching speed depends on release trains, and shipping a mobile fix is its own topic.
Metrics to avoid
- Raw count of vulnerabilities found. It rewards noisy scanners and says little about risk.
- Number of SDKs approved. Approving more is not a goal.
- Training completion as a stand in for governance.
If you use vulnerability counts at all, pair them with reachability: how many of the findings affect code your app actually calls.
Setting targets
Do not set targets before you have two quarters of data. Then choose directional goals: coverage near complete, exceptions with expiry always, reviews on time for the high tier. Targets for age or response time should come from your release rhythm, not from another company's numbers.
Reporting
One page: the six numbers, three quarters of trend, the three oldest exceptions, and one decision you need from leadership. Put the owner's name at the top. If a number worsened, say why in a sentence.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are prioritised and tracked to closure. That tracking is the raw material for response time metrics.
Safeguard's dependency scanning, reachability analysis and compliance evidence automation can supply data for several of these measures. A free scan is at gold.safeguard.sh/scan.
Quick check
What is the single most useful metric?
Register coverage. If the register misses part of what ships, other numbers mislead.
Should we count vulnerabilities?
Only with context such as reachability and severity. A raw count mostly measures scanner noise.
Sources
Last reviewed: 19 October 2026.
