Vulkro for enterprise

Answer the security review before it starts.

Your source code never leaves the machines you already own. Vulkro installs and runs inside your perimeter, and there is no service anywhere else doing the analysis, so there is no upload to review, nothing of ours in the path of a release, and nothing to negotiate about where your code lives. This page is written for the three people who decide whether a scanner gets in: the security reviewer, the operator installing it somewhere with no route to the internet, and whoever has to complete the questionnaire.

Start the 14-day trial Request a license →

No code upload
Air-gapped install supported
The same answer every time

$ VULKRO_OFFLINE=1 vulkro scan .
  offline mode: outbound calls refused

CRITICAL  SQL injection in invoice lookup
            services/billing/invoices.py:118
HIGH      Missing authorization on export route
            services/billing/routes.py:41

1,284 files scanned. 0 network calls.
exit 1 (findings present)

The same scan, with every outbound call refused.

01 / The architecture

It runs inside your perimeter.

A review reads your files, works out what an attacker could reach, and writes the results back to disk. All of that happens on the machine you started it on. The reason your security review of us is short is that there is no second place for your code to be.

No upload, by construction

Nothing in the product sends your code anywhere. You do not have to take that on faith: switch on offline mode, which refuses every call that would leave the machine, and the review still completes. If it secretly needed a server of ours, that run would fail in front of you.

Nothing of ours can break your release

A review does not call out to run. Your pipeline stays green when our systems are unreachable, and a review on a disconnected build machine produces the same result as one on a laptop.

The same answer every time

The same code produces the same findings on every run and on every machine. No model scores, ranks or filters a finding, which is what lets a review block a release instead of starting an argument about why the result moved.

trust boundaryone switch closes it

Everything the scan needs stays on your machine: the code it reads, the map it builds of how your product fits together, the findings it writes, and the optional local model it can consult without leaving the machine. One line leaves.

Stays on this machine: source code, call graph + taint, findings, account layer, and the local model on 127.0.0.1
One crossing: A signed entitlement check and a usage counter, on a debounced cadence.
Never crosses: source code, file paths, file names, finding contents, project names, the hardware fingerprint

The scan pipeline never touches the wire. The account layer is the only thing on it.

02 / Air gap

Install it on a machine with no route to the internet.

The offline path is not a degraded mode. Copy the program in, install a signed license file bound to that machine, and refresh vulnerability data from a file you carry across the boundary yourself. What it finds is identical, because everything it needs is already on that disk.

A license that never phones home

Disconnected seats run on a signed license file bound to that machine. No sign-in, no renewal call, no outbound traffic at any point in its life. An operator can check the license state from the machine itself, with no network.

Vulnerability data you carry in

Vulnerability data publishes as a single file. Move it across the boundary on whatever media your policy allows, apply it, and the matching against your own dependencies happens on that machine. Each file is checksummed and the checksum is verified before it is applied. The data we publish by default covers npm and PyPI, and a wider set adds Go modules, crates.io and Maven.

One switch that enforces it

Offline mode refuses every call that would leave the machine: sign-in, the license check and the check for a newer version alike. Set it once in your build image and the guarantee is enforced by the software rather than promised by a page like this one.

Updates on your schedule

Nothing updates itself. A new version and new vulnerability data are both files you choose to bring in, which means the version that passed your review is the version that keeps running until you decide otherwise.

$ vulkro activate ./platform-team.lic
  license installed: machine-bound, offline

$ vulkro update --bundle ./vulkro-cve.vkbundle
  checksum verified, advisories applied locally

$ VULKRO_OFFLINE=1 vulkro scan .
  no outbound call attempted

Three commands, no network at any point.

03 / The estate

Across every repository, not one at a time.

An organization with two hundred services does not have a per-repository problem. It has a portfolio problem: which teams got worse this quarter, which mistake was repeated in eleven places, and which of those eleven is exposed to the internet. Vulkro rolls every repository you point it at into one view, on one machine, with no server in between.

vulkro serve - 127.0.0.1:8723local desktop console

Portfolio rollup

ranked by risk score

Per-project severity totals and risk score across the portfolio
Project	Type	Risk	CRIT	HIGH	Findings
checkout-service	node	71	2	9	38
billing-api	java	64	1	12	44
identity-gateway	go	58	0	7	26
partner-portal	python	43	1	4	19
notification-worker	node	22	0	2	11
209 more projects	sorted by risk score, filterable by team folder

platform-estate214 projects rolled upoffline: no network calls

The console reads the rollup from results already saved on this machine. The same rollup prints as a table on the command line.

One view over every repository

Point it at the directory that holds your repositories and it reviews each one, then writes a single rollup: totals per project and a risk score you can rank on. Two further views answer the estate questions directly: the same mistake in the same file across several repositories, and one row per problem type showing how it scored in each.

An export your own tools can read

Each repository can also be written out as a stable, versioned document: where untrusted input enters, where it ends up, and the route between them. It is meant to be archived, compared over time and read by whatever you already run, and the version is stamped on it so a change to the format is never a silent one.

Possible links between services

Given those exports, Vulkro points out where one service calls an address another service exposes, so a risk that looks small inside one repository can be seen in the context of the next. These are leads for a reviewer to follow, and they are reported as possible, never as proven.

Progress you can show a board

Each review can be saved as a snapshot, and that history is what shows whether risk is going up or down. A quarterly board update reads from records you already hold on your own machines, not from a window a vendor decides how long to keep open.

One finding format everywhere

A finding looks the same in the console, in the report you send to a team, and in the files your other tools read, across every repository. Nothing has to be reconciled between two tools before the numbers can be added up.

