securevibe

The local-first SecureVibe CLI — autonomous AI security engineer for AI generated apps. Analysis runs entirely on your machine (tree-sitter AST + taint), no upload required.

Quick start

npm install -g securevibe       # or: npx securevibe scan <path>

securevibe scan <path>          # findings + security score
securevibe ready <path>         # launch readiness scorecard + go/no-go verdict
securevibe fix <path>           # preview fixes (dry run)
securevibe fix <path> --apply   # apply + back up originals (asks per change)

From a clone of this repo instead: pnpm install && pnpm build, then node packages/cli/dist/index.js scan <path> (pnpm demo scans the bundled sample).

The free beta includes a daily usage limit, reset at local midnight (the current count and limit are shown after each run; the limit itself is remotely adjustable and not a fixed number, see below). The --staged commit guard is never limited. See LICENSE.

Commands

| Command | What it does | |---|---| | securevibe scan [path] | Full scan → findings + security score (default command) | | securevibe init [path] | Wire SecureVibe in: pre-commit guard + GitHub Action + gitignore (doc 12) | | securevibe fix [path] | Autonomously fix findings, then re-scan to verify (doc 05) | | securevibe explain [path] | AI-powered plain-language explanations for critical/high findings | | securevibe pr-comment [path] | Post/update a PR findings summary (used by the GitHub Actions workflow) | | securevibe deps [path] | Audit dependencies for known CVEs against the local OSV database (SCA) | | securevibe db <update\|status> | Manage the local OSV database — update is networked | | securevibe update | Update securevibe itself to the latest published version (also networked) | | securevibe ready [path] | Launch readiness scorecard: pass/fail gates + go/no-go verdict | | securevibe ai-audit [path] | Focus on the AI-agent attack surface (doc 04) | | securevibe protect [path] | Remediation-first view: the fix for every finding (doc 05) | | securevibe attack-map [path] | Exploit paths from reachable findings + choke point (doc 06) | | securevibe score [path] | Just the score + deployment-readiness verdict (doc 08) | | securevibe config <show\|set-key\|unset-key> | Manage local Groq/Anthropic keys for the AI-powered fixer | | securevibe repl [path] | Interactive session — run scan/fix/etc without re-invoking the CLI each time |

Flags: --json, --sarif (GitHub code-scanning / CI interop), --no-color, --ci (exit 2 on BLOCK, 1 on WARN, 0 on SHIP — for build gates), --staged (scan only git-staged files — what the pre-commit guard uses), --diff <base> (scan only files changed since <base> — what the PR-comment step uses; also exempt from the daily usage limit, same as --staged). fix flags: --apply (write to disk; asks before each change), --yes (apply every verified fix without prompting — for CI/scripts), --no-llm (deterministic-only), --json. init flags: --force (replace an existing hook/workflow/config).

The REPL renders a bordered input box with a live status line (target + active AI-fixer provider). Type / to open a command-discovery menu, or type commands directly as before (scan, fix --apply, help, etc. — the / prefix is optional, not required). Up/down arrow cycles through your command history. scan/fix/explain show a single live progress spinner instead of scrolling status lines.

Inside the REPL, anything you type that is not a command is a question for the AI about your last scan: "why is finding 3 critical?", "which of these should I fix first?". Answers are grounded in the scan results only; the assistant never sees your files and never claims your code is secure. The first question each session asks before anything is sent to your provider. Needs the same key as fix and explain (securevibe config set-key groq).

Always-on (doc 12)

securevibe init makes the tool continuous so insecure code can't slip through:

• a git pre-commit hook that runs scan --staged --ci and rejects any commit that introduces a blocking issue — including a committed secret (verified: it aborts the commit, then lets the clean version through);
• a GitHub Actions workflow (.github/workflows/securevibe.yml) that scans every PR and uploads SARIF to GitHub code scanning, gates the build on deployment-readiness, and posts a PR comment summarizing findings in the changed files only (updated in place on new commits, not reposted — and one of the few other commands (besides db update and update) that talks to the network, and only to post a findings summary already computed locally, never your source code);
• gitignores .env / backups and drops a minimal securevibe.config.json.

It is idempotent (existing files are left alone unless --force). Everything it installs runs locally — no account, and your secrets / API keys are never stored or transmitted. The one exception is the PR-comment step above, which uploads a findings summary (never your source code) already computed by the local scan.

The fix loop (doc 05)

securevibe fix turns detection into remediation. For every finding it produces a concrete code change, then re-runs the exact same detectors on the new content and only keeps the change if it passes a verification gate:

the targeted finding is gone AND no new medium-or-worse issue was introduced AND the file still parses.

Anything that fails the gate is rolled back and surfaced as a manual instruction.

