Opengrep Studio · Code Audit Workbench

Find weaknesses before attackers do.

A local-first static code-audit workbench on top of Opengrep — import source, scan with rules, triage findings one by one, diff against baselines, deliver reports — your code never leaves your machine.

English · 简体中文 · 繁體中文 · 日本語 · 한국어 · Русский · Français

_{Triage view: baseline cards (new / fixed / remaining) · taint flow (source → propagation → sink) · highlighted hits · review verdicts}

Every codebase hides a few landmines: database passwords hardcoded in source, user input concatenated straight into SQL, debug endpoints left in after release, passwords still hashed with MD5. Static code analysis flags these problems early — without running your program and without uploading your code anywhere.

To be fair, AI is genuinely good at reading code — business-logic flaws, authorization risks, novel patterns no rule covers: it understands intent. But using an AI chat as a code audit runs into four walls:

• AI samples; an audit must be exhaustive — a 100k-line project won't fit into any context window; of 47 SQL-concatenation sites it may flag the 5 "obvious" ones, and you'll never know it skipped the other 42. A rule engine promises that every match gets reported — only then do you dare write "all problem patterns covered by these 812 rules have been checked" in your conclusions;
• A chat is one-shot; an audit needs a ledger — AI doesn't remember what it read last month: which findings are newly introduced, which got truly fixed, which you already ruled a false positive — everything starts over;
• "AI said so" doesn't count as evidence — client delivery demands reproducibility: source hashes, engine version, full command line, so anyone can rerun and get the same result; a chat log can be neither re-verified nor attributed;
• It can't keep up with commit frequency — a full read-through costs real tokens, and the bigger the project, the costlier and leakier it gets; a local engine takes seconds to minutes at zero marginal cost — that's what plugs into CI.

So this isn't either/or: rule engines provide the exhaustive safety net, AI adds semantic understanding — Semgrep itself ships AI assistance and every SAST vendor is wiring in LLMs; that's the road everyone is on. The engine behind Opengrep Studio is opengrep (the open-source community continuation of Semgrep OSS), and it scans professionally — but driving a full audit straight from its CLI still means four walls:

• The output is just JSON — what was matched and how severe it is, all read by eyeball from terminal output, with no workspace for triage;
• Rule messages are English-only — a hint like "tainted data flowing into eval" doesn't immediately tell everyone where the problem is or what to change;
• No way to tell whether a fix worked — rescan after fixing, and figuring out which findings are new and which are truly gone means manually diffing two JSON files;
• Nothing to hand to managers or clients — a risk report has to be assembled from JSON line by line, and it never looks professional.

Opengrep Studio completes this pipeline: drop in code → click scan → triage findings → export a report. The engine runs locally, and your code never leaves your machine. The analysis power belongs to the upstream engine — Studio turns scan output into a reviewable, comparable, verifiable, deliverable audit workflow. In the AI era this workflow is scarcer, not obsolete: AI dumps a big pile of findings on you in one go, and someone has to dedupe them, baseline them, track them across scans, and turn them into a report — AI produces findings; Studio manages them.

• Security consultants / appsec engineers doing code audits — client code can't go to third-party clouds (and shouldn't be pasted into online AI chat either); delivery means a reproducible audit report;
• Small teams without a commercial SAST budget — commercial audit platforms cost a small fortune per year; this is free, open source (MIT), and runs entirely locally;
• Anyone learning application security — 812 rules with messages in eight languages + a CWE knowledge base with fix advice + taint-flow visualization, and a rule lab that validates rules on the spot;
• Open-source authors — scan for hardcoded secrets and dangerous calls before publishing; it takes minutes.

Drag in a whole folder, upload ZIP / 7Z / RAR / TAR.GZ archives, or paste a Git repo URL for a shallow-clone import (respects .gitignore / .opengrepignore by default; toggle it off to dig hardcoded secrets out of .env). Language composition is analyzed automatically after upload.

Curated from opengrep-rules (rules carrying CWE / OWASP metadata first, upstream provenance links kept on every rule), covering 108 CWEs; all 812 rule messages are available in English, Simplified Chinese, Traditional Chinese, Japanese, Korean, Russian, French and German, plus a CWE knowledge base (108 entries with weakness notes and fix advice) in the same eight languages (the English UI falls back to Simplified Chinese). Custom rule packs support online editing, import/export, and quality checks.

