Repo del giorno: Sandyaa, l'auditor di sicurezza che non si ferma finché non prova il bug

🔍 Cos'è Sandyaa: dalla lista di sospetti alla prova

Sandyaa è un CLI Node.js che punti verso una directory locale o un URL Git: da lì in avanti gira end-to-end, senza pause né conferme, finché l'audit non è completo. Costruisce un contesto attraverso i file per capire come le parti del codice interagiscono, individua vulnerabilità e — per ciascuna — scrive un proof-of-concept in Python pensato per dimostrarla, non solo descriverla. Al termine, ogni bug confermato finisce in una cartella dedicata sotto `findings/`, con un file di analisi, il PoC, una guida di setup e un file `evidence.json` che collega ogni affermazione a un file e una riga precisi.

Il progetto è mantenuto da SecureLayer7, che dichiara di aver già usato Sandyaa per scovare diversi zero-day nelle proprie attività di ricerca. È distribuito sotto licenza MIT, testato attivamente su macOS, atteso funzionare su Linux (non ancora validato) e disponibile su Windows solo tramite WSL2, dato che alcuni comandi shell usati internamente (come `which claude`) sono specifici di Unix. Lo stato dichiarato dal progetto è alpha: gli autori stessi avvertono di aspettarsi margini grezzi e falsi positivi.

repo       securelayer7/sandyaa
linguaggio TypeScript 98.4% · JavaScript 1.6% · licenza MIT
autore     SecureLayer7 (offensive security, Pune · Austin)
cosa       audit di sicurezza autonomo via Claude Code, PoC inclusi
richiede   Node.js 18+, git, Claude Code già autenticato
stelle     ~242 · 55 fork (fotografia al 22 luglio 2026) · stato alpha

⚙️ Come funziona: Recursive Language Models al posto del context finito

Il primo elemento che distingue Sandyaa dagli altri scanner basati su LLM che ho visto è l'assenza di una chiave API: il tool si appoggia alla sessione Claude Code già autenticata sulla tua macchina. Se paghi già per Claude Code, Sandyaa riusa quella stessa CLI — niente da configurare, nessuna sorpresa in fattura. Il supporto opzionale per Gemini funziona allo stesso modo, riusando il login della CLI `gemini` se presente nel `PATH`; solo chi preferisce la REST API deve esportare una `GEMINI_API_KEY`, e solo per risolvere la versione del modello all'avvio.

Il secondo elemento è architetturale: invece di forzare l'intero codebase in un'unica finestra di contesto, Sandyaa fa scrivere al modello un REPL Python che filtra con regex, suddivide i file in chunk e genera query verso sotto-istanze dell'LLM, aggregando i risultati in codice invece che in linguaggio naturale. È l'approccio dei Recursive Language Models (RLM), descritto nel paper a cui il progetto fa riferimento (arxiv.org/html/2512.24601v1): la dimensione del chunk si adatta dinamicamente alla densità del codice e al budget di token, e un sistema di checkpoint automatico permette di riprendere un audit interrotto senza ripartire da zero.

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

sandyaa /percorso/al/progetto        # directory locale
sandyaa https://github.com/utente/repo   # URL Git, clonato in tmp
sandyaa --fresh /percorso/al/progetto     # ignora il checkpoint esistente

🧪 Otto passate ricorsive, poi la prova prima della segnalazione

Il cuore del progetto sono le otto passate ricorsive che rileggono lo stesso codice più volte per raffinare i risultati: tracciamento delle catene di chiamata, espansione del data-flow, auto-verifica, concatenazione delle vulnerabilità, raffinamento del PoC, rilevamento di contraddizioni, validazione delle assunzioni e prova di sfruttabilità. Un attacker-control analyzer separato scarta le segnalazioni che non sono raggiungibili da input non fidato, il passaggio che più riduce il rumore da problemi puramente teorici. Il CTO di SecureLayer7, Sandeep Kamble, ha raccontato a Help Net Security che il team ha continuato a stringere questa pipeline di verifica finché il tasso di falsi positivi non è sceso abbastanza da rendere più produttivo leggere l'output di Sandyaa che il codice a freddo.

