Why this exists
I built Vulkro because every SAST tool I tried wanted my code on their server. The cloud-SAST vendors upload it. The paid tiers of OSS scanners pull it through their cloud. The big appliance vendors sell you a private instance and then ship telemetry by default with a checkbox buried two settings menus deep.
I write code for a living. My code is full of half-finished ideas, embarrassing comments, customer names in test fixtures, secrets I haven't rotated yet. I don't want any of that on someone else's hard drive. Not for a free tier, not for a $40-per-seat-per-month tier, not for the privilege of seeing 22% of the bugs.
So Vulkro is a CLI. It reads your code on your machine. It never calls home. $19 for a month or $149 for a year, no auto-renewal. There is no "Pro" tier where the good rules are paywalled, no upsell path to a $50,000 enterprise deployment, and no surprise charges. The benchmark is public, the methodology is documented, and you can run the full product before paying.
I am one person. If that worries you, please buy something else. If that's the reason you're reading this, welcome.
Why offline is the only acceptable default.
Three things happen when a SAST vendor takes your code into their cloud. First, you're trusting their TLS, their employee access controls, their incident response. Second, you're producing analysis artifacts that live on their disks indefinitely, which becomes a discovery problem if your customers sue you. Third, you're feeding their training corpus, whether or not they have an LLM today.
None of these are theoretical. The 2023 Codecov breach exfiltrated CI secrets from thousands of repositories because a CI plugin shipped credentials to a vendor by default. The 2024 Snowflake breach demonstrated that one compromised credential at one vendor unlocks every customer's data simultaneously. SaaS security tools concentrate risk. They don't reduce it.
The argument for cloud SAST is convenience. "We do the heavy lifting for you." The honest version is that the vendor needs your code on their servers to bill you for compute and to train next year's product. If the heavy lifting actually had to happen on a remote server, none of the offline tools (Bearer, Semgrep CE, Brakeman, Bandit) would run.
Vulkro runs on a laptop. The 13-repo benchmark corpus finishes in 104 seconds on commodity hardware. There is no heavy lifting that requires a data centre.
What we don't collect, and how to verify it.
Vulkro collects nothing. No anonymised usage stats, no error reports, no installation pings, no "anonymous opt-in" anything. The only network call the binary ever makes is to check for a newer release once per machine per day, and that check is documented, opt-out via VULKRO_NO_UPDATE_CHECK=1, soft-fails after a 2-second timeout, and reads exactly one URL: the GitHub Releases atom feed for vulkro.
You don't have to trust this. The binary is statically linked. Run it under strace, dtrace, or your favourite sandbox. The only DNS lookup is api.github.com and only when the cache is older than 24 hours.
VULKRO_OFFLINE=1 removes even that call. With the variable set, vulkro refuses every outbound network operation and returns an error rather than silently fall back to anything.
$ VULKRO_OFFLINE=1 vulkro scan .
[ok] offline mode enforced
[ok] CVE bundle: ~/.vulkro/cve-bundle/ (signed, verified)
[ok] no outbound network calls permittedOne developer maintains this.
My name is Arpit Sharma. I built Vulkro. I write the detectors, sign the CVE bundles, write the docs, answer support email, and ship the website. The codebase is roughly 60,000 lines of Rust on tree-sitter. The CVE bundler is a separate Python pipeline I ran for the first time in May 2026.
What that means in practice: when you email [email protected], I read it. Reply time is usually a day, sometimes faster. There is no Tier 1 routing through a partner support contractor. The flip side is that if I'm on a flight, you wait. I'd rather tell you that up front than pretend otherwise.
Arpit SharmaMaintainer, Vulkro · [email protected]
What we commit to.
- The benchmark stays public. Methodology, ground truth, scoring code. Re-run any time. If we regress on F1 between releases, file an issue and we'll fix it or document why. The detectors themselves are closed (that's the product); the validation that they work isn't.
- Breaking changes get a deprecation window. A CLI flag, a config key, or a JSON field doesn't disappear without a release of warnings.
- No telemetry, ever. This is the one commitment we will not negotiate. There is no "anonymous opt-in" path on the roadmap.
- No surprise charges. No auto-renewal, no auto-upgrade, no upsell modal. When your license lapses the CLI prints a one-line note and asks you to buy a new one. Until then, nothing changes.
And where we're going.
There is an enterprise path on the roadmap, with private rule packs, air-gapped license servers, on-premise CVE mirroring, and SSO. It is still a plan. The shape will be "a heavier license you renew yourself" not "a SaaS console", because nothing about the core product changes when a larger team buys it. If your team needs any of that today, email [email protected] and we'll figure out what works in the meantime. No upsell, no spam, just an honest conversation.
How to reach me.
Newsletter, for the weekly CVE + release digest: vulkro.substack.com
Substack Chat, for in-between threads and live questions: vulkro.substack.com/chat
Reddit, for public Q&A and scan-result discussion: reddit.com/r/vulkro
Bug reports, install help, "I think this finding is wrong": [email protected]
Sales, custom quotes, air-gapped deployments: [email protected]
License transfers, invoices, refund questions: [email protected]
No web form. No AI. No chatbot. Email and the chat threads are the API.