All rule messages and CWE notes are also published as a static rules-encyclopedia site: https://lyfxxk.github.io/Opengrep-Studio/ — generated by server/scripts/build-rules-site.mjs and auto-deployed on every push to main.

Every finding links straight to file and line with the hit highlighted in red; taint findings show the full source → propagation → sink chain; review verdicts (confirmed / false positive / accepted) persist across scans by finding fingerprint, building the audit evidence chain.

Set a baseline scan and every later scan automatically classifies findings as new / fixed / remaining; the scan center can also pick any two completed scans for a dual-snapshot compare (even across projects): issue level matched by fingerprint, file level by snapshot content.

One click generates a paper-styled "Code Audit Test Report": overall verdict, risk distribution, top-hit rules, hot files, finding details, triage stats — print straight to PDF or download a single-file offline HTML; every report ships with a reproducibility manifest (source SHA-256, full engine command line, rule-file hashes). Report and manifest render in your interface language — English, Simplified Chinese, Traditional Chinese, Japanese, Korean, Russian, French or German.

Rule YAML on the left, positive and negative samples on the right, one click runs the real engine to check "does it hit, does it false-positive"; a verified rule saves together with its samples as a portable rule pack, ready for one-click regression afterwards. Drafts autosave; Ctrl+Enter runs.

Export SARIF 2.1.0 for GitHub Code Scanning / DefectDojo / SonarQube to consume; or import SARIF 2.x produced by other tools as a full scan, included in your baseline and report system.

Projects, cumulative scans, findings and rule packs at a glance; cross-project risk distribution, top-hit rules, engine status and per-project risk overview — auto-refreshes while a scan is running.

The dashboard "Engine status" card shows the actually installed version and where it came from; click "Check for updates" to compare against the latest upstream stable and upgrade in one click:

