Annunciamo ExploitHunter.app

Un banco di lavoro open source per la sicurezza che riunisce ambito, approvazioni, strumenti ed evidenze in un unico progetto.

Indice

• Il ciclo è volutamente noioso
• Il prodotto è l’evidenza
• Otto modelli, un solo target
• Il benchmark ha scoperto il benchmark
• Instradare i modelli in base al task
• Dove si colloca accanto a deepsec, VulnHunter e agli altri
• Eseguilo localmente. Usalo responsabilmente.
• Cosa succede dopo

Gli strumenti di sicurezza hanno un problema di burocrazia.

Trovano una riga sospetta, ti consegnano un badge di gravità e poi ti lasciano discretamente dimostrare se la cosa conta davvero. Il finding è «high». L’evidenza è tre grep con addosso un trench.

Gli agenti AI possono accorciare questo flusso di lavoro. Possono anche trasformare un’istruzione vaga, un browser e una shell in una pila molto più rapida di attività non verificate.

ExploitHunter.app riparte da dove lo scanner si ferma. Dagli un target autorizzato e un obiettivo. L’agente mappa le route raggiungibili, controlla un browser, esegue strumenti da terminale e di sicurezza, verifica un’ipotesi e salva le risposte, gli screenshot e i transcript che supportano il finding. Poi trasforma quell’evidenza in un report con citazioni.

È open source e local-first. Puoi passare da modelli ospitati a modelli locali senza distribuire target, approvazioni, cronologia ed evidenza su progetti separati.

Non è uno scanner con una chatbot incollata sopra. È un workbench che ricorda cosa ha provato l’agente e cosa è tornato indietro.

Parlare di sicurezza costa poco. La parte utile è eseguire il controllo autorizzato, conservare la prova e indicarti la prossima mossa.

Il ciclo è volutamente noioso

Un progetto ExploitHunter segue ogni volta la stessa sequenza:

authorize target → plan → request approval → probe → save evidence → prioritize → report

L’ordine conta perché l’agente ha una portata reale.

L’autorizzazione del target è stato del progetto, non contesto conversazionale. Non vive in un messaggio della chat dove «certo, procedi» può assumere nuovi significati tre turni dopo. Le scansioni attive, i test delle credenziali, i comandi shell e le scritture su file passano tutti da un gate di approvazione. Le approvazioni dei comandi ad alto impatto sono vincolate a un’intenzione, a un progetto e a un target. Per impostazione predefinita sono monouso.

I gate di approvazione non sono le note in piccolo sotto la presentazione del prodotto. Sono ciò che rende ragionevole collegare un agente a strumenti reali. Limitano la deriva dell’ambito, rendono le revisioni meno dipendenti dalla memoria e danno al team qualcosa di meglio di «l’ha detto l’AI».

Il prodotto è l’evidenza

La risposta finale del modello non è l’unità durevole del lavoro di sicurezza. Lo è l’evidenza.

Chiudi l’app. Cambia modello. Torna domani. L’indagine ha ancora una memoria.

ExploitHunter conserva la cronologia di progetti e thread, ma il record durevole è la pipeline dell’evidenza: cosa è stato provato, con quale approvazione, contro quale target autorizzato e quale risultato è arrivato. La sonda, la risposta, il transcript dei comandi, lo screenshot e l’artefatto di supporto vengono archiviati insieme al finding. Il report cita il lavoro invece di parafrasare il paragrafo conclusivo del modello.

I finding possono poi alimentare il tracking delle remediation, l’analisi delle varianti, il lavoro sugli attack path e un report che il revisore può verificare riga per riga.

C’è anche un vantaggio egoistico: il debugging smette di essere mistico. Quando l’agente si lascia sfuggire qualcosa, usa troppo gli strumenti, si inventa una conclusione o non salva un artefatto, il fallimento è visibile nel record. Correggiamo il prodotto invece di discutere con lo screenshot di una bolla di chat.

Otto modelli, un target

Poiché ogni esecuzione lascia un record, confrontare i modelli smette di essere un esercizio di impressioni.

Ho assegnato a otto route di modello lo stesso difficile task su Juice Shop e le ho fatte passare attraverso il percorso applicativo reale di ExploitHunter. Stesso target. Stessi strumenti. Stesso contratto dell’evidenza. Se un’esecuzione non riusciva a dimostrare quale modello fosse stato eseguito o a conservarne l’output, non entrava nella tabella. I benchmark possono anche apprezzare l’ambiguità. Le fatture, di solito, no.

