The organisation dashboard
Every other part of Vulkro is built for the person writing the code: the editor extension, the CLI, the local console. The organisation dashboard is for everyone else. It answers the questions a lead, a security manager or an auditor asks, and it answers them across the whole estate rather than one repository at a time:
- Which repositories are connected, and when was each last checked?
- How many issues are open that carry a real proof?
- Which way is that going, over 30 and 90 days?
- What is on fire right now, and who owns it?
It is optional, paid, and off until someone publishes to it.
What it shows
Coverage first. The number a lead can act on is how much of the estate is actually being checked and how fresh each check is. A repository that has not been scanned in three weeks is a more useful thing to know than a big finding count.
Proven issues, then the queue. Issues that carry a complete data-flow proof are shown as open work. Everything unproven is shown as a work queue to triage, never as "vulnerabilities you have". This distinction is deliberate: a dashboard that inflates a number for a non-technical reader stops being trusted the first time an engineer checks it.
A P0 tracker with a time-to-fix clock against an SLA, and the repositories that own each item.
Depth when you want it: dependency and CVE inventory with three-way reachability, the proven attack-path shapes, a codebase and attack-surface map, blast-radius impact ranking, per-repository drill-down, and portfolio comparison across the estate.
Impact and exposure rank what to look at first. They are not a health grade, and the dashboard does not present a single composite score.
Who can do what
| Role | Can publish | Can view the dashboard |
|---|---|---|
| Member with publish rights | Yes | No |
| Admin | Yes | Yes |
| Owner | Yes | Yes |
A developer or a CI job can send a snapshot without being able to read the estate. Viewing is an admin action.
It requires online mode
The dashboard is a network feature. Publishing is refused while offline
mode is on (--offline or VULKRO_OFFLINE), deliberately and with an
actionable error rather than silently doing nothing, because a team that
believes its dashboard is current when nothing has been published is
worse off than one that is told plainly.
A fully air-gapped organisation is not supported. If your machines have no route out, keep the offline plan: scanning, the editor, the local console and the CLI all work with no network at all, and you lose only the shared dashboard.
A self-hosted organisation server on your own network is not "offline"
from the scanner's point of view. It is simply a different
VULKRO_ORG_URL.
What publishing sends
Run vulkro publish --preview to print the exact payload for a
repository before you send anything. It needs no licence and no network.
A snapshot carries the repository's git remote, the branch, file and module names, API routes and handler names, the file and line behind each finding, the data-flow and data-access maps, your dependency inventory, and contributor names with a one-way hash of each git email.
It never carries your source code, code snippets, finding message bodies, secret values, raw email addresses, or the licensing machine id.
Your source code never leaves your machine. What publishing uploads is a
detailed map of the application, which is what makes the dashboard
useful and is why it is opt-in and covered by a data-processing
agreement. The full terms are on
Organisation dashboard data processing,
and vulkro publish --terms prints them in the terminal.
Hosted, or your own
Use our hosted instance, or run the same organisation server yourself from a Docker image or a Helm chart. A self-hosted organisation stays on your infrastructure and does not appear in anyone else's portal; we receive nothing.
Getting started
vulkro publish --terms # read what you are agreeing to
vulkro publish --preview # see the exact payload, send nothing
vulkro publish . # publish this repository
Then, from CI on your default branch, so the trend is built from one authoritative source:
export VULKRO_ORG=acme
export VULKRO_ORG_TOKEN="$VULKRO_PUBLISH_TOKEN"
vulkro publish . --authoritative
Salesforce builds publish the same way with vulkro-sf publish, tagged
so one dashboard keeps the two products apart.
If a plan lapses
The scanner keeps working. It drops back to one repository at a time in the console and the editor, and the multi-repository views, the portfolio and publishing stop. Vulnerability data stays current, so a lapsed scanner never goes quietly stale.
See also
vulkro publishfor every flag and the exit codes.vulkro fix, which takes a--findingid straight from a dashboard row.- Offline mode for what runs with no network.