• The upgrade is an atomic swap: download → verify SHA-256 (from the GitHub release asset digest) → run opengrep --version to confirm → only then replace files; if any step fails, the old engine stays untouched
• Only the latest stable is offered (pre-releases are ignored); the button is disabled for users managing the engine themselves via OPENGREP_BIN
• Upgrading is disabled while a scan or the Rule Lab is running (Windows can't replace a running exe); the version-probe cache invalidates automatically after a successful upgrade
• The installed version is recorded in opengrep-tool/installed.json; re-running npm run setup:engine never downgrades an upgraded engine back to the version pinned in engines.json

UI at a glance (login & dashboard)

• Node.js ≥ 22.12 — built-in node:sqlite needs 22.5+, and Vite 8 in the frontend needs 22.12+; still no native dependencies
• The scan engine is downloaded and SHA-256-verified automatically (~50 MB), nothing to preinstall; Git is only needed for repo-clone import

Double-click 一键启动（Windows）.bat on Windows; on macOS / Linux run:

./一键启动（macOS／Linux）.sh

The script checks your Node version, installs dependencies, downloads the engine, and opens the browser. Frontend at http://localhost:1022, backend API at http://localhost:8787.

git clone https://github.com/Lyfxxk/Opengrep-Studio.git
cd Opengrep-Studio
npm run install:all   # root + server + code dependencies in one go
npm run setup:engine  # download opengrep v1.33.1 and verify SHA-256
npm run dev           # backend (:8787) + frontend (:1022) together

npm run docker:build
npm run docker:run    # = docker run --rm -p 8787:8787 -v ogstudio-data:/data opengrep-studio

The image ships with the engine and the built frontend — open http://localhost:8787 and you're in; data persists in the ogstudio-data volume.

One caveat on upgrades: a one-click upgrade writes to the container layer (/app/opengrep-tool), so it survives container restarts but is lost when the container is recreated (docker compose down && up), falling back to the version pinned in engines.json. For a long-term engine bump, change server/scripts/engines.json and rebuild the image.

Download OpengrepStudio.exe from the Releases page, put it in a writable folder (Desktop, Downloads — not Program Files) and double-click: the browser opens the console automatically. On first launch the runtime files are unpacked next to the exe along with a data/ folder. The scan engine is not bundled — install it in one click from the dashboard "Engine status" card (~50 MB, SHA-256-verified) or point OPENGREP_BIN at an existing engine. No Node.js installation is required. If Windows SmartScreen warns about an unknown publisher, click "More info → Run anyway" (the binary is not code-signed; that's expected). Only the Git-clone import needs a local Git installation.

Default login: admin / 123456 (see Security Model). Suggested flow:

1. Scan config — pick the rule packs to enable (optionally with exclude/include paths and engine args)
2. Create a project and bind that config — or skip binding: a protected fallback config (all enabled built-in rule packs, cannot be deleted) is bound automatically on the first scan
3. Import source (drag a folder / upload an archive / Git clone)
4. Run a scan, then triage findings one by one
5. Set a baseline, rescan, and watch new / fixed / remaining; when it's time to deliver, generate the test report

Want to see it before touching your own code? npm run seed seeds three demo projects (with baseline diffs and review records) in one go.

flowchart LR
    U["Browser UI<br/>React 19 + Vite"] -->|"REST /api"| S["Express backend<br/>:8787"]
    S -->|"child process<br/>--json --dataflow-traces"| E["opengrep engine<br/>v1.33.1"]
    S --> DB[("SQLite<br/>server/data/studio.db")]
    S --> FS[("immutable source snapshots<br/>data/workspace/")]

• Single-process deployment: the backend also serves the built frontend (in production, port 8787 is all you need); binds 127.0.0.1 only, by default
• Every scan runs against an immutable source snapshot; the snapshot hash and the full command line are archived, so every report is reproducible
• SQLite stores projects / scans / findings / reviews / configs — no external service dependencies; all data lives in server/data/
• Up to 2 scans run concurrently (extra ones are queued automatically) to make use of local resources; the Rule Lab and scans are mutually exclusive

npm test             # backend unit tests
npm run test-packs   # rule pack structure + bundled samples
npm run e2e          # HTTP end-to-end against a running backend (real engine)
npm run e2e:ui       # browser end-to-end (Playwright; builds the frontend, boots an isolated backend on :8799)
npm run e2e:ui:fast  # browser end-to-end without the engine-dependent scan case

Browser tests live in code/e2e/ and write to code/e2e/.tmp/, so they never touch your server/data/. CI runs both suites against the real engine.

Honest disclosure — please read:

• Local single-machine tool: binds 127.0.0.1 only by default; code and results never leave the machine, no telemetry
• The login gate is a frontend-only guard against mis-clicks (fixed account admin / 123456); the backend API has no authentication — do not expose the service to the public internet; if you truly need it on the LAN, set HOST yourself and add access control
• Docker mode defaults to HOST=0.0.0.0; use it only inside an intranet / behind protection
• Upload & unzip are hardened against Zip-Slip / symlinks / size & file-count bombs; Git clone is https-only with credential interaction disabled

• Localization of all 812 rule messages + CWE knowledge base in eight languages (English / Simplified Chinese / Traditional Chinese / Japanese / Korean / Russian / French / German)
• Baseline & two-snapshot diffing, review evidence chain
• SARIF 2.1.0 import/export, reproducibility manifest
• Rule Lab & portable rule packs with sample regression
• Docker image & one-click launch on 3 platforms
• Engine check-update & one-click upgrade (multi-channel download fallback)
• UI i18n (English / Simplified Chinese / Traditional Chinese / Japanese / Korean / Russian / French / German)
• Scan queue & parallel scheduling
• Rule-pack import from URL & community index
• GitHub Action workflow template (scan in CI, upload SARIF back)
• Customizable report templates (branding / header & footer)

• opengrep/opengrep — the scan engine (LGPL-2.1); this repo does not vendor its binary, it is downloaded and verified by script
• opengrep/opengrep-rules — source of the built-in rules; thanks to all upstream rule authors
• shadcn/ui / Radix UI / Tailwind CSS / CodeMirror / Vite / React — all the good stuff the interface is made of

This repository's code is released under MIT.

Two third-party license notes:

• The scan engine: opengrep is released under LGPL-2.1; this repo contains no engine binary — npm run setup:engine downloads it from the official Releases and verifies it by SHA-256
• Built-in rules: curated from opengrep-rules (LGPL 2.1 + Commons Clause) — free to use and redistribute with attribution kept, but the rules themselves must not be sold as a paid product