---
title: "Security Dashboard UX Design | Utkarsh Panwar"
description: "Security dashboard UX design from CodeAnt AI: rank findings by severity, give each an owner and a fixed-or-not state, and show coverage before charts."
url: https://www.utkarshdesign.com/guides/security-dashboard-design
author: Utkarsh Dhairya Panwar
updated: 2026-10-08
---

# Security dashboard design for engineering teams

Guide · 6 min read · By [Utkarsh Dhairya Panwar](https://www.utkarshdesign.com/about) · Updated 8 Oct 2026

![CodeAnt attack surface dashboard in a browser: security score 674, Grade D, a risks-by-severity donut, asset counts and a Fix These First list](https://www.utkarshdesign.com/images/codeant-product-attack-surface.webp)

**A security dashboard should answer three questions for every finding: how bad is it, who owns it, and is it fixed yet. I rank findings by severity and exposure, put an owner on each row, track open, in progress or fixed, and merge every scanner into one ranked list.**

## Most security dashboards are built for the demo

Search for security dashboard examples and you get dark screens full of world maps, gauges and threat counters. They look serious in a sales call. Then a real team opens one on a Monday and can't tell which three things to fix this week.

Most writing on this topic is about SOC analysts watching live events. My experience is the other half: application security for engineering teams. At CodeAnt AI I design the security scans, secret-leak detection and the dashboards on top of them, used by 40,000+ developers a week across 800+ companies. Those readers don't watch the dashboard all day. They come in, decide and leave, so for them it works more like a to-do list with evidence attached than a wall display.

## The three columns that matter more than any chart

| Question | What to show | What usually gets shown instead |
| --- | --- | --- |
| How bad is it? | Severity plus exposure: is the vulnerable code reachable, is the leaked key still valid, is the asset public | A raw CVSS number with no context |
| Who owns it? | A team or repo owner on every row, with a way to reassign | Nothing, so everyone assumes someone else has it |
| Is it fixed? | Open, in progress, fixed, or accepted risk, with the date it changed | A count that only ever goes up |

A finding with no owner sits there until an audit. Without a fixed state the dashboard can only grow, and a number that only grows teaches people to stop looking. Every tool already has a severity column, so most of the design work goes into the other two.

## One queue, not one tab per scanner

When I started on CodeAnt's manager views, code analysis results and secret leaks lived in separate places. A manager doing the weekly check had to open both, hold the picture in their head, and then decide. The data was fine; putting it together was the slow part.

The dashboards I designed put both sources into one view, organised around a single question: what needs attention across the org right now. Org-level triage time fell 35%, and the scanners didn't change at all. A leaked API key and an injection flaw in the same repo now appeared side by side, ranked against each other, described with the same severity words.

If your product runs more than one kind of scan, ask a manager to find the single most urgent issue in their org and count the tabs they open. More than one means the dashboard is making them do the merging.

## Show what wasn't scanned

A clean dashboard is only good news if the scanner could see everything. Code security tools get access repo by repo, and a GitHub app installed with "select repositories" will report zero issues on code it was never given.

![GitHub-style Install and Authorize dialog with All repositories and Select repositories options, a read and write permission list and a green Install and Authorize button](https://www.utkarshdesign.com/images/QWzAhleILakb0CawY3pUt5lphEE.webp)

_The scope chosen here decides what the dashboard can ever report on._

- Put coverage near the top: repos scanned out of repos in the org, and when each was last scanned.
- Treat "not scanned" as its own state with its own colour, never as an empty, healthy-looking row.
- Write the empty state honestly: "No secrets found in 12 connected repos. 4 repos aren't connected." beats a green tick.

## Ownership needs a hand-off, not a field

Adding an owner column is easy. Making ownership work is harder, because the person looking at a finding often can't fix it. A manager spots it, a platform engineer owns the repo, and a security lead signs off on accepting the risk.

So the main action on every row should be "send to owner" or "create ticket", pre-filled with the file, the line and the suggested fix. A finding that needs someone to copy details into Jira by hand will wait until that person has a free afternoon. If the owner can't be worked out from the repo, ask once at setup (which team owns which repos) rather than on every finding.

- Pre-fill the ticket with everything needed to act: file, line, severity, why it matters, and the fix.
- Show who it was sent to and when, on the row itself.
- Let "accepted risk" be a deliberate state with a name and a reason attached, so it doesn't look the same as "ignored".

## Do and don't, row by row

| Don't | Do |
| --- | --- |
| "Critical: 47" as the biggest number on the page | "3 critical issues are new this week, 2 in payments-api" |
| A severity donut with no link into the items | Each slice opens the filtered list behind it |
| "Secret detected" | "AWS key committed in config/prod.env, still valid, owned by platform team" |
| Findings sorted by scan date | Findings sorted by severity, then by how long they've been open |
| A trend chart of total findings | A trend of findings fixed versus found, so progress is visible |

The grade on CodeAnt's attack surface view earns its place because a short Fix These First list sits next to it. A score alone only says how things stand. With the three items that would move it alongside, the team has a plan.

## Before you ship it

1. **Write the reader's Monday question**: For a manager it's usually "what's the worst open thing, and is someone on it?" The top of the page answers that and nothing else.
2. **Give every finding three fields**: Severity with context, owner, and state. If the data model can't supply an owner, fix that before the layout.
3. **Merge sources into one ranked list**: Same severity scale across code issues, secrets and dependencies, so they can be compared.
4. **Make coverage visible**: What was scanned, what wasn't, and when.
5. **Close the loop**: Show fixed items leaving the list. People keep using a dashboard when their work visibly changes it.

For the wider question of what managers and individual contributors each need from a dashboard, see my guide to SaaS dashboard design. Alert noise is a separate problem, covered in my guide to alert fatigue.

[CodeAnt AI case study](https://www.utkarshdesign.com/work/codeant-ai): The product behind these examples: AI code review, security scans and the manager dashboards on top.

If you're building a security or developer product and the dashboard is where users stall, that's the work my AI and developer tools design service covers.

## Questions people ask

### Should code issues and secret leaks be on the same dashboard?

For managers, yes, ranked on one severity scale. Developers fixing a single repo can still filter to one type, but the default view shouldn't make anyone merge two lists by hand.

### How do you show severity without everything looking red?

Keep the strongest colour for the top tier only, add exposure to the label (reachable, public, key still valid), and mark what's new since the last visit so old criticals don't bury new ones.

### What's the difference between a security dashboard and a SIEM or SOC console?

A SOC console is built for analysts watching live events all day. The dashboards I design are for engineering teams who check in, fix and leave, so they read like a ranked to-do list rather than a monitor.

### Have you designed a live SOC console?

No. My work is application security for engineering teams at CodeAnt AI: code scans, secret leaks and the manager views on top. Many of the principles carry over, but I'd say so plainly before taking on a SOC project.

## Sources

1. [CVSS v4.0 User Guide](https://www.first.org/cvss/v4.0/user-guide), FIRST
2. [Installing a GitHub App from a third party](https://docs.github.com/en/apps/using-github-apps/installing-a-github-app-from-a-third-party), GitHub Docs
3. [About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners), GitHub Docs

## Working on this?

Tell me what you're building and where it's stuck: [book a 30-minute call](https://cal.com/utkarsh-design/30min), email [work@utkarshdesign.com](mailto:work@utkarshdesign.com) or [send a brief](https://www.utkarshdesign.com/contact).

## Related

- [SaaS dashboard design for managers and contributors](https://www.utkarshdesign.com/guides/saas-dashboard-design)
- [Designing alerts to avoid alert fatigue](https://www.utkarshdesign.com/guides/alert-fatigue)
- [Developer tools UX lessons from CodeAnt](https://www.utkarshdesign.com/guides/designing-for-developer-tools)
- [Cybersecurity product and website design](https://www.utkarshdesign.com/for/cybersecurity)

---

Utkarsh Dhairya Panwar, Founding Product Designer and Design Engineer (IIT Roorkee; Founding Designer at CodeAnt AI, YC W24). Email: work@utkarshdesign.com · Book a call: https://cal.com/utkarsh-design/30min · Hire: https://www.utkarshdesign.com/hire · About: https://www.utkarshdesign.com/llms.txt