Track how long unexplained changes stay unexplained, how many services have no current baseline, how many deployed versions lack a stored SBOM, and how often alerts lead to action. Skip raw component totals, which rise with project size and tell you little about risk.
Judge a metric by the decision it drives
A useful metric changes what someone does next. If a number rising or falling would not alter any plan, it is decoration. The aim here is not a dashboard. It is a handful of measures that show whether your drift process is working.
Measures that earn their place
| Metric | What it shows | Action it drives |
|---|---|---|
| Time from change detected to explained | Whether owners respond | Fix routing and ownership |
| Count of unexplained changes older than your agreed window | Backlog of unknowns | Escalate to owners |
| Share of deployed versions with a stored SBOM | Record completeness | Close gaps in the pipeline |
| Services with a stale baseline | Comparisons that mislead | Refresh baselines |
| Alerts acted on versus ignored | Alert quality | Tune rules |
| Gate blocks later overturned | Rule accuracy | Fix over strict rules |
You will need your own history to set targets. Do not copy a number from elsewhere. Begin by measuring for a month, then choose thresholds that make sense for your teams.
Measures to be careful with
- Total component count. It grows with the project and says nothing about risk on its own.
- Number of diffs produced. A busy pipeline produces many, which is not a success.
- Vulnerabilities found. Depends on what you scan and how, and can rise when coverage improves, which is good news that looks bad.
- Percent of builds with an SBOM, if it counts builds nobody deploys.
If you do report these, put context beside them. A rising finding count after expanding scan coverage should be labelled as such.
Collecting the data
Most of this comes from the pipeline and the ticket system. Stamp each SBOM with the service, version and generation time. Stamp each alert with the time raised and the time explained. Then the first two metrics are a query, not a project.
Reviewing them
Look at the table monthly with the owners present. Ask what changed, what stuck, and what the process cost the teams in effort. If a measure never prompts a conversation, retire it.
Beware of gaming. If the target is explained quickly, people may write thin explanations. Spot check a sample for quality.
Where tools fit
A platform can collect these automatically if it stores SBOMs per version and tracks alert handling. Check whether it can export the raw data, so you are not locked into its charts.
Safeguard stores SBOMs, monitors continuously and applies policies, and its compliance and evidence automation can help retain the records. The free scan shows what a project inventory looks like.
Quick check
Is the total number of components a good metric?
Not on its own. It grows with project size and does not measure risk.
How do I choose targets?
Measure for a month, then set thresholds from your own history rather than a number from another team.
Last reviewed: 19 October 2026.
