Organisation dashboard data processing

Last updated: September 18, 2026

The organisation dashboard is the only part of Vulkro that uploads anything about your code. This page says exactly what it sends, who handles it, how long it is kept, and how to stop.

Everything else about Vulkro is unchanged: scanning runs on your own machine, needs no account and no network, and uploads nothing. See the Privacy Policy for the product as a whole.

1. It is optional, paid, and off by default​

Nothing is published until you deliberately run vulkro publish (or vulkro-sf publish) and accept the publishing terms. The dashboard is part of the paid online plan.

Two commands let you see exactly what you are agreeing to before you agree to it:

• vulkro publish --terms prints the publishing terms and exits.
• vulkro publish --preview prints the exact snapshot for the repository in front of you and sends nothing. It needs no licence and no network.

2. Who is who​

You are the controller of the data you publish. Where the dashboard is hosted by us, Reveriext acts as a processor and handles the data only to provide the dashboard to your organisation.

If you self-host the organisation server on your own infrastructure, we receive nothing at all: the data stays on your systems and we are not a processor of it.

3. What a snapshot contains​

One snapshot describes one repository at one moment:

• the repository's git remote, and in a monorepo the sub-project path
• the branch name
• file and module names, API routes and endpoints, and handler names
• the file and line behind each finding, with its rule, severity and disposition
• data-flow and data-access maps, hotspots, and the code-structure map
• your dependency inventory: package name, version, ecosystem, and the CVE or GHSA identifiers recorded against it
• contributor names, together with a one-way hash of each contributor's git email address
• the scanner version and the vulnerability-data bundle date

4. What a snapshot never contains​

• your source code or any code snippet
• finding message bodies
• secret values or credentials, in any form, including redacted forms
• raw email addresses (only the one-way hash is sent)
• the licensing machine identifier

5. Personal data, and the setting that governs it​

A snapshot carries your colleagues' names, because the dashboard is used for audit and ownership decisions and a hash cannot be audited. The hashed email exists only so that two people with the same name stay distinct and one person stays stable across a name change.

This is personal data about your staff. Two consequences follow:

• Your organisation controls whether names are published at all. The contributor-names setting exists for exactly this, and turning it off leaves the coverage, finding and trend data unaffected.
• You confirm, by publishing, that you are authorised to publish your colleagues' names and that doing so is compatible with your own internal rules, including any staff-monitoring or works-council obligations.

vulkro publish --preview prints the names that would be sent, so a developer can see precisely what their employer will see about them.

6. Purpose​

Published data is used only to provide the organisation dashboard to your organisation: coverage, open findings and their disposition, trends, the P0 queue, dependency and advisory views, and adoption. It is not used to train models, is not sold, and is not shared with anyone outside the processing described here.

7. Network use at publish time​

Publishing uses the network to reach your organisation server. If you enable live vulnerability lookups (VULKRO_CVE_LIVE), Vulkro may also query public advisory databases to enrich advisory data at publish time. Only the package coordinates needed to look up an advisory are sent to those services. Your source code is never sent to them.

Setting VULKRO_OFFLINE=1 refuses publishing and every other outbound call. A fully air-gapped organisation dashboard is not supported: if your machines have no route out, the offline plan scans without it.

8. Retention​

Snapshots are kept for your organisation's configured retention window, which defaults to 90 days, and are then aged out. The durable trend rollup keeps aggregate counts only, so a trend line survives the underlying snapshots being dropped.

For a self-hosted server, retention is whatever you configure on your own infrastructure.

9. Access​

• Anyone in your organisation who holds the right to publish may send a snapshot, from a developer machine or from CI.
• Only organisation admins can view the dashboard.
• Publishing and viewing both stop if the organisation's plan lapses. Scanning continues regardless.

10. Sub-processors​

Where we host the dashboard, the infrastructure sub-processors we use are listed in the Privacy Policy. We will update that list before adding a new sub-processor that handles published data.

11. Withdrawing​

You can stop at any time, and stopping is immediate:

• Stop running publish commands, or disconnect the machine. Nothing further is sent.
• Ask an organisation admin to remove data already published.
• On a self-hosted server, delete it directly.

12. A signed agreement​

If your procurement process needs a countersigned data-processing agreement, a security questionnaire, or a record of processing, write to contact@vulkro.com and we will provide it.

13. Changes​

If what a snapshot contains changes, this page and the terms printed by vulkro publish --terms change with it, and the --preview output will always show the current payload.

Contact​

Questions about this page, or about data already published: contact@vulkro.com.