Repo of the day: Sandyaa, the security auditor that won't stop until it proves the bug

🔍 What Sandyaa is: from a list of suspects to proof

Sandyaa is a Node.js CLI you point at a local directory or a Git URL: from there it runs end to end, with no pauses or confirmations, until the audit is done. It builds context across files to understand how the pieces of code interact, identifies vulnerabilities, and — for each one — writes a Python proof-of-concept meant to demonstrate it, not just describe it. Once done, every confirmed bug lands in its own folder under `findings/`, with an analysis write-up, the PoC, a setup guide, and an `evidence.json` file linking every claim back to an exact file and line.

The project is maintained by SecureLayer7, which says it has already used Sandyaa to surface several zero-days in its own research. It ships under the MIT license, is actively tested on macOS, expected to work on Linux (not yet validated), and only available on Windows through WSL2, since some internal shell commands (like `which claude`) are Unix-specific. The project's own stated status is alpha: the authors themselves warn to expect rough edges and false positives.

repo       securelayer7/sandyaa
language   TypeScript 98.4% · JavaScript 1.6% · license MIT
author     SecureLayer7 (offensive security, Pune · Austin)
what       autonomous security audit via Claude Code, PoCs included
requires   Node.js 18+, git, an already logged-in Claude Code
stars      ~242 · 55 forks (snapshot as of July 22, 2026) · alpha status

⚙️ How it works: Recursive Language Models instead of a fixed context window

The first thing that sets Sandyaa apart from other LLM-based scanners I've looked at is that it needs no API key: the tool piggybacks on the Claude Code session already authenticated on your machine. If you already pay for Claude Code, Sandyaa just reuses that same CLI — nothing to configure, no billing surprises. Optional Gemini support works the same way, reusing the `gemini` CLI's own login if it's on your `PATH`; only those who prefer the REST API need to export a `GEMINI_API_KEY`, and only to resolve the model version at startup.

The second thing is architectural: instead of forcing the entire codebase into a single context window, Sandyaa has the model write a Python REPL that filters with regex, chunks files, and spawns queries to sub-instances of the LLM, aggregating results in code rather than in natural language. This is the Recursive Language Models (RLM) approach, described in the paper the project references (arxiv.org/html/2512.24601v1): chunk size adapts dynamically to code density and token budget, and an automatic checkpointing system lets an interrupted audit resume without starting over.

git clone https://github.com/securelayer7/sandyaa.git
cd sandyaa && npm install && npm run build && npm link

sandyaa /path/to/project              # local directory
sandyaa https://github.com/user/repo   # Git URL, cloned into a temp dir
sandyaa --fresh /path/to/project        # ignore an existing checkpoint

🧪 Eight recursive passes, then proof before it's ever reported

The heart of the project is its eight recursive passes, which revisit the same code multiple times to refine results: call-chain tracing, data-flow expansion, self-verification, vulnerability chaining, PoC refinement, contradiction detection, assumption validation, and exploitability proof. A separate attacker-control analyzer drops findings that aren't reachable from untrusted input — the step that cuts the most noise from purely theoretical issues. SecureLayer7's CTO, Sandeep Kamble, told Help Net Security that the team kept tightening this verification pipeline until the false-positive rate dropped low enough that reading Sandyaa's output was a better use of time than reading the code cold.

What it actually looks for: memory bugs (use-after-free, buffer overflow, type confusion, double-free), logic bugs (auth bypass, TOCTOU, state machine errors), injection (SQL, command, XSS, SSRF, path traversal), crypto misuse, concurrency races, integer issues, and unsafe APIs like deserialization, XXE, and prototype pollution. Executing the generated PoC — useful to confirm the exploit actually works — is off by default: it has to be enabled explicitly, and is still preceded by the attacker-control filter, so no PoCs get built for paths that weren't reachable anyway.

🏢 Why it matters, for developers and SMBs

For developers, the strongest signal is two real, publicly disclosed bugs in the Spring AI project: a SQL injection in `MariaDBFilterExpressionConverter` and a JSONPath injection in `PgVectorStore AbstractFilterExpressionConverter`. These aren't staged demos — they're CVEs in a project many companies actually use to wire LLMs into their Java backends, a tougher test than any synthetic benchmark. The fact that the tool runs on the same Claude Code CLI you might already use to write code also means security auditing stops being a separate tool to configure and becomes one more command in the same environment.

For an SMB without a dedicated offensive-security team, Sandyaa lowers the cost of a first serious pass over proprietary code ahead of a release or an external audit: point the CLI at a repository you own or are authorized to test, and get findings backed by proof instead of a generic list to sort through by hand. It's still a tool to use responsibly: the README itself is explicit that it should only run on code you own or are authorized to test, never on someone else's repository without permission.

⚠️ Limits and caveats before using it

The project is openly alpha and recent: released in April 2026, it currently has around 242 stars and no GitHub release published — it lives on direct commits to the main branch. That's worth keeping in mind before handing it a critical audit: the supporting code (parsing, chunking, aggregation) is as young as its adoption, not as battle-tested as the Claude models it runs on.

Native Windows support doesn't exist: Sandyaa runs Unix-only commands and invokes the Claude CLI without a shell wrapper, so it fails outside WSL2. macOS is the only actively tested platform; Linux is expected to work but hasn't been validated by the team yet. And even with PoC execution off by default, generating exploit code for a codebase at all — even just as text, without running it — deserves the same level of care you'd give any other LLM-generated output touching a sensitive project.

• Alpha status: released in April 2026, no GitHub release, rough edges expected by the authors themselves.
• No native Windows support: requires WSL2; only macOS is actively tested, Linux not yet validated.
• PoC execution is opt-in: off by default, but still needs to be enabled with awareness even when it is.
• Authorized code only: the README explicitly asks that it be used on repositories you own or are permitted to test.

✅ Where to start

The path I'd suggest: install Sandyaa, point the CLI at a non-critical project you fully own, let the audit run with the default config (`chunk_size: 15`, `depth: maximum`, `min_severity: high`), and read the `analysis.md` of each finding under `findings/` first, without enabling PoC generation. Only after manually verifying a couple of findings does it make sense to raise the stakes — validating PoCs, lowering the severity threshold, or pointing it at a larger repository and leaning on the automatic checkpoint resume.

Zooming out, Sandyaa is a useful case study in where LLM-assisted code security is headed: no longer "find as many issues as possible" but "prove each one is real before reporting it." It's the same shift showing up in other recent agentic tools — less output to sort through, more verifiable claims — and it's worth watching even though, in its own authors' words, the project remains alpha today.

More articles from the blog