An application security dashboard should answer five questions: what software do we have, what is exposed, what is overdue, are we getting better, and what needs a decision. If a tile does not help answer one of them, it is probably decoration and can go.
Start from questions, not data
Most dashboards start from what the scanner exports and end up as a wall of counts. Starting from the questions a reader asks produces a smaller, more useful page.
The five questions
| Question | Candidate tiles | Notes |
|---|---|---|
| What do we have? | Repositories, services and images under inventory, with coverage against the full list | Coverage needs a denominator |
| What is exposed? | Open critical and high findings, known exploited items, reachable findings | Separate known exploited from the rest |
| What is overdue? | Items past SLA, oldest open, by team | List the top few by name |
| Are we improving? | Opened versus closed, age distribution, median and 90th percentile time to fix | Show trend, not a single point |
| What needs a decision? | Exceptions expiring, blocked fixes, unowned assets | Each with an owner and date |
Design rules
- Put the answer in words next to the chart, for example "Overdue criticals: 3, down from 5".
- Give every percentage a count beside it.
- Use the same time window across tiles.
- Mark accepted risks distinctly rather than hiding them.
- Keep to one screen. Detail belongs behind drill downs.
Who is the reader
Different readers need different views from the same data. Engineers want their own backlog. Managers want team trends. Executives want five numbers. Build a small number of views, each tied to a role, rather than one page for everyone.
What to cut
- Total vulnerabilities ever found.
- Severity pie charts with no trend.
- Scan counts that measure activity, not outcome.
- Leaderboards that rank people or teams.
Checking your dashboard
Take a recent decision, such as whether to delay a release or fund a migration. Ask whether the dashboard supplied the facts. If it did not, add the missing view or admit the dashboard is not serving its purpose.
Review cycle
Look at usage every quarter. Remove tiles nobody opened, and ask readers which question they could not answer. A dashboard is a product, and needs the same care.
Try it yourself
Open the demo and map what you see to the five questions. Which questions does it answer, and which would need another view?
Click through it at your own pace, or open it full screen.
Safeguard supports this with SBOM and dependency scanning, reachability analysis and asset discovery, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
How many tiles should a dashboard have?
Few enough to fit one screen, each linked to one of the key questions.
Should one dashboard serve every role?
No. Build a few role based views from the same data.
Last reviewed: 19 October 2026.