| Route del modello | Giudice | Costo | Durata | Chiamate agli strumenti | Lettura | |---|---:|---:|---:|---:|---| | Kimi K3 | 10.0/10 | $0.220184 | 223.4s | 8.0 | Qualità più alta al prezzo più basso tra i due punteggi perfetti | | Claude Opus 4.8 | 10.0/10 | $1.633301 | 115.9s | 8.0 | Stessa qualità di Kimi, quasi il doppio della velocità, costo 7,4× superiore | | DeepSeek V4 Flash | 9.33/10 | $0.058695 | 395.5s | 32.0 | Miglior punteggio tra le due route perfette | | GPT-5.6 Luna | 8.67/10 | $0.016304 | 52.2s | 3.3 | Miglior risultato in termini di costo e velocità | | GPT-5.6 Terra | 8.0/10 | $0.124046 | 107.5s | 6.0 | Supera Sol per prezzo e velocità a parità di punteggio | | GPT-5.6 Sol | 8.0/10 | $0.368514 | 229.6s | 10.0 | Capace, ma in questo campione Terra lo domina | | Qwen 3.6 Flash | 5.5/10 | $0.085678 | 96.9s | 16.5 | L’impostazione più economica migliora l’efficienza, ma la qualità resta indietro | | GPT OSS 120B | 5.0/10 | $0.062529 | 36.6s | 4.3 | Rapido ed economico, ma troppo volatile per essere la route predefinita |

Leggetela come una policy di routing, non come un podio.

Luna è il punto di partenza efficiente. DeepSeek compra altri due terzi di punto del giudice a circa 3,6× il costo, 7,6× la durata e 9,6× le chiamate agli strumenti. Kimi arriva a 10/10 senza il conto di Opus. Opus raggiunge lo stesso punteggio circa 108 secondi prima, spendendo altri $1,41. GPT OSS resta un esperimento supervisionato, mentre Terra offre un caso più solido di Sol per questo task.

Solo Luna, DeepSeek e Kimi si trovano su quella frontiera. Le altre route non sono inutili. Hanno bisogno di una motivazione che vada oltre punteggio grezzo e costo: Opus compra velocità, Terra soddisfa un vincolo sulla famiglia del modello senza il conto di Sol e GPT OSS è abbastanza economico da poter essere esplorato sotto supervisione.

La versione estesa, con metodologia, budget degli strumenti, controlli negativi e i modi in cui i modelli si mettono in imbarazzo quando il transcript dei comandi contiene già la risposta, si trova in Gli agenti di sicurezza hanno bisogno di router di modelli, non di classifiche.

Il benchmark ha scoperto il benchmark

Il risultato più importante non è stata una vittoria di un modello. È stato un errore dello scorer.

Il primo report sul recupero dell’archivio ha dato a Kimi 5/10 e a GLM 9/10. Il task era riuscito. Entrambi gli agenti avevano recuperato harbor-lantern-47 e un controllo indipendente eseguito sull’host con unzip -t -P ha dimostrato che quella password funzionava, mentre le alternative no.

Il giudice aveva applicato un audit raw-Cybench degli strumenti vietati a un task nativo di ExploitHunter in cui era richiesto scrivere le evidenze. Ha penalizzato esattamente il comportamento richiesto dall’harness. Stesso output del modello. Stessa traccia salvata. Rubrica sbagliata.

Rimosso l’audit irrilevante, Kimi passa da 5/10 a 10/10. GLM resta a 9/10. I punteggi corretti sono stati riscritti nelle tracce Langfuse originali come browser-e2e-llm-judge-corrected, e un controllo API in sola lettura del 17 luglio ha confermato entrambi i valori sugli ID delle tracce persistite.

Questo scarto di cinque punti spiega perché ExploitHunter conserva tracce, evidenze, versioni dello scorer, costi, token, budget degli strumenti e fallimenti dell’harness, invece di appiattire una valutazione in un unico numero eroico. Se il benchmark non sa mostrare il proprio lavoro, è solo un altro modello che fa un’affermazione sicura di sé.

Instradare i modelli in base al task

ExploitHunter non si limita a supportare una lunga lista di provider di modelli. Li tratta come una panchina.

Una fase di ricognizione, un controllo di exploit, un flusso browser, la sintesi delle evidenze e una proposta di remediation sono tutti lavori di sicurezza. Non sono lo stesso task per un modello.

VulnHunter di Capital One fa una scelta coerente a favore di un flusso di analisi del codice ottimizzato per Claude/Claude Code. ExploitHunter fa una scelta diversa: mantenere stabili l’ambito del progetto, le approvazioni, gli strumenti e le evidenze, mentre il percorso del modello cambia in base al lavoro da svolgere.

Un’ampia ricognizione web può premiare un modello economico e veloce con un budget ristretto per gli strumenti. Un laboratorio locale vincolato può favorire la privacy e l’inferenza offline. Una validazione difficile o il report finale possono giustificare un percorso frontier più lento. ExploitHunter sposta il lavoro tra queste corsie mentre target, cronologia, approvazioni, strumenti e artefatti restano al loro posto.

Il modello giusto è una decisione di instradamento, non un logo nella schermata delle impostazioni.

ExploitHunter supporta provider hosted oltre a Ollama e LM Studio. Puoi eseguirlo come servizio Node locale o come app desktop Electron. Lascia vuote le chiavi API hosted e un modello locale compatibile manterrà il lavoro candidato lontano dai provider a pagamento. Usa un percorso hosted quando la velocità o un problema più difficile lo giustificano. Mantieni localmente il lavoro sensibile quando quel confine conta più del risparmiare qualche secondo su un’esecuzione.