Cosa cerca, in concreto: bug di memoria (use-after-free, buffer overflow, type confusion, double-free), bug di logica (bypass di autenticazione, TOCTOU, errori nella state machine), injection (SQL, comandi, XSS, SSRF, path traversal), uso scorretto della crittografia, race condition di concorrenza, problemi sugli interi e API non sicure come deserializzazione, XXE e prototype pollution. L'esecuzione del PoC generato — utile per confermare che l'exploit funziona davvero — è disattivata di default: va abilitata esplicitamente, ed è comunque preceduta dal filtro attacker-control, così non si generano PoC per percorsi che non sarebbero comunque raggiungibili.

🏢 Perché è interessante, per sviluppatori e PMI

Per chi sviluppa, il segnale più concreto sono due bug reali già divulgati pubblicamente nel progetto Spring AI: una SQL injection in `MariaDBFilterExpressionConverter` e una JSONPath injection in `PgVectorStore AbstractFilterExpressionConverter`. Non sono demo costruite ad arte, sono CVE su un progetto che molte aziende usano davvero per integrare LLM nei propri backend Java — un test più severo di qualunque benchmark sintetico. Il fatto che il tool giri sulla stessa CLI di Claude Code che magari già usi per scrivere codice significa anche che l'audit di sicurezza smette di essere uno strumento separato da configurare e diventa un comando in più nello stesso ambiente.

Per una PMI senza un team di sicurezza offensiva dedicato, Sandyaa abbassa il costo di una prima verifica seria su codice proprietario prima di una release o di un audit esterno: punti il CLI su un repository che possiedi o sei autorizzato a testare, e ottieni segnalazioni corredate di prova invece di un elenco generico da smistare a mano. Resta comunque uno strumento da usare con responsabilità: il README stesso è esplicito nel dire di eseguirlo solo su codice di cui hai il possesso o l'autorizzazione a testare, non su repository di terzi senza permesso.

⚠️ Limiti e cautele prima di usarlo

Il progetto è dichiaratamente alpha e recente: pubblicato ad aprile 2026, ha oggi circa 242 stelle e nessuna release pubblicata su GitHub — vive di commit diretti sul branch principale. È il tipo di segnale che vale la pena tenere a mente prima di affidargli un audit critico: il codice di supporto (parsing, chunking, aggregazione) è giovane quanto la sua adozione, non quanto la solidità di Claude su cui si appoggia.

Il supporto per Windows nativo non c'è: Sandyaa lancia comandi Unix-only e invoca la CLI Claude senza un wrapper di shell, quindi fallisce fuori da WSL2. macOS è l'unica piattaforma testata attivamente; Linux è atteso funzionare ma non è ancora stato validato dal team. E anche con l'esecuzione dei PoC disattivata di default, generare comunque codice di exploit per un codebase — anche solo come testo, senza eseguirlo — merita lo stesso livello di attenzione che si darebbe a qualunque altro output generato da un LLM su un progetto sensibile.

• Stato alpha: pubblicato ad aprile 2026, nessuna release GitHub, margini grezzi attesi dagli stessi autori.
• Windows nativo non supportato: richiede WSL2; solo macOS è testato attivamente, Linux non ancora validato.
• Esecuzione PoC opt-in: disattivata di default, ma va attivata con consapevolezza anche quando lo è.
• Solo su codice autorizzato: il README chiede esplicitamente di usarlo su repository posseduti o di cui hai il permesso di test.

✅ Da dove partire

Il percorso che suggerisco: installa Sandyaa, punta il CLI su un progetto non critico di cui hai il pieno possesso, lascia girare l'audit con la configurazione di default (`chunk_size: 15`, `depth: maximum`, `min_severity: high`) e leggi prima l'`analysis.md` di ogni finding in `findings/` senza abilitare la generazione dei PoC. Solo dopo aver verificato manualmente un paio di segnalazioni ha senso alzare l'asticella — validare i PoC, abbassare la soglia di severità, o puntarlo su un repository più grande sfruttando il resume automatico via checkpoint.

Nel quadro più ampio, Sandyaa è un caso di studio su dove sta andando la sicurezza del codice assistita da LLM: non più «trova quanti più problemi possibile» ma «prova che ognuno è reale prima di segnalarlo». È lo stesso spostamento che si vede in altri strumenti agentici recenti — meno output da smistare, più affermazioni verificabili — e vale la pena osservarlo anche se oggi il progetto resta, nelle parole dei suoi stessi autori, alpha.

Altri articoli del blog