Add three data quality metrics beside your remediation numbers: reopen rate, false positive rate and suppression age. They tell you whether the findings are trustworthy and whether fixes really stick. Without them, an SLA dashboard can look healthy while engineers quietly ignore the tool.
Reopen rate
Reopen rate is the share of closed findings that return within a window, say 30 days. A high rate usually has one of three causes: a fix that was incomplete, a dependency that was bumped back by another change, or a scanner that flaps between results.
Track it by cause where you can. "Regression" and "tool noise" need different responses. The first is an engineering process problem. The second is a configuration problem.
False positive rate
This is the share of findings that were triaged as not applicable. Be careful with the definition. A finding might be technically correct but irrelevant, for example in an unused code path, and that is different from a scanner error.
Use two labels:
- Incorrect: the tool reported something that is not true.
- Not applicable: true, but not exploitable in this context.
Both are costly to developers, but the fix differs. Incorrect findings go back to the tool vendor or rules owner. Not applicable findings are an argument for context aware prioritisation such as reachability analysis.
Suppression age and reason
Count active suppressions, their reasons and how long they have been in place. Every suppression should have a reason and an expiry. Ones without are a risk, since they hide findings forever.
A sensible review rule is that suppressions expire and need a fresh decision. Report the number reviewed and renewed each month.
Developer trust signals
Two softer signals help: the share of findings that developers act on without a reminder, and survey comments from a handful of engineers. If the first falls and complaints rise, expect gaming of the formal metrics soon.
How to collect
You need status values that distinguish fixed, not applicable, incorrect, accepted and reopened. If your tracker only has open and closed, the data cannot support these metrics. Add the statuses before you try to chart anything.
What to do with the numbers
- High reopen rate: look at the deployment step. Was the fix actually released?
- High incorrect rate: tune rules or change the tool configuration.
- High not applicable rate: add context to prioritisation, so those items are ranked low from the start.
- Old suppressions: schedule a review.
Related: mean vs median vs p90 and the vanity metrics checklist.
A small example
Imagine 100 findings closed last month and 12 of them returned. A reopen rate of 12 percent sounds high, but when you look, 9 were caused by a base image rebuilt from an old cache that reintroduced a vulnerable package. The fix is a change to the build, not a lecture to developers.
Without the reopen metric and a sample of causes, those 9 items would look like individual failures. With it, one pipeline change removes most of them. This is the practical value of data quality metrics: they find systemic causes behind scattered symptoms.
Quick check
What false positive rate is acceptable?
There is no universal number. Track your own trend and listen to developers. A rising rate is a problem at any level.
Should reopened findings keep their original age?
Yes, link them to the original so the history is visible, or use a documented reset rule.
Last reviewed: 19 October 2026.
