Build a waterfall that starts at the raw finding count and ends at the fixed count, with every step labeled and every item in exactly one bucket. Typical buckets are duplicates, not present, not reachable, deferred with an owner, and fixed. If the buckets add up to the total, the gap stops looking like neglect.
Why a gap looks suspicious
An auditor sees a scan with several hundred findings and a remediation report with a few dozen closures. Without an explanation, the natural reading is that most of the findings were ignored. The explanation is usually fine. The trouble is that it lives in people's heads.
The fix is arithmetic. If you can show that the numbers reconcile, the discussion moves from "why so few" to "are your bucket definitions sensible".
The waterfall
Use one row per step and make the totals tie.
| Step | What it means | Evidence to attach |
|---|---|---|
| Raw findings | Everything the scanner reported in one run | Scan export with date |
| Duplicates | Same advisory on the same component reported more than once | Grouping rule |
| Component not present | Finding on something not in the shipped build | Build manifest or SBOM |
| Vulnerable code not reachable | Component present, no call path found | Reachability record |
| Deferred | Reachable or unknown, scheduled with owner and date | Ticket |
| Fixed | Upgrade or patch merged and rescanned | Pull request and rescan |
Every finding lands in one row. Do not let an item sit in two.
Define each bucket in writing
The bucket definitions matter more than the counts. For "not reachable", say what analysis was used and what the label means: no call path found in this build on this date. The OpenVEX specification uses the label vulnerable code not in execute path for this situation, which gives you a standard phrase. It also warns that some justifications, such as an attacker being unable to control the vulnerable code, can be difficult to prove conclusively.
For "unknown", do not fold it into "not reachable". Keep it in deferred until someone has looked. See why reachability analysis says unknown.
Keep the run pinned
Record the scan date, the commit or version scanned, and the tool versions. A waterfall built from one run is checkable. A waterfall that mixes yesterday's scan with last month's fixes is not.
NIST's Secure Software Development Framework describes recording each vulnerability and making a risk based decision about whether it will be remediated or addressed by other means, with approved exceptions recorded. The waterfall is a compact view of exactly that record.
Offer the recompute
Give the auditor the export and let them filter. If they can recreate your counts in a spreadsheet, you have done the hard part. If a bucket relies on judgment, add the reviewer name and date.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a long list shrinks into smaller labeled groups.
Quick check
Should the waterfall include findings I fixed in earlier months?
Show them in a separate trend view. The waterfall should describe one pinned run so it can be recomputed.
What if a bucket count changes after the audit starts?
Say so, note the new date and keep both versions. Do not overwrite the earlier figure.
Safeguard produces reachability results and keeps the linked records, so each bucket can point at its evidence. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