Nothing to stand up first

The rollup is built from files on disk. There is no system of ours to deploy, no agent to install on every build machine, and nothing that has to be reachable for a review to run.

04 / Evidence

Evidence an auditor can open.

An audit does not accept a dashboard. It accepts files: an inventory of what you ship, a statement about which known vulnerabilities actually apply to you, and a control-by-control record of what was checked and what it was checked against. Vulkro writes all three to disk on your machine.

vulkro cra-bundle . --framework soc2-fullexit 1, findings present

cra-readiness.zip/built on this machine
- index.htmlreadiness one-pager
- compliance/soc2-full, 61 controls
  - manifest.jsonframework, scan id, control summary
  - summary.mdevery control with its status
  - findings.csvfinding to control mapping, flat
  - soc2-full.htmlper-control evidence table
  - controls/one file per control
    - CC6.1.jsonPass
    - CC6.6.jsonPartial, 2 findings
    - CC7.2.jsonFail, 1 finding
    - CC8.1.jsonPass
    - P4.1.jsonPass
    - ...56 more control files
  - README.mdwhat each file is, and what it is not
- sbom/
  - cyclonedx.jsonCycloneDX 1.6
  - spdx.jsonSPDX 2.3
- vex/
  - openvex.jsonOpenVEX 0.2.0, per CVE

$ vulkro compliance-pack . --framework soc2-full --output ./compliance/

vulkro cra-bundle runs the same pack and writes it into one zip with the SBOM and VEX documents beside it. Every file is generated locally: nothing is uploaded, and each control file cites the findings and endpoints it was built from.

An evidence pack is a directory of files an auditor can open, diff and archive.

SBOM in both formats

CycloneDX and SPDX, both built from the dependency files in the repository rather than by a service that has to be shown what you depend on. Both land beside the evidence pack, so one download answers the question of what you ship.

A statement on every CVE

An OpenVEX document ships beside the SBOM, one statement per published vulnerability. Turn on the reachability check (it is off by default) and each one is marked reachable or not, with the route from your own code to the vulnerable function recorded behind the verdict. A vulnerability nothing in your product can reach is set aside with evidence rather than sitting in the queue as noise.

Per-control compliance evidence

The compliance pack writes one folder per framework: a summary, a spreadsheet linking every finding to the control it touches, and one file per control citing the findings and the endpoints it was built from. The CRA bundle staples that together with the SBOM and VEX documents into a single zip an auditor can be handed.

Framework mappings, the profiles available, and what each pack does and does not assert are covered on the regulated industries page.

05 / The wire

What crosses the wire, exactly.

Vulkro needs a verified account, and checking that account is the one thing that touches the network. Here is the whole request. It carries usage counters: there is nowhere in it for a finding to travel, and nowhere a file name could sit. Disconnected installs replace it entirely with a license file on disk.

Entitlement check to Vulkroat most once a day

Field and example value	What it carries
"product": "vulkro",	which binary made the call
"install_id": "3f9c1a7e-5b40-4c8d-9a21-7ce4d0b28f16",	a random id minted at install, not a hardware fingerprint
"version": "0.21.0",	the build that is running
"os": "macos",	operating system family, not a machine name
"scans_since_last_heartbeat": 4,	how many scans ran since the last call
"timestamp": "2026-08-15T09:41:02Z"	when the call was made

Not in the bodysource code, file paths, file names, project names, finding contents, the hardware fingerprint

Read the per-call breakdown at /docs/air-gap/network. Set VULKRO_OFFLINE=1 and the call is refused instead of made.

The complete request body. Usage only: there is no field for a finding to travel in.

The software itself is the source of truth for that field list, and it adds a device token once this machine is signed in.

06 / Procurement

The paperwork, and who to send it to.

Most of a security questionnaire asks where the data goes, which is why the architecture above makes this section short. These are the answers reviewers ask for first, in roughly the order they ask them.

Where does our source code go?: Nowhere. It is read from the disk of the machine running the review and is never sent anywhere.
Is there a cloud service that analyses our code?: No. Everything the review needs, including the vulnerability data, is installed on your machine.
Does a scan need network access?: No. A scan on a disconnected build machine produces the same result as one on a laptop.
Does an AI model see our code?: Not during a review. The optional AI help talks only to a model running on the same machine, and it can never change what the review found.
What does leave the machine?: A license check carrying usage counters and nothing else, and offline mode refuses even that.
Can we run it with no route to the internet at all?: Yes. A signed license file bound to that machine replaces the sign-in, and vulnerability data is applied from a file you carry across the boundary.
Where are findings stored?: On the machine that ran the review: a local database, plus whatever report file the run was asked to write.
Who do we send the questionnaire to?: The address on the contact page. Reports about a vulnerability in Vulkro itself follow the security policy.

Security questionnaire

Send the questionnaire your process uses, whether that is a standard one or your own spreadsheet, and we complete it against this architecture rather than a generic template. Say which questions are blocking and we answer those first.

DPA and processing scope

Nothing from a review reaches us, so the review itself sits outside the scope of any processing agreement. What is in scope is the account: an email address, an install identifier and usage counters. Ask for a DPA covering that scope and name the contracting entity in the request.

License request

Licenses are issued directly by our team, per seat, on request, for the review of your codebase, the review of your Salesforce build, or both. A 14-day trial of the full product starts on your first sign-in, with no card. Seats with no route to the internet get a signed license file bound to the machine instead of a sign-in.

Reporting a vulnerability in Vulkro itself is a different path: follow the security policy.