To audit a vulnerability dashboard in an hour, pick three headline numbers, export the rows behind each, recompute them independently, then trace a sample of ten findings back to the scanner and the code. Record every mismatch with a cause. You do not need to fix everything in the hour.
Minutes 0 to 10: choose the numbers
Pick three figures that appear in reports to leaders: for example open critical findings, percent of assets scanned, and time to remediate. These are the ones where an error does the most harm.
Minutes 10 to 25: recompute from rows
- Export the underlying rows for each figure. If you cannot export them, that is finding number one: the number is not traceable.
- Recompute the figure with a spreadsheet or a short script.
- Compare. A match is good. A gap points to a hidden filter, a different unit, a date range or a time zone.
Check these frequent culprits first: default filters such as hiding suppressed items, rows with missing severity, and the date field used for the time window.
Minutes 25 to 45: trace a sample
Pick ten findings at random, mixing severities and teams. For each one, answer:
- Does the component really exist at this version in the repository?
- Does the advisory really apply to that version?
- Is the severity the one the source gives, and which source is it?
- Is the status right: open items actually open, closed items supported by a fix?
- Does the finding have an owner?
Keep a tally of how many of the ten pass every check. Ten is too small for a percentage you would publish, but it is plenty to expose a systematic problem.
Minutes 45 to 55: check the edges
Look at what the dashboard cannot show. List a few repositories you know exist and confirm they appear. Look for assets with no scan date. Check that numbers for different teams add up to the total.
Minutes 55 to 60: write it up
Use a table with four columns: number checked, result, cause of mismatch, owner of fix. Keep wording factual. Date it, so the next audit can compare.
What good looks like
A good outcome is not zero mismatches. It is that every mismatch has a known cause and an owner, and every headline number has a written definition. Repeat the audit after any tool change and on a regular rhythm.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Counts in the platform link to the rows that produced them, which shortens the recompute step. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and follow one finding from detection to resolution, noting which number on screen changes and which stays put.
Click through it at your own pace, or open it full screen.
Quick check
Is ten findings enough to audit?
It is enough to reveal systematic problems, not to publish an accuracy percentage. Increase the sample if you want a figure you will quote.
Who should run the audit?
Someone who does not own the dashboard, so that the checks are independent.
Last reviewed: 19 October 2026.
