We assume your repo is sensitive
That's why VibeGuard runs locally by default. Here's exactly what happens with your code and data - no marketing fluff, just the facts.
Security is about trade-offs. We'll explain ours clearly so you can make informed decisions.
Security is engineering, not theater
A security tool that uploads your code to a cloud for scanning creates a new attack surface. A tool that stores your API keys creates a target for theft. A tool that "phones home" with telemetry creates a data trail you didn't ask for.
We designed VibeGuard with a simple principle: minimize data movement, maximize user control. Not because it's a marketing differentiator, but because it's the right engineering decision for a tool that handles sensitive code.
This page documents exactly what VibeGuard does with your data, what trade-offs we made, and why. If anything here concerns you, don't use the tool. If you have questions, email us. We'd rather lose a customer than mislead one.
What we assume about your data
Our design decisions start from these assumptions.
Your repository is sensitive
It might contain API keys, proprietary algorithms, customer data patterns, or trade secrets. We design as if every repo we touch contains all of these.
Scans run entirely on your machine. We never see your code.
Your LLM API key is sensitive
It has spending limits, rate limits, and access to powerful models. A leaked key can cost you money and enable abuse.
Your key is stored locally and sent directly to your provider. We never see or store it.
Metadata can be sensitive too
File paths, directory structures, and dependency lists can reveal information about your project. Even 'anonymized' data can be re-identified.
We don't collect file paths, project names, or finding details. We don't have analytics dashboards showing 'what our users are scanning.'
Network requests are attack surface
Every outbound connection is a potential data leak point, interception vector, and availability dependency.
Free tier requires zero network access. Pro requires network only for license validation and policy bundle updates - never for scan data.
What stays local, what leaves
A complete accounting of data flow.
Scanning
All 11 scanners run on your machine. Source code is read from disk, analyzed in memory, and never transmitted anywhere.
- Semgrep, Bandit run as local processes
- Gitleaks checks files on disk
- Trivy scans local container images
- npm-audit reads local package-lock.json
- No code snippets sent to any server
- Works completely offline
Reports
Scan results are written to your project directory. You control if and where they go next.
- JSON, HTML, SARIF stored in .vibeguard/
- Baselines stored locally
- SARIF upload to GitHub is your choice
- No automatic upload anywhere
- No cloud backup of results
- Delete anytime - it's your data
Patching (Pro)
When you run patch, minimal context goes to your chosen LLM provider using your API key.
- You choose: OpenAI, Anthropic, etc.
- You provide your API key
- Key stored locally, never on our servers
- Request goes directly to provider
- We never see the prompt or response
- You pay the provider directly
What "minimal context" means
When you run vibeguard patch, here's exactly what gets sent.
What IS sent to your LLM
- •The specific code snippet with the finding (typically 10-50 lines)
- •The finding message (e.g., "hardcoded secret detected")
- •The file path within your project
- •Instructions for generating a fix
What is NOT sent
- •Your full codebase or repository
- •Other files not related to the finding
- •Your git history or commit messages
- •Environment variables or .env contents
- •Any data to VibeGuard servers
The trade-off: To generate useful patches, we need to send some code to an LLM. We minimize this to the smallest useful context. If you're not comfortable with any code leaving your machine, don't use the patch feature - scanning works completely offline.
SARIF and GitHub Code Scanning
What is SARIF?
SARIF (Static Analysis Results Interchange Format) is an OASIS standard for static analysis tool output. It's a JSON format that describes findings in a tool-agnostic way.
What GitHub does with it
GitHub explicitly supports uploading SARIF files from third-party tools to show alerts in Code Scanning. When you upload SARIF to GitHub, the findings appear in your Security tab alongside GitHub's own CodeQL results.
What's in a SARIF file
The SARIF file contains finding metadata: rule IDs, file locations, line numbers, and messages. It does not contain your full source code. GitHub uses this metadata to annotate your code in pull requests and the Security tab.
Your choice
SARIF export is optional. You can run VibeGuard in CI purely for exit codes (fail builds on critical findings) without uploading anything to GitHub. The SARIF upload is a convenience feature, not a requirement.
What we collect (and don't)
We do NOT collect
- • Your source code or file contents
- • File paths or directory structures
- • Finding details or vulnerability info
- • Dependency lists or package names
- • Git history or commit messages
- • Your LLM API key or responses
We DO collect (Pro only)
- • License validation requests (is this key valid?)
- • Policy bundle download requests
- • Basic error reports (opt-in, anonymized)
Future telemetry: If we add optional telemetry (e.g., anonymous usage statistics to improve the product), it will be opt-in, documented here, and you'll be able to verify exactly what's sent by inspecting network traffic. We will never silently add telemetry.
What our servers actually do
The Pro backend has a narrow scope by design.
Licensing
Validates your Pro subscription. Manages seat counts for team plans. Standard SaaS licensing infrastructure.
Data involved: license key, email, subscription status
Policy bundles
Delivers updated scanning rules and prompting templates. Think of it like antivirus signature updates. No code analysis happens on our servers.
Data involved: bundle version, download timestamp
What we don't have: Dashboards showing "what our users are scanning," analytics on finding types, or any aggregated view of your security posture. We can't sell what we don't collect.
What we gave up for privacy
Every design choice has trade-offs. Here's what our local-first approach costs.
No cloud dashboards
No automatic PR comments
No 'smart' cross-repo insights
BYOK complexity
We're here to answer
If you have questions about our data handling, security practices, or anything on this page, email us. If you find a security issue in VibeGuard itself, we want to know.