Data
Theorem
One legible view of the attacks hitting a customer’s entire ecosystem — and the shortest path from seeing to acting.
The platform continuously discovers, tests, and protects the APIs, mobile apps, web, and cloud services in a company’s stack. This project lived inside the API-protection product: specifically, how to show the attacks hitting a customer’s APIs.
Teams don’t lack data. They drown in it.
A platform watches a customer’s whole ecosystem — mobile, APIs, cloud, web — and every surface streams security signal: attempted exploits, suspicious traffic, schema mismatches. The raw material is all there. What’s missing is a way to stand back and read it.
“What’s hitting us right now, where’s it coming from — and what do I deal with before lunch?”
Readable in seconds. Actionable in one move.
I designed toward five questions a security lead asks on sight. Every chart had to answer one — and encode severity so attention lands in the right place first.
What attacks are most common?
By request volume.
Where do they come from?
Source location.
How severe are they?
Severity encoding.
What's my attack surface?
Affected endpoints.
What are the trends?
Change over time.
Everyone showed a piece. No one showed the shape.
Three benchmarks — each useful, each partial. The opening was a view that reads the whole landscape at a glance.
A feed of attacks
Useful OWASP-type breakdowns — strong on events, weak on shape.
Organized by attacker
Most-attempted endpoints and types — a different lens, not the first question.
A blocked-request log
Precise, but a wall of rows to read line by line — precision without the vantage point.
Three forks that shaped the frame.
Each was a live option, not a strawman. The design is the sum of choosing the right side of all three.
A live feed
Individual attacks — the market’s default.
Aggregate by type & origin
The shape reads in seconds.
Everything on the front page
Every stakeholder’s signal.
Only the five questions
Earn the glanceable layer.
A static overview
A poster to look at.
A working surface
Scan, filter, drill in, act.
Lead with type & origin. Rank by volume. Encode severity.
The ecosystem dashboard answers the five questions at a glance, then gets out of the way. A selected attack opens a detail drawer — reusing the platform’s existing policy-violation pattern, so there’s nothing new to learn — carrying the payload, the path, and the one clear next action.
A chart that’s interesting but ambiguous is worse than none. A critical attack can never read as safe.
Decide what earns the glanceable layer — and what gets demoted.
Promote
Volume, severity, attack surface — the glanceable layer.
Demote
Payloads, request internals — on-demand, in the drawer.
Encode
Severity by color; a critical attack can’t read as safe.
Restrain
A few chart types, used consistently — no novelty for its own sake.
Attacks up front — the glanceable layer.
Anomalies folded in on demand — same drawer, nothing new to learn.
In a data-dense, high-stakes domain, editing is the design.
The hard part isn’t drawing the charts — it’s deciding what earns a place in the glanceable layer, how to encode severity so attention lands correctly, and how to keep the path from “I see a problem” to “I’m doing something about it” short and unbroken. Anyone can add another widget; the value is in what you leave off, and why.
Honest framing: the surviving record documents the plan — validate legibility with real users, refine the encoding, partner with engineering on rollout — not a committed KPI or measured outcome. Every figure shown is placeholder sample data; the screens are MUI recreations, not the production UI.
The visualization is the front door. The value is the handoff.
Lead with type and origin. Encode severity so the important thing is the visible thing. Then get out of the way — scan, drill in, act, without ever leaving the view.