Safety

Last updated: July 14, 2026

Vulkro is built around a single design constraint: your source code, your scan results, and your environment never leave your machine.

This page is the operational complement to the Privacy Policy. Privacy explains the legal posture ("we never receive your scan data"). This page explains the engineering posture: how the binary is built so the data cannot leave, even by accident.

What Vulkro never does​

Vulkro the binary, when invoked on your machine, never:

• Uploads source code anywhere. Not to us, not to a model, not to a cloud function. The scanner reads bytes from disk into memory and emits findings to stdout / a file path you control.
• Executes your code. Vulkro is a static analyzer built on tree-sitter. It does not call npm, pip, bundle, go build, cargo build, or any package-manager command. A package manager could (in principle) be subverted by a compromised package; vulkro removes that vector entirely.
• Resolves DNS or makes outbound HTTP requests during a scan. The scan itself is fully local. The binary's network calls sit outside the scan path and are enumerated below; with a license file installed, VULKRO_OFFLINE=1 disables every one of them at the binary boundary.
• Sends content telemetry, analytics, error reports, or any data derived from your code. The account entitlement check carries exactly six usage fields (product, install id, version, operating system, timestamp, and a scan counter), never code, paths, or findings. There is no code path that sends scan content or a diagnostic home.
• Trains a model on your code. No vendor-side model ingest, no fine-tuning loop, no embedding capture. Vulkro is not an AI product in the LLM sense; the detection engine is a pattern-matching static analyzer.
• Reads files outside the scan root you pass. The default scan root is the working directory; subprojects are detected only within. Vulkro respects .gitignore and the Vulkro config's exclude patterns.

What Vulkro does do​

Three things, all local:

• Read source files within the scan root. The reads are bounded by the cap flags (--max-file-size, --max-files) and the .gitignore filter.
• Parse the source via tree-sitter grammars compiled into the binary. Parsing is in-memory; no temp files, no fork-exec.
• Match the parse tree against the detector catalog. Each detector is a Rust function that takes the AST + source bytes and emits zero or more findings. Findings are serialized to your chosen output format and written to stdout or your file.

That is the entire scan. No phase of it requires the network, the package manager, your shell, the system clipboard, or any remote service.

The network calls, enumerated​

The binary makes exactly three kinds of outbound call, none of which occurs inside a scan and none of which carries code, paths, or findings:

• The account entitlement check. Vulkro requires an account (vulkro login); the check verifies your entitlement about once a day and sends the six usage fields listed above, nothing else. Air-gapped machines use a signed license file instead and make no call at all.
• The signed CVE bundle download on vulkro update, from dist.vulkro.com, so the dependency-vulnerability matcher has fresh advisory data. It is gated by an explicit subcommand. The bundle is verified against a trust root compiled into the binary; tampering at the CDN is rejected.
• The release version check: a small JSON feed on the same CDN, fetched at most once per machine per day (24-hour cache, 2-second timeout, fail-silent) to print a one-line upgrade notice. Opt out with VULKRO_NO_UPDATE_CHECK=1.

If your network policy blocks all of this, run the binary fully offline:

• VULKRO_OFFLINE=1 refuses every outbound call (the entitlement check, the CVE bundle fetch, and the version check). Pair it with a license file and the scanner runs fully disconnected.
• You can also fetch the bundle on a machine with internet access and copy it to ~/.vulkro/cve-bundle/; vulkro reads it from disk.

The bundle ingress is documented in Offline mode and Bundle format.

Versus cloud-hosted SAST​

Vulkro's positioning vs the SaaS scanners (Semgrep AppSec Platform, Snyk, Bearer Pro, Aikido, etc.):

Cloud SAST has real strengths (managed updates, web UI, centralized policy) and Vulkro is not trying to replace it for every team. But if "the vendor never sees the code" is a hard requirement (defense, healthcare, finance, anyone under NDA with their customers), Vulkro is built to make that requirement enforceable rather than trust-based.

How to verify​

Skepticism is welcome. Three concrete checks:

1. Run with the network disabled. VULKRO_OFFLINE=1 vulkro scan . produces the same findings as a connected run (modulo CVE bundle freshness). A scanner that "needs the cloud" would fail or hang.
2. Snoop the network at the OS layer. lsof -i, tcpdump, or your firewall logs while a scan runs will show zero outbound connections from the vulkro process.
3. Check the public artifacts. Vulkro is closed source (the detector implementation is the licensed product), but the binary is not obfuscated, and the benchmark harness and methodology plus the compliance mapping are public, so the accuracy and evidence claims are verifiable without the rule engine.

Reporting a safety claim that turned out to be wrong​

If you find a code path that contradicts anything on this page, treat it as a security bug and email security@vulkro.com with the reproduction. The safety guarantees on this page are load-bearing; a bypass is treated with the same seriousness as an authentication bypass would be in a customer's product.