Measure reachable and exploited findings, the number of routes still served by legacy code, the spread of versions per risky library, and time to fix by phase. Raw finding totals mislead during a split because duplication can raise the count even when exposure falls.
Why raw totals mislead
When you extract a service, its libraries are counted again in the new repository. Some of the old ones stay in the monolith until cleanup. The total number of findings across all repositories can rise during the project, even though the amount of risk is falling. Reporting that number alone causes needless alarm or hides real progress.
Metrics that work
| Metric | What it shows | How to collect |
|---|---|---|
| Reachable findings in the legacy app | Real exposure, trending down | Reachability analysis on each scan |
| Findings on the exploited list | Urgent exposure, ideally zero | Match components against CISA's Known Exploited Vulnerabilities catalog |
| Routes still served by legacy | Migration progress | The route register at the facade |
| Versions per risky library | Drift and duplication | Cross service inventory |
| Owner coverage | Accountability | Share of manifests with an owner |
| Time to fix by phase | Process health | Ticket data, split by new and legacy |
| Open exceptions and their age | Slipping plans | Exception register |
| Dead code removed | Surface reduction | Commits and dependency counts |
Pick five or six for your report. Too many metrics bury the message.
Set the baseline first
Every metric needs a starting value. Take the scan, route list and owner map before the first extraction, and date them. Fowler describes modernization as decisions about how to break up a problem and how to deliver the parts. Baselines make each delivered part measurable.
A simple report layout
- Headline. Reachable findings now versus baseline.
- Migration. Routes moved this month and routes remaining.
- Risks. Items on the exploited list and exceptions near expiry.
- Next month. The slices planned and the findings they should close.
Keep it to one page. Show trends over several months, not single snapshots.
Beware gaming
Any metric can be gamed. Counting findings invites suppressing them. Counting routes migrated invites moving the easy ones first. Pair metrics so that gaming one shows up in another, for example findings closed alongside findings suppressed, and routes moved alongside risk removed.
Share it with the right audience
Engineering leads want the detail and the owners. Executives want a trend, the largest open risk and what is needed to close it. Compliance teams want evidence that the process runs. For executive reporting ideas see what an AppSec report for executives should contain.
Safeguard's compliance and evidence automation and its vulnerability inventory can supply the data behind several of these metrics.
Quick check
Can the finding count go up and still be progress?
Yes, when duplicated libraries are counted in new repositories before cleanup. Track reachable and exploited findings alongside it.
How often should we report?
Monthly is common, with an immediate flag for any new exploited finding.
Sources
Last reviewed: 19 October 2026.
