I Built a Dashboard to Make Security Reports Easier to Read

When working with security tools like Trivy and npm audit, I realized that their primary goal is to generate detailed reports that can be consumed by automation, CI/CD pipelines, and other security tools.

For developers, however, there are times when you simply want a quick visual overview of a report. Questions like:

• How many critical vulnerabilities are there?
• Which packages need immediate attention?
• Which vulnerabilities already have a fix available?
• What should I investigate first?

can require navigating through a large JSON report or terminal output.

Of course, Trivy already provides excellent terminal output, and there are powerful enterprise platforms that provide comprehensive security dashboards. I wasn't trying to recreate those tools or copy their ideas. Instead, I wanted to explore a different question: What if viewing a security report was as simple as opening a web page?

The Idea

My goal was to build a lightweight, browser-only application where developers can simply:

• Drag & Drop a JSON report
• Paste a JSON report
• Click Analyze Report

That's it. No installation. No backend. No account. No database. Within seconds, the report is transformed into an interactive dashboard.

The focus isn't on replacing existing security platforms-it's on providing a simple, fast, and privacy-friendly way to explore security reports.

Why Browser-Only?

Security reports often contain sensitive information about a project. Uploading those reports to a remote server just to visualize them isn't always desirable. That's why I decided that every report should be processed locally inside the browser.

Nothing is uploaded. Nothing is stored. Your security report never leaves your machine.

Supporting Multiple Scanners

One thing I learned very quickly is that different security scanners don't speak the same language. For example, Trivy and npm audit both report vulnerabilities, but their JSON structures are completely different. The UI shouldn't need to know which scanner generated the report.

Instead of building separate interfaces for every scanner, I introduced a normalization layer. Each supported report is converted into a common data model before it reaches the UI. Once normalized, the dashboard can display vulnerabilities using the same components regardless of the original scanner.

Besides simplifying the frontend, this also makes supporting additional scanners much easier in the future.

What I Learned

This project taught me much more than building a React interface. Some of the biggest lessons were:

• Good dashboards are about information hierarchy, not displaying every field available.
• A normalization layer makes supporting multiple data sources significantly easier.
• Security tools and frontend applications solve different problems. Sometimes the challenge isn't generating data-it's presenting that data in a way that's easy to explore.
• Processing reports entirely in the browser improves both privacy and user trust.
• A simple workflow often creates a better user experience than a feature-heavy interface.