A vulnerability scan dashboard is the web interface where you launch a scan, watch it run, and review what it found without touching a command line. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and its web dashboard covers that entire loop across 17 pages, from the scan list down to an interactive graph of how findings connect.
What can you actually do from the dashboard?
The dashboard opens on a landing page with stats, recent scans and a severity breakdown, so the first thing you see on any given day is how many scans ran and how bad the worst findings are, not a blank screen you have to query. From there, /scans lists every scan with severity counts and duration, and clicking into /scans/[id] gets you the findings, the assets discovered, a link into the graph view, filters, and export.
That last part matters more than it sounds. A hunter running five or six targets in parallel does not want to tail log files to know when a scan finishes. Progress updates come through over a live WebSocket connection, so the scan list and the individual scan page update in real time as new findings land, instead of requiring a manual refresh to see whether anything new showed up in the last ten minutes.
How do you read what a scan found?
/graph and /graph/[id] give you an interactive Cytoscape.js-powered attack graph, which is the dashboard's way of showing how a chain of findings connects rather than making you piece it together from a flat findings list. For a hunter chasing something like an IDOR that leads into a privilege escalation path, seeing that relationship laid out visually is faster than cross-referencing finding IDs by hand.
The findings table itself, reached from /scans/[id], supports filtering, so on a target with a few hundred findings you can narrow down to a severity band or a vulnerability class before you start manually triaging anything. Export is available from the same page, which is where the dashboard hands off to whatever format your pipeline or report actually needs.
Where do credentials, network and cloud assets live?
A handful of pages exist specifically for asset types that do not fit neatly into a flat findings list. /credentials holds the credential vault and test results, /network shows a host and service topology map, /ad surfaces Active Directory enumeration results, /cloud is the AWS, Azure and GCP asset inventory, and /oob is the out-of-band callback log, the record of interactions triggered when a payload reaches back out to a listener you control, which is often the only proof a blind vulnerability actually fired.
Keeping these as dedicated pages rather than burying them inside a generic findings table means a hunter working a cloud-heavy target can go straight to /cloud and see the asset inventory Vexta built up, instead of filtering a mixed list of subdomains, endpoints and cloud resources down to what they need.
How do you manage schedules, settings and wordlists?
/schedules is where cron job management lives for recurring scans, /configuration handles API keys, notification channels and hunting settings, and /settings covers server configuration, TLS, the AI provider connection and template management. /wordlists is the page for uploading and managing the subdomain, directory and parameter wordlists a scan draws on.
None of this requires editing a config file by hand. If you run engagements as part of a wider practice, being able to point a client-facing summary at a dashboard, rather than a raw export, also helps when you are reporting progress under an engagement covered by a VAPT service rather than a one-off scan.
What protects the dashboard itself?
The dashboard supports dark, light and auto themes, which is a small thing until you are staring at findings for six hours straight. More important is what protects access to it: CSRF protection on the web UI, and TOTP-based multi-factor authentication available at /setup and enforced at /login alongside the standard email and password check. /activate is where a license gets bound to the install in the first place.
Because Vexta runs as a self-hosted binary and scan data stays on the machine it runs on, the dashboard you are looking at is talking to your own instance, not a shared multi-tenant service. Only the license key and hardware ID talk out to the license server; everything you see on these 17 pages, findings included, stays local.
That distinction is worth spelling out for anyone evaluating a scanner for client work. A dashboard backed by a shared cloud service means a vendor is a link in the chain that holds a client's findings, however briefly. A dashboard backed by a self-hosted, agentless binary means the only place that data exists is the machine you chose to run it on, which is a simpler story to tell a client asking where their vulnerability data actually lives.
Key takeaways
- The dashboard spans 17 pages covering the full scan lifecycle, from launch to graph view to export.
- Scan progress and new findings update over a live WebSocket connection, no manual refresh needed.
- Dedicated pages exist for credentials, network topology, Active Directory, cloud assets and OOB callbacks.
- /schedules, /configuration, /settings and /wordlists cover recurring scans, notifications, server config and wordlist management.
- CSRF protection and TOTP MFA protect the dashboard, and all scan data stays on the machine Vexta runs on.
Frequently asked questions
Does Vexta require the command line to run scans?
How many pages does the Vexta dashboard have?
How does the dashboard show scan progress?
What is the attack graph view for?
Does the dashboard connect to a shared cloud service?
How is the dashboard secured?
See the dashboard on your own targets
Run a scan, watch it progress in real time, and review the findings and attack graph from one dashboard.