• Deterministic, offline (zero setup): parameterize SQL (driver-aware placeholders), lock wildcard CORS to an env-driven allowlist, pin weak JWT algorithms, and move hardcoded secrets to env references / gitignore .env.
• AI-powered (optional, set GROQ_API_KEY for the free tier or ANTHROPIC_API_KEY for Claude): targets the logic-level classes a rule can't safely rewrite — RCE/command-injection, AI tool-hijack / missing firewall, IDOR, DOM XSS, and complex SQL. One rewrite per file; the result is kept only if it passes the verification gate, otherwise it falls back to a precise manual instruction. Groq is used by default when both keys are present (lower bar to try it at all); set SECUREVIBE_LLM_PROVIDER=anthropic to force Claude instead.
• Setting a key: securevibe init is the primary path — if it detects an LLM SDK dependency (openai, @anthropic-ai/sdk, langchain, ...) and no key is already set, it offers to set one up on the spot, once per project (declining is remembered so it won't ask again). You can also export a key yourself (GROQ_API_KEY=...), or run securevibe config set-key groq any time — it prompts interactively (never as a command argument, so it never lands in shell history) and saves it to ~/.securevibe/config.json, used automatically whenever the env var isn't already set.
• A second AI feature, securevibe explain: for critical/high findings, asks the same configured provider for a plain-language explanation grounded in the actual flagged code (not just the generic why/fix text every finding of that detector shares). Capped at the top 10 qualifying findings per run. Falls back to the static why/fix text with no key configured, or if a call fails — an explanation is always additional context, never required to use the command. fix --apply with no key configured still offers to set one up as a fallback. securevibe config show lists what's stored (masked).

Honesty (read this):

• A "fixed" finding means our detector no longer flags it — not that the app is proven secure. Taint is intra-file, so always review the diff and run your tests.
• The AI-critical (ai-tool-hijack) clears only when the fix adds a guard our detector recognizes (a tool allowlist + argument-schema validation — what the LLM prompt asks for). The prompt-injection surface typically remains (input still reaches the model) and is reported as a residual to address with input isolation.
• The deterministic, offline fixers are verified end-to-end here. The AI-powered path (Groq or Claude) is wired and unit-tested (provider selection, response parsing, the truncation and verification gates) but has not been exercised against a real API key in this build — set GROQ_API_KEY or ANTHROPIC_API_KEY and review the diffs it proposes.
• fix is dry-run by default; --apply backs up originals to .securevibe-backup/<ts>/ first.
• fix --apply is interactive: it shows each verified diff and asks [y]es / [n]o / [a]ll / [q]uit before writing. A declined change is reported skipped, never fixed, and the after-score reflects only what you approved. In a non-interactive shell (CI, piped) it refuses to write unless --yes is given, so it never hangs and never writes unattended by surprise.

Dependency / CVE scanning (SCA)

securevibe deps reads package.json and requirements.txt, matches each pinned version against a local copy of the OSV advisory database, and reports known CVEs.

• A separate dimension. Dependency findings are reported on their own Dependencies line and never enter the code sub-scores, so the three code baselines stay byte-identical. A critical CVE still blocks deployment, and securevibe fix bumps the package to the lowest non vulnerable version while preserving your range prefix (^, ~, ==, ...).
• Offline first. A bundled seed (data/osv-seed.json) ships with the CLI, so deps works with no network. db update and update are the only commands that download anything (OSV advisory dumps, or the CLI's own next version, respectively). pr-comment is the only command that uploads anything, and only a findings summary already computed locally — never your code or package list. Most other commands also make one small background check: a newer version notice (the npm registry, cached a day, exempt under --json/--sarif/--staged) and the current daily usage limit (a public read only endpoint, cached an hour, exempt under --staged/--diff). Both are tiny GET requests for a version string or a number, and never send your code, your findings, or anything else about your project.
• Honest framing. A clean result reads "no known advisories as of <db date>", not "secure" — it means nothing matched the local database on that date, which is not a proof of safety.

What it detects

Classic (doc 03): SQL injection, command/code execution (RCE), XSS, IDOR / broken access control, insecure CORS, weak JWT, hardcoded secrets (provider keys, connection-string passwords, .env assignments).

AI-application security (doc 04 — the differentiator):

• Prompt-injection surface (untrusted input → LLM)
• Prompt injection → tool execution (model output drives an unvalidated fs/shell/DB/network sink)
• Over-privileged AI tools
• Missing AI execution firewall
• RAG / indirect-injection exposure
• Unauthenticated MCP servers

Findings are tagged with CWE / OWASP (incl. OWASP LLM Top 10) / MITRE ATT&CK & ATLAS, and severity is reachability-weighted (taint-confirmed flows rank highest), per doc 03/08.

How it maps to the architecture

| Source | Design doc | |---|---| | src/engine/parser.ts | tree-sitter parsing layer — doc 02 | | src/engine/taint.ts | intra-file taint — doc 03 | | src/engine/detectors/classic.ts | classic detectors — doc 03 | | src/engine/detectors/aisecurity.ts | AI-app security — doc 04 | | src/engine/detectors/secrets.ts | secret detection — doc 03 | | src/engine/score.ts | scoring + readiness — doc 08 | | src/engine/fix/* | autonomous fix loop (deterministic + LLM + verify) — doc 05 | | src/ui/* | report / protect / fix / attack-map / SARIF — docs 12/17 |

This is the buildable MVP slice. The cloud orchestration, multi-agent remediation (auto-PRs), sandboxed attack simulation, and runtime protection live in the design docs (05/07/09/13) and are the commercial layer.

Notes & limitations (honest MVP scope)

• Languages: JS / TS / TSX / Python (tree-sitter grammars). New grammars are additive.
• Taint is intra-file (doc 03 calls cross-file/symbolic out as the scale-up); the IDOR detector is a heuristic semantic check (confidence-scored accordingly).
• fix verifies against our own (intra-file) detector — it confirms the finding is no longer flagged, not that the app is provably secure. The deterministic fixers are non-breaking by construction; the verification gate is the safety net for LLM rewrites.
• fix applies changes locally + backs them up; it does not open PRs yet (that's doc 05's cloud engine). Detection favors precision but is not exhaustive.