Non c’è nessuna vittoria morale nell’inviare ogni task di sicurezza al modello più costoso disponibile. C’è solo una fattura.

Dove si colloca accanto a deepsec, VulnHunter e agli altri

ExploitHunter è deliberatamente più ampio di un harness per la scansione del codice. Porta un candidato su un target in esecuzione, lo analizza con strumenti browser e terminale, conserva le prove e poi consegna un finding verificato al sistema che dovrebbe correggerlo.

Diversi progetti coprono ormai parti diverse di questo flusso. Bene. I team di sicurezza hanno bisogno di strumenti che si passino il lavoro, non dell’ennesima categoria con un unico vincitore.

| Strumento | Dove è forte | In cosa ExploitHunter è diverso | |---|---|---| | Vercel deepsec | Un harness codebase-first: individuazione statica dei candidati, analisi con coding agent, riverifica, arricchimento e fan-out opzionale su sandbox su larga scala. | Deepsec è adatto all’analisi dei repository e al follow-up orientato alle pull request. ExploitHunter mette al centro un progetto di ricerca autorizzato che può includere un’applicazione in esecuzione, un browser, una rete di laboratorio, un terminale, evidenze persistenti e approvazioni esplicite dell’operatore. | | Capital One VulnHunter | Analisi del codice attacker-first, falsificazione strutturata dei finding e proposte mirate di remediation del codice. | La sovrapposizione è reale: le evidenze e la riduzione dei falsi positivi dovrebbero essere il minimo indispensabile. ExploitHunter è meno legato a un harness di coding o a un singolo percorso del modello, e più focalizzato sul coordinamento dell’indagine prima di proporre una modifica al codice. | | GitHub Security Lab Taskflow Agent | Taskflow dichiarativi abilitati per MCP, in particolare il triage degli alert CodeQL e l’analisi delle varianti. GitHub riferisce che ha contribuito a trovare circa 30 vulnerabilità reali. | È la base giusta quando l’input è un flusso ripetibile di scansione del codice. ExploitHunter è il workbench per la ricerca esplorativa che usa strumenti, dove ambito, approvazioni ed evidenze devono sopravvivere a un’indagine più lunga. | | OpenHands Vulnerability Fixer | Trasformare l’output di scanner come Trivy o di altri strumenti in correzioni prioritarizzate, test e pull request. | Una fabbrica di remediation. ExploitHunter opera prima nel ciclo: stabilire che il finding è reale, registrare il perché e consegnare un problema ben supportato al sistema di correzione. | | Assay | Applicazione offline delle policy, replay deterministico e bundle di evidenze crittografiche per le chiamate degli agent agli strumenti. | Complementare, non concorrente. È il tipo di controllo runtime deny-by-default che i workspace di ricerca agentica dovrebbero poter usare sotto il proprio livello di approvazione. |

Uno stack utile probabilmente include più di uno di questi strumenti: uno scanner del codice solleva i candidati, un taskflow fa il triage dei pattern ricorrenti, un workspace di ricerca verifica i casi pericolosi e un agent di remediation trasforma il lavoro verificato in una patch revisionabile. I passaggi di consegne contano più dell’incoronare una mascotte della sicurezza.

Eseguilo localmente. Usalo responsabilmente.

ExploitHunter è distribuito con licenza MIT, open source e progettato per attività che sei autorizzato a svolgere. Il repository include un target Juice Shop locale con hardening e laboratori di rete multi-servizio, così puoi provare l’intero flusso senza puntare un agent verso qualcosa che non possiedi.

git clone https://github.com/justsml/ExploitHunter.app.git
cd ExploitHunter.app
pnpm install
cp .env.example .env
pnpm dev

Poi apri http://localhost:3210.

Scegli un percorso del modello, autorizza un target che possiedi o per cui hai il permesso esplicito di eseguire test e assegna un obiettivo all’agent. Lascia che mappi il lavoro, approva solo le azioni che intendi davvero eseguire e osserva le evidenze accumularsi invece di sparire nella cronologia della chat.

Questa è la versione noiosa della sicurezza agentica.

È anche la versione che voglio dalla mia parte quando comincia la parte interessante.

Cosa succede dopo

Il prossimo obiettivo non è fare una dichiarazione più ambiziosa sull’hacking autonomo. È rendere più affidabile il ciclo di ricerca: report migliori sulle esecuzioni ripetute, validazione più rigorosa delle evidenze, maggiore copertura dei modelli locali, visibilità più chiara sulle approvazioni e un percorso più rapido da una finding verificata a una patch che un essere umano voglia davvero unire.

Gli agent di sicurezza non hanno bisogno di spazio illimitato per improvvisare. Hanno bisogno di sufficiente portata per sorprenderci, confini rigidi attorno a quella portata e prove quando dichiarano di aver avuto successo.

Questo è ExploitHunter: un unico posto in cui indirizzare modelli, strumenti, laboratori, approvazioni, evidenze e attività successive verso lo stesso problema.

Ora puntalo contro qualcosa che hai il permesso di rompere.