Trust

This page is for the person who has to approve running a third-party, closed-source tool on a private codebase: the security lead, the CISO, the reviewer who answers the procurement questionnaire. The claim you are being asked to sign off on is architectural, so here it is in plain words: the entire analysis runs on your machine. Your code is never uploaded, and it never enters a model. Everything below is the detail behind that sentence, with a way to verify each part yourself.

Where your code goes​

Nowhere. Vulkro is a single binary; the detection engine and the CVE database ship inside it. A scan reads your files locally, analyzes them locally, and writes results locally (to your terminal, to ~/.vulkro/, or to the report file you asked for). There is no cloud analysis tier, no "deeper scan" that uploads code, and no model API call anywhere in the scan path.

You do not have to take that on faith. Pull the network cable and the scan still runs:

VULKRO_OFFLINE=1 vulkro scan .

VULKRO_OFFLINE=1 refuses every network call that would leave this machine, so if the scanner needed your network to analyze your code, this command would fail. It does not. On Linux you can make the test stricter by running the scan inside a network namespace with no interfaces at all; the air-gap guide shows how.

What crosses the wire, exactly​

Vulkro requires a verified account, and the account layer does make network calls. Here is the complete list of what they carry.

• The usage heartbeat. Sent on a debounced cadence (a background ping at most once a day, plus a flush after a completed scan at most once an hour), it carries up to eight fields: product, install id, version, operating system, timestamp, and a scan counter, plus a device token when this machine is signed in, and a short set of language slugs (for example go,java,javascript) when the last scan detected them. The install id is a random identifier minted once at install time; it is not a hardware fingerprint. No source code, no file paths, no filenames, and no finding contents are ever part of it.
• Sign-in and the entitlement refresh. vulkro login and the recurring lease refresh carry a device token so the server can confirm your seat and return a signed lease. They never carry code, paths, or findings.
• Downloads, not uploads. Installing the binary and running vulkro update fetch checksummed artifacts from our CDN. Nothing about your project is sent to request them.
• Vulkro AI (local) does not use the wire. The advisory AI layer talks to a local Ollama runtime at 127.0.0.1, on your machine. On that loopback path the prompts, and the code snippets inside them, never leave the machine, and no API key exists because there is no service behind it. Pointing the layer at a remote OpenAI-compatible endpoint instead is an explicit choice you make with a flag, an environment variable, or vulkro ai use; it is never a default. Under VULKRO_OFFLINE=1 the loopback path keeps working and any non-loopback endpoint is refused. See vulkro ai.

What is never sent, from any code path in the product: your source code, your file paths, the contents of any finding, and machine identifiers such as the hardware fingerprint. There is no crash reporter and no feature-use analytics in the binary.

All of it can be turned off. VULKRO_OFFLINE=1 disables every call that would leave the machine (the loopback AI path above stays available, because a call to 127.0.0.1 does not), and air-gapped machines use a signed license file instead of the online sign-in, so they satisfy the account requirement with zero network access. The per-call breakdown lives in the privacy policy and the network reference.

Deterministic by design​

There is no AI inside the scan. Findings come from program analysis (parsers, taint tracking, rule evaluation), not from sampling a model, so the same code produces the same verdict on every run.

That property is what makes the tool safe to put in charge of anything. A CI gate that flickers gets bypassed within a week; a deterministic gate can block a merge and be trusted to block the same merge tomorrow. For audits it means evidence is reproducible: anyone can rerun the scan on the same revision and get the same findings, which is what an assessor actually asks for. And because no model is involved, there is no prompt surface to inject, no model drift between runs, and no vendor inference endpoint with a copy of your code.

The advisory layer is the documented exception, and it is fenced off. Vulkro AI (local) runs only when you invoke it (for example vulkro triage), and it asks a model for an advisory second opinion on the findings determinism cannot judge on intent. By default that model is local, served by an Ollama runtime at 127.0.0.1, so even the advisory path sends nothing off the machine and needs no API key; a remote endpoint is an explicit opt-in. Its verdicts are labelled advisory, they never change a deterministic scan result, and the benchmark is scored with AI off. vulkro scan itself makes no model call under any flag. See vulkro triage and vulkro ai.

Closed source, verifiable anyway​

The detection engine is proprietary; it is the licensed product, and we do not publish it. We are not asking you to trust unreadable code on reputation, though. The things that let you check the product are written down.

The benchmark is scored against catalogued bugs, not adjectives. Every bug in the corpus is pinned to a public CVE or GHSA advisory in a real project, and a finding counts only if it lands within five lines of the catalogued bug. The scored head-to-head covers 83 catalogued bugs; Vulkro finds 47 of them at 0.78 precision on the default high-confidence setting. The methodology, the scoring rules, and the complete results are all below.

Check any number against the advisory it cites. The benchmark methodology documents the scoring rules, the provenance rule, and the complete results.

Every finding explains itself. Each finding carries a stable ID, and vulkro explain <ID> documents what the check looks for, why this instance fired, and how to fix it. You can audit the behaviour of every detector you encounter, in the product, before you trust its verdict.

The changelog is public. Every release documents what changed at vulkro.com/changelog, so the tool you approved does not drift silently.

The network claim is testable. The VULKRO_OFFLINE=1 test above is the blunt instrument: run it on a machine with no route out and watch the scan complete.

Account and licensing data​

Scanning requires a verified account. Your first device sign-in starts a 14-day trial of the full product, and after the trial licenses are issued per seat, directly by our team; there is no self-serve checkout.

The account portal stores what a license needs and nothing from your codebase: your email address, license and seat records, the names of the devices you have signed in (you can rename or deauthorize them), and the usage counters from the heartbeat above. It cannot store code, paths, repository names, or findings, because the scanner never sends them. Air-gapped machines are licensed with a signed .lic file and never appear in the online device list at all. The full data-handling statement, including payment processing and retention, is in the privacy policy.

Security of Vulkro itself​

A scanner runs with read access to your source, so its own supply chain has to hold up.

• Checksummed releases. Every release ships a SHA-256 checksums manifest covering every platform binary, so you can confirm the download you got is the one we published:

  # replace v0.19.0 with the version `vulkro --version` reports
  curl -fsSLO https://dist.vulkro.com/releases/v0.19.0/vulkro-0.19.0-mac-arm64.tar.gz
  curl -fsSLO https://dist.vulkro.com/releases/v0.19.0/SHA256SUMS
  shasum -a 256 -c SHA256SUMS --ignore-missing
  

  That is an integrity check, not an authenticity one. Releases are not yet signed, and we would rather say so than imply a guarantee we do not currently provide.

• CVE data ships inside the checksummed binary. The CVE database and rule packs are baked into the binary, so the checksums manifest above already covers them: verify the download and you have verified the detection data along with it. An Ed25519 signing path for out-of-band bundle updates is wired into the code, but no trusted signing key is compiled into shipped binaries yet, so we do not claim runtime signature verification today: the binary-baked data remains the source of truth until that key is published. See signing and trust roots.

• Reporting a vulnerability. If you find a security issue in Vulkro, email [email protected]. The coordinated-disclosure policy and our response commitment are on the security page, and the machine-readable contact is at /.well-known/security.txt.

See also: Security policy, Privacy policy, Benchmark, Air-gap install.