A clearer path from finding to fix
Oxeye is a security platform for cloud applications. It shows how vulnerabilities in code connect to running services and whether an attacker could reach them.
As Oxeye’s product designer, I led the design of the compliance heatmap, attack-map sidebar, and scan workflow. I built the shared design system and reviewed the implementation with engineers.
Security teams could see which apps needed attention, investigate an attack path without leaving the issues list, and follow a scan while they worked. Reusable components and documented interaction states gave engineers a consistent way to build those flows.
Product design · Interaction design · Design system 
Acquired by GitLab ↗
What is Oxeye?
Oxeye helps security and engineering teams work out which software vulnerabilities need attention first. It shows how an issue in code connects to the running application and whether an attacker could reach it.
See how the layers connect
- Connect isolated findings into one route from weakness to impact.
- Rank by exploitability and business exposure, not by raw count.
- Turn findings into tasks engineering teams can act on.
From issue to investigation
I designed how users move from the issues list into an investigation, check the risk, and decide what to do next. I built shared components so the same patterns worked across the dashboard, packages, and attack paths.
Compliance at a glance
Users had to filter and open several screens to understand where compliance issues were concentrated. I designed one overview so they could spot the areas needing attention before opening the details.
Why a heatmap?
A heatmap fit the question: which apps have issues, and against which standards? Rows and columns make that comparison easy. Color shows severity, counts show how many issues there are, and hover reveals the requirements behind them.
Users could start with the full picture and choose where to investigate, rather than build that picture through filters.
Explore the design studies and supporting screens
Complexity
GDPR, HIPAA and PCI DSS all tracked at once.
Visibility
No at-a-glance status across frameworks.
Prioritization
Critical issues buried in healthy data.
Usability
Competitor tools were dense and hard to learn.
Start with the application.
The tools I reviewed started with a standard. Developers often needed to start with their application. I connected the two so they could see which code issues affected which requirements.
Payment app · detected
SQL injection · CriticalXSS · MediumWeak cipher · LowCompliance impact
PCI DSS 6.5.1GDPR Art. 32SOC 2 CC6.1Three ways to show the same information.
Show the attack path first
I designed the attack-map sidebar from the first information map through implementation review. I worked out what users needed immediately and what could appear on hover or click. The attack path came first; the supporting details stayed close by.
Icons show the services, lines show how they connect, and color points to the affected service. Hovering a node reveals its security factors. Users can inspect the path without leaving the issues list.
Interaction decisions
- Open on Flow
The attack path comes first. Details, code, and stack trace remain one tab away.
- Keep severity and status visible
The CVE name, severity, and status stay in the header while users inspect the map.
- Focus the affected service
The affected service stays in full color while other services are muted.
- Filter internet exposure in place
The Internet connection toggle narrows the same map without leaving it.
- Carry identity into the detail view
The CVE name and severity repeat in the header so the issue stays identifiable.
- Distinguish the connection types
Solid lines mark confirmed routes. Dotted branches show possible connections.
- Reveal why a node is exploitable
The hover popover names the security factors beside the node: shared network, host namespace, and privileged container.
Keep scan progress clear
I designed the dynamic application security testing (DAST) flow from starting a scan to opening its findings. I mapped the loading, running, and result states and reviewed them with engineering during implementation.
The scan action changes to a running state in the same place. The radar icon animates to show activity, and the finding count links to the results. I used motion to make those changes noticeable while users continued working.
Scan interaction decisions
- Reveal actions on hover
The row menu appears on hover, keeping the applications list easy to scan.
- Put Run DAST first
The scan action leads the menu. Its radar icon returns in the running state.
- Raise priority in place
Mark as critical lets users flag an application from the list.
Watch the recording
- Show observer connection
Users can check the connection beside the scan status.
- Replace the action with status
The radar animates beside “Running” in the same place the scan started.
- Link to live findings
The count updates as findings arrive and opens the filtered issues list.
Watch the recording
A system engineering can build
I documented the screens, interactions, loading states, and edge cases, then reviewed the implementation with engineering. The handoff pointed to shared components so the team had one reference for how they should behave.
Across all three features, I kept asking the same questions: what does the user need now, what can wait until they interact, and what should they do next?
View handoff boards and component specifications
One design system behind every handoff
I organized colors, type, spacing, and components in one library. Handoffs reused those components and their states, with extra notes for new behavior or exceptions.
View the product UI system
Public product context
In Oxeye’s published customer story, Inspectiv’s CISO described spending less time assessing issues manually. That feedback is about the wider platform, not a result measured for these individual features.
Read Oxeye’s Inspectiv customer story ↗GitLab’s acquisition announcement describes the value of Oxeye’s runtime context and code-to-cloud tracing.
Read GitLab’s product announcement ↗Across the compliance heatmap, attack paths, and scan status, I designed each view to answer a different question: where should I look, how did this happen, and what’s happening now? I documented the interaction states and reusable components so engineering could carry those decisions into the product.