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=1enforces this at the binary boundary; the only network ingress the binary ever performs is the signed CVE bundle download onvulkro 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
.gitignoreand 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.gitignorefilter. - 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 moreSecurityFindingrecords. 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=1refuses 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.):
| Vulkro | Cloud SAST | |
|---|---|---|
| Source code uploaded to vendor | No | Yes (the scan happens on their infrastructure) |
| Scan results visible to vendor | No | Yes (stored in vendor's database) |
| Used to train vendor's models | No | Sometimes (read the terms of service) |
| Subject to vendor data-breach exposure | No | Yes |
| Inspectable build artefacts | Yes (signed binaries) | No (server-side) |
| Reproducible benchmark | Yes | Vendor-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:
- 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. - 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. - 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.