Catching the secret before the commit: code scanning that never leaves the machine
The most common leak at a small business isn't a sophisticated attack — it's a password or API key forgotten in the code, pushed to git, and from there out to the whole world. We wanted to catch it the moment it's written, not two weeks after the breach. But there was one non-negotiable condition.
The condition: the code never leaves the machine
Many scanning tools upload your source code to their cloud in order to analyze it. For an Israeli business — with its code, its secrets, and sometimes customer data — that's exactly the problem we set out to solve, not to create. So the first rule was: the scan runs 100% on the developer's machine. The code and the secret values never reach our cloud; only a sanitized finding (rule ID, severity, file:line, a masked fingerprint of the secret — never the secret itself) is sent up to the organizational dashboard.
The core decision: one engine, not ten plugins
We could have built a separate plugin for each editor — one for VSCode, one for Cursor, one for JetBrains, and more. That's a trap: ten codebases to maintain, logic that fragments, and different bugs everywhere. Instead we built a single engine — one static executable (Rust) — that contains all the logic, and every "surface" is a thin wrapper around it:
- CLI → git hooks (pre-commit / pre-push) and CI
- LSP → red squiggles in the editor as you type (VSCode/Cursor/JetBrains)
- MCP + hook → AI agents (like Claude Code) — blocks a secret before it's written to disk
The logic is written once. The exact same rule that protects your commit also protects your CI and whatever an AI agent tries to write.
What it catches
The core combines gitleaks-style secret detection (a catalog of regular expressions) with a Shannon entropy metric — to distinguish a random string that looks like a real key from an innocent placeholder like "your-api-key-here". AWS keys, GitHub tokens, private keys, passwords inside connection strings, and more — all flagged with a fix in plain language and a CWE reference. Coming next: deep vulnerability scanning (Semgrep) and dependency scanning (CVE).
The angle nobody talks about: AI agents that write code
More and more code today is written by AI agents. They're excellent — but they can also "hallucinate" an insecure pattern or embed a secret by mistake. Our engine sits as a hook on the agent: when the agent tries to write a secret or a critical vulnerability, the hook refuses — before the content ever touches the disk. We turned a new risk (AI writing code) into a defensive gate.
How we tested it
We ran the tool on our own codebase. Two things mattered: that it catches real secrets (we tested with synthetic samples — AWS, Stripe, connection strings — and all were caught), and that it doesn't make noise on valid code (the placeholders were correctly rejected). The result on our own code: 100/100 — zero embedded secrets, because they all live in the right place (a secret manager), exactly as we recommend to our customers.
How we keep improving it — continuous quality control
The tool runs itself on every code change we make (a CI gate), including dependency scanning (SCA) that flags when a library we depend on becomes vulnerable. Next steps: the editor surface (LSP) and the agent surface (MCP) for every customer, a diff engine that alerts only on what's new (not old noise), and an optional AI insight that explains each finding. Same philosophy: one tool, local, transparent — the knowledge is exposed, the code stays with you.
This article describes the approach at a principle level. It contains no sensitive detection signatures, keys, or details that would help an attacker — on the contrary, the transparency of the model is a point of strength.
← All articles