C'è un momento, in ogni infrastruttura che cresce, in cui il controllo manuale smette di funzionare non perché sia sbagliato, ma perché è raro. Un penetration test fatto a mano è un evento: qualcuno se lo ricorda, blocca mezza giornata, lo fa bene una volta e poi passano mesi prima che ricapiti. Anansi nasce esattamente da questa osservazione — non come un tool più aggressivo o più sofisticato di un pentest classico, ma come la sua trasformazione in processo di fondo: economico abbastanza da girare ogni settimana, disciplinato abbastanza da non fare mai danni veri, onesto abbastanza da dire "sono entrato" solo quando è davvero entrato.
Il nome non è casuale. Tra i tanti riferimenti possibili nella cultura tech per un sistema di attacco automatizzato — Loki è il più ovvio — Giobi ha scelto il ragno-dio ingannatore dell'Africa occidentale proprio perché comunica una cosa diversa: piccolo, furtivo, trova le crepe. Non ostile. È una differenza che conta quando il nome del progetto può capitare di pronunciarlo davanti a un cliente che origlia: "Anansi" non fa scattare nessun allarme, "Loki" forse sì.
Il primo dato da tenere a mente, prima di ogni dettaglio tecnico, è che Anansi non è un tool generico configurabile su bersagli diversi: è costruito attorno a un unico elenco fisso di macchine — efesto, tanuki, avocado, emibrain, heimdall, b2 — che sono, letteralmente, tutta l'infrastruttura di Giobi e nient'altro. Questa lista, chiamata whitelist nel vocabolario del progetto, non è un parametro che si può sovrascrivere per un'occasione speciale. È la ragione stessa per cui il sistema ha il permesso di esistere.
Per questo la whitelist è imposta due volte, a due livelli indipendenti, e non una sola. Il primo livello è applicativo: ogni modulo di Anansi, prima di toccare un bersaglio, deve chiedere il permesso a un modulo dedicato — la Guardia — e si ferma se la risposta è no. Il secondo livello è di rete: il firewall di egress del container Docker in cui Anansi vive permette connessioni in uscita solo verso gli IP della whitelist, punto. Anche se un bug nel primo livello dovesse far passare qualcosa che non doveva passare, il secondo livello non lo lascerebbe uscire comunque. Un solo punto di controllo, per un sistema il cui unico compito è attaccare cose, è stato giudicato un rischio inaccettabile.
La whitelist stessa non si allarga da sola. Non c'è una modalità "espandi lo scope", non accetta bersagli dedotti da una scansione DNS o da una scoperta di rete. Aggiungere un host è un'azione deliberata, manuale, fatta da Giobi dentro la configurazione del container — mai un'inferenza automatica di Anansi su se stesso.
Client e infrastrutture di terzi sono fuori scope in modo permanente e categorico: non è un parametro da modificare, è l'intera ragione per cui il sistema può esistere.
Il secondo concetto attorno a cui tutto il design ruota è la distinzione tra un finding e un bucato — ed è una distinzione che nasce da un'esperienza già vissuta altrove nell'ecosistema di Giobi: la migrazione di tutte le notifiche via Discord verso abchat, fatta il giorno prima che questo progetto partisse, proprio per combattere l'alert fatigue di sistemi che gridano "allarme" ogni volta che uno scanner trova qualcosa che assomiglia a un problema.
Anansi può dire "sono entrato" — bucato, appunto — solo sotto una condizione molto stretta: un file canary è stato effettivamente depositato sull'host bersaglio, tramite un metodo di verifica classificato come sicuro, e la sua presenza è stata poi confermata rileggendolo. Tutto il resto — una vulnerabilità che uno scanner ha segnalato ma che non è mai stata verificata sul serio — resta un finding: viene loggato, senza urgenza, senza notifica push. Il sistema si è guadagnato il diritto di far vibrare il telefono di Giobi solo quando ha davvero, concretamente, messo piede dentro qualcosa.
Il file canary stesso merita una parola in più, perché il suo comportamento dopo la scoperta dice qualcosa sulla filosofia dell'intero progetto. È un file dal nome unico, generato per ogni run, con un timestamp e un hash che lo legano a quella specifica esecuzione di Anansi. Non porta nessun payload oltre alla prova stessa: non è una backdoor, non è un meccanismo di persistenza, non è una via per rientrare più tardi. E soprattutto, Anansi non lo ripulisce da solo dopo aver notificato. Il canary lasciato lì è esso stesso una prova per chi dovrà sistemare la vulnerabilità sottostante — rimuoverlo in silenzio indebolirebbe proprio il segnale "questo è davvero successo" che tutto il sistema esiste per produrre. Chi ripara il buco, rimuove anche il canary, come parte del fix.
Il terzo pilastro concettuale è cosa qualifica una verifica come sicura, ed è probabilmente il punto in cui il design si distingue di più da un semplice script di pentesting automatico. Una verifica conta come sicura solo se usa un meccanismo che non può, nemmeno nel caso peggiore, causare danni, perdita di dati o interruzione di servizio. Concretamente, per lo scanner nuclei questo significa restringersi solo ai template etichettati safe, o a categorie con comportamento di proof-of-concept non distruttivo e di sola lettura — confermare una local file inclusion leggendo un file noto e innocuo, confermare un bypass di autenticazione raggiungendo un endpoint che dovrebbe essere inaccessibile e leggendone i metadati non sensibili. Mai eseguire comandi arbitrari, mai scrivere qualcosa che non sia il canary stesso, mai toccare dati appartenenti a un utente vero o a un cliente.
Il punto cruciale, e la ragione per cui questo vincolo è descritto come architetturale e non come regola, è che il modulo che si occupa della verifica — chiamato Exploit Verifier — è costruito in modo da non essere capace di eseguire una verifica non sicura. Non è che gli viene chiesto di comportarsi bene: semplicemente non esiste, nel suo codice, un percorso che invochi un vero framework di exploitation come Metasploit, o un payload RCE su misura. Se un finding non può essere verificato in sicurezza con gli strumenti che Anansi ha a disposizione, resta un finding per sempre — anche se un penetration tester umano lo considererebbe ovviamente sfruttabile. È una scelta che rinuncia deliberatamente a un po' di copertura in cambio della garanzia assoluta che il sistema non possa fare danno.
Il quarto concetto chiave del vocabolario è il triage, ed è anche il punto in cui un modello linguistico entra nella pipeline — con un ruolo volutamente ristretto. Il triage è lo step in cui un LLM, ospitato sulla GPU on-prem di Giobi (qwen3.6, a costo marginale zero visto che l'hardware è già pagato e altrimenti resterebbe inattivo), guarda l'output grezzo e deterministico dello scanner e decide quali finding meritano un tentativo di verifica sicura, e in che ordine tentarli.
Ma il triage non tocca mai il bersaglio direttamente. Legge solo l'output dello scanner e decide "prova questo per primo" oppure "non vale la pena, logga e vai avanti". È un confine disegnato con cura: la parte rischiosa e costosa — parlare davvero con un target reale — resta interamente dentro moduli deterministici, dove il comportamento è prevedibile e verificabile passo per passo. Al giudizio del modello linguistico resta affidato solo qualcosa di puramente interno e a basso rischio: dare una priorità a una lista.
Il sistema si articola in quattro moduli deep, ciascuno con un'interfaccia stretta e una responsabilità precisa. La Guardia, già descritta, è la prima chiamata che ogni altro modulo fa prima di muoversi: non scopre nuovi bersagli, non accetta target dedotti dall'output di una scansione o da una risoluzione DNS, e non dipende da nient'altro — è lei stessa il punto di partenza di tutta la catena.
Lo Scanner è il modulo di ricognizione deterministica: prende un bersaglio già approvato dalla Guardia ed esegue nmap per la scoperta di porte e servizi, e nuclei per il matching di vulnerabilità e misconfigurazioni basato su firme. Normalizza l'output di entrambi gli strumenti in un unico formato di finding strutturati — host, porta, servizio, id del finding, severità, evidenza, tag del template nuclei. Non c'è nessun giudizio in questo passaggio: lo Scanner riporta tutto ciò che vede, senza filtrare. Decidere cosa conta è compito di un altro modulo, e tentare di verificare o sfruttare qualcosa è compito di un altro ancora.
Triage & Verifica è il modulo che unisce le due fasi già descritte — la classificazione fatta dall'LLM e il tentativo di verifica sicura fatto dall'Exploit Verifier — proprio perché il senso del triage è decidere su cosa vale la pena spendere un tentativo di verifica. L'LLM classifica i finding grezzi in base a quanto sembrano promettenti e quanto sembrano verificabili in sicurezza, e ne seleziona un piccolo numero per run — un budget deliberato, per tenere le esecuzioni brevi ed economiche, non un "verifica tutto quanto trovi". Per ciascun finding selezionato, l'Exploit Verifier tenta esclusivamente il metodo di verifica sicura appropriato per quella categoria, e deposita un canary solo se — e soltanto se — quella verifica sicura è effettivamente riuscita. Prima di ogni tentativo di verifica, la Guardia viene reinterrogata: un finding proveniente da una scansione ormai vecchia, su un host che nel frattempo è stato tolto dalla whitelist, non deve mai ricevere un tentativo di exploitation.
Il quarto modulo, Notifica, traduce i risultati di un run in comunicazione verso Giobi seguendo esattamente la distinzione tra finding e bucato. Ogni esecuzione produce sempre un post completo sul canale abchat anansi-redteam, indipendentemente dall'esito — così esiste sempre una traccia consultabile di cosa Anansi ha tentato e visto. Ma solo una violazione confermata, un canary effettivamente depositato, fa scattare la notifica push vera e propria sul telefono di Giobi. Una vulnerabilità trovata ma non verificabile in sicurezza, o che il triage ha giudicato non degna di un tentativo, viene loggata e basta: nessuna urgenza, nessun push. E non c'è fallback su Discord in nessuna circostanza — abchat resta l'unico canale, in coerenza con la decisione presa a livello di flotta il giorno prima che il progetto nascesse.
Attorno ai quattro moduli deep, due interfacce leggere fanno da colla. Uno scheduler n8n innesca un run completo — Scanner, poi Triage & Verifica, poi Notifica, in quell'ordine — su base settimanale, senza contenere alcuna logica propria oltre a "esegui la pipeline, una volta, su un timer": se la cadenza deve cambiare, è una modifica di configurazione del workflow n8n, non una modifica di codice dentro i moduli. Un entry point a riga di comando, anansi.py, permette a Giobi di lanciare un run manuale fuori dal calendario — per testare, o per controllare subito un host specifico — come un thin wrapper sulla stessa pipeline a quattro moduli che n8n chiama.
Il design elenca poi una manciata di vincoli descritti esplicitamente come non negoziabili, e vale la pena leggerli come sono scritti, non riassunti: la whitelist resta per sempre solo infrastruttura propria di Giobi, mai un cliente, mai un terzo, in nessuna configurazione — un ingaggio autorizzato separatamente avrebbe bisogno di un suo strumento e di una sua carta, completamente fuori da questo progetto. Nessuna verifica non sicura, nessun framework di exploitation, nessun payload distruttivo, mai — vincolo scritto nel codice dell'Exploit Verifier, non nella policy che gli viene chiesto di seguire. Nessuna raccolta di credenziali mantenuta, nessun movimento laterale, nessuna persistenza oltre il singolo file canary — un metodo di verifica sicura che richiedesse una di queste cose si squalificherebbe da solo come "sicuro", per definizione. L'isolamento è totale: un container Docker dedicato su efesto, con un proprio spazio di rete, egress filtrato solo verso gli IP della whitelist, e mai su Heimdall — perché la ragione d'essere di Heimdall è sopravvivere a un efesto che va giù, e deve restare fuori da qualunque cosa possa comprometterla. E infine, abchat come unico canale di notifica, senza fallback su Discord in nessuna circostanza, in coerenza con la migrazione a livello di flotta decisa il giorno prima.
Il design del 28 settembre 2026 lascia esplicitamente tre decisioni sospese, e le lascia sospese di proposito invece di forzare una risposta prematura. La prima riguarda l'elenco esatto dei tag e delle categorie di template nuclei che qualificano una verifica come sicura: serve un primo passaggio di revisione dei tag nativi di nuclei prima che il proof of concept faccia il suo primo run reale, un lavoro che Giobi e Claude faranno insieme prima che il PoC punti a qualcosa oltre efesto stesso. La seconda riguarda se aggiungere testssl e ffuf allo Scanner dopo che il PoC con nmap e nuclei avrà dimostrato di reggere, o se quella coppia di strumenti basterà già come segnale — una decisione che Giobi riprenderà dopo i primi run del PoC. La terza riguarda la policy di retention dei log del canale Village anansi-redteam — tenerli per sempre, o fare pulizia dopo N mesi — che non è urgente e verrà ripresa quando esisterà davvero uno storico di run da guardare.
Quello che il design non lascia aperto, invece, è il principio che tiene insieme tutto il resto: un sistema che ha il permesso di attaccare qualcosa deve essere costruito in modo da non poter, nemmeno per errore, attaccare la cosa sbagliata — e deve dire la verità su cosa ha davvero trovato, distinguendo con cura quello che ha solo notato da quello che ha effettivamente dimostrato.