Sandyaa — open-source autonomous code auditor that proves bugs with working exploit PoCs

What to do

The summary tells you what Sandyaa is but not how to run it. Install and invoke:

git clone https://github.com/securelayer7/sandyaa.git
cd sandyaa
npm install
npm run build
npm link      # installs the `sandyaa` command globally

# Local directory
sandyaa /path/to/project
# Remote git URL (cloned into a temp directory)
sandyaa https://github.com/user/repo
# Custom config
sandyaa -c ./my-config.yaml /path/to/project
# Ignore an existing checkpoint and start over
sandyaa --fresh /path/to/project

Requires Node.js 18+, Claude Code installed and logged in, and git (auto-installed on macOS/Linux if missing). Findings land in findings/ under the target directory, one folder per bug containing analysis.md, poc.py, SETUP.md, and evidence.json, plus a top-level SUMMARY.md.

Configuration

Sandyaa reads .sandyaa/config.yaml from the current working directory. The knobs an engineer will actually tune:

analysis:
  chunk_size: 15
  depth: maximum
detection:
  min_severity: high
  exploitability_threshold: 0.7
output:
  generate_pocs: true
  validate_pocs: true

exploitability_threshold and min_severity gate how much noise you get; validate_pocs toggles whether generated PoCs are actually executed to confirm findings. Runs are checkpointed and resumable — --fresh discards an existing checkpoint.

What it looks for

The summary names the recursive-pass architecture but not the bug classes. Detectors span memory safety (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 (ECB, hardcoded keys, bad randomness), concurrency races, integer issues, and unsafe APIs (deserialization, XXE, prototype pollution). Which run on a given chunk is decided by the planner, not fixed.

The RLM approach is grounded in arxiv.org/html/2512.24601v1.

Caveats

Alpha-stage; the page explicitly says to "expect rough edges and false positives." The GEMINI_API_KEY env var, if set, is used only to resolve the latest Gemini model tiers at startup — it is not required, and without it static model defaults apply. Only run it against code you own or are authorized to test.