Skip to main content

Safety

Last updated: May 24, 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. VULKRO_OFFLINE=1 enforces this at the binary boundary; the only network ingress the binary ever performs is the signed CVE bundle download on vulkro update (see below).
  • Sends telemetry, analytics, error reports, or anonymized usage data. The binary has no telemetry endpoint compiled in.
  • 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 wiremap 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 (src/security/). Each detector is a Rust function that takes the AST + source bytes and emits zero or more SecurityFinding records. 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 CVE bundle: the one network ingress

vulkro update downloads a signed CVE bundle from dist.vulkro.com so the dependency-vulnerability matcher has fresh advisory data. This is the only outbound network call the binary ever makes, and it is gated by an explicit subcommand. The signed bundle is verified against a trust root compiled into the binary; tampering at the CDN is rejected.

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

  • VULKRO_OFFLINE=1 refuses every outbound call (including the CVE bundle fetch).
  • 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.):

VulkroCloud SAST
Source code uploaded to vendorNoYes (the scan happens on their infrastructure)
Scan results visible to vendorNoYes (stored in vendor's database)
Used to train vendor's modelsNoSometimes (read the terms of service)
Subject to vendor data-breach exposureNoYes
Inspectable build artefactsYes (signed binaries)No (server-side)
Reproducible benchmarkYesVendor-published only

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. Read the source. Vulkro is closed source (the detector implementation is the licensed product), but the binary is not obfuscated, and the benchmark harness plus compliance mapping are public. The CVE bundler tool (tools/cve-bundler) that produces the signed advisory data is also public, so the only network input to a scan is reproducible end-to-end.

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 [email protected] 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.