ExploitHunter.app: la piattaforma di sicurezza IA n. 1

Un'ampia suite di sicurezza offensiva, con una suite di valutazione approfondita.

Indice

• Il ciclo utile è breve
• Un agente di sicurezza non dovrebbe avere un modello preferito
• Gli strumenti degni di credito non fanno tutti lo stesso lavoro
• I numeri sono pubblici perché anche le avvertenze dovrebbero esserlo
• Il benchmark ha catturato il benchmark
• L’evidenza è il prodotto
• Eseguilo localmente. Usalo responsabilmente.
• Cosa c’è dopo

Gli strumenti di sicurezza hanno un piccolo problema di documentazione.

Trovano una riga sospetta, ti passano un badge di gravità, e poi silenziosamente ti fanno dimostrare se è importante. Il risultato è “alto”. Eppure l’evidenza sono tre grep in un trench coat.

Quel flusso di lavoro era già costoso. Gli agenti lo peggiorano se glielo permettiamo. Un modello con un browser, una shell e un’istruzione vaga può generare una pila molto convincente di attività e token bruciati. Token bruciati != Fuoco.

Così ho costruito ExploitHunter.app: un workspace open-source, local-first per la ricerca di sicurezza autorizzata. Dà a un agente un vero lavoro: pianificare un’indagine, restare all’interno di un ambito target registrato, chiedere prima di fare lavori rischiosi, conservare le prove e produrre un rapporto che qualcun altro possa effettivamente ispezionare.

Non uno scanner con un chatbot incollato. Non una finestra di chat che tiene un set di grimaldelli. Un ciclo di ricerca con obiettivi e protezioni.

Il punto non è far sembrare occupato un agente. Il punto è far sì che ogni affermazione sopravviva al contatto con un altro ingegnere.

Il ciclo utile è breve

Un progetto di ExploitHunter si muove attraverso una sequenza deliberatamente noiosa:

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

Quell’ordine è importante.

L’autorizzazione al target è durevole. Non vive solo in un messaggio chat dove “sì, vai avanti” può acquisire nuovi significati tre turni dopo. Scansioni attive, test delle credenziali, comandi shell e scritture di file richiedono un gate di approvazione. Le approvazioni dei comandi ad alto impatto sono legate all’intento, limitate al progetto e al target e monouso per impostazione predefinita.

Poi c’è la parte che i prodotti di sicurezza amano glissare: la prova. ExploitHunter memorizza la sonda, la risposta, la trascrizione del comando, lo screenshot e l’artefatto di supporto con il risultato. Un rapporto può citare il suo lavoro invece di parafrasare le sensazioni della risposta finale del modello.

Questo non rende la ricerca sicura per magia. Riduce la deriva dell’ambito, rende le revisioni meno dipendenti dalla memoria e dà ai team qualcosa di meglio di “l’AI ha detto così.”

Un agente di sicurezza non dovrebbe avere un modello preferito

Gli ultimi annunci sulla sicurezza agentica sono un segnale utile: più team stanno realizzando che l’analisi del codice sorgente necessita di ragionamento dal punto di vista dell’attaccante, falsificazione e riparazione—non un altro carnevale di sink isolati. L’annuncio di VulnHunter di Capital One espone chiaramente questo caso per un flusso di lavoro di analisi del codice ottimizzato per Claude/Claude Code.

ExploitHunter fa una scommessa diversa.

La ricerca di sicurezza non è un compito per un singolo modello. Ricognizione web ampia, un laboratorio locale vincolato, sintesi delle prove, un flusso nel browser e un passaggio finale di remediation premiano modelli diversi, budget di strumenti e posture di privacy. Il modello giusto è una decisione di percorso, non un logo su una schermata delle impostazioni.

Ecco perché ExploitHunter supporta sia provider hosted che Ollama e LM Studio. Eseguilo come servizio Node locale o app desktop Electron. Lascia vuote le chiavi API hosted e potrà usare un modello locale compatibile senza inviare lavoro candidato a un provider a pagamento. Usa una route hosted quando la velocità o un problema complesso lo giustificano. Tieni il lavoro sensibile in locale quando quel confine conta più di risparmiare qualche secondo su un’esecuzione.

Local-first non significa che ogni modello scaricato diventi un agente di sicurezza affidabile. L’ultimo preflight sulla macchina di sviluppo ha tentato 24 pacchetti LM Studio; tre hanno superato i gate di caricamento, primo token e throughput. Quattro tentativi successivi sul percorso browser non hanno prodotto righe valide per la qualità del modello: uno ha superato il contesto disponibile, gli altri si sono conclusi senza il token, l’output e le prove di persistenza richieste dall’harness. L’ultimo tentativo sul percorso di produzione ha raggiunto la revisione di completamento, ma il giudice di qualità ha correttamente valutato la sessione bloccata con zero. Sono risultati di integrazione, non punteggi di qualità del modello – ed è esattamente il motivo per cui ExploitHunter testa l’intero percorso invece di dichiarare vittoria quando un modello risponde a un singolo prompt.

Non c’è vittoria morale nell’usare il modello più costoso per ogni attività di sicurezza. C’è solo una fattura.

Gli strumenti degni di merito non stanno tutti facendo lo stesso lavoro

Questo spazio è diventato interessante rapidamente. È un bene. I team di sicurezza hanno bisogno di più di una forma di strumento, e fingere il contrario è il modo in cui ogni categoria diventa un elenco di funzionalità in un trench coat.

Lo stack utile potrebbe essere composto da più di uno di questi strumenti: uno scanner di sorgenti per sollevare candidati, un taskflow per triare pattern ricorrenti, un workspace di ricerca per verificare i casi pericolosi e un agente di remediation per trasformare il lavoro verificato in una patch revisionabile. Nessuno ha bisogno di una mascotte della sicurezza che prende tutto.

I numeri sono pubblici perché anche le precisazioni dovrebbero esserlo

Abbiamo eseguito valutazioni in forma di prodotto contro target locali intenzionalmente vulnerabili, laboratori di rete Docker, scenari sintetici di comportamento degli strumenti e artefatti offline. Non sono rivendicazioni di supremazia universale nei benchmark. Sono osservazioni datate da un harness specifico, con artefatti di esecuzione e modalità di fallimento conservati accanto alle righe valide.

Iniziamo con il confronto diretto più pulito. Sette route attuali hanno ciascuna completato gli stessi 14 scenari di comportamento degli strumenti di sicurezza con una configurazione fissa. Queste sono le medie dell’intera suite, con il costo del modello tenuto separato dalla spesa del giudice:

Questo è un confronto tra modelli, non una vaga somiglianza di famiglia. Sol guida la media di 3 punti su Gemini e 4 punti su DeepSeek Flash. Flash arriva a 0,94 punti percentuali da Sol costando circa 98× meno. Gemini è il miglior realizzatore costante, con risultati tra 409 e 414. Kimi batte GLM di 1,7 punti medi ed è molto più costante; GLM costa circa 8× meno. Ogni candidato ha generato, tentato ed eseguito zero comandi pericolosi.

Le colonne dei fallimenti sono altrettanto utili. Il prezzo di Flash è eccellente, ma in media ha 9,67 fallimenti di guardia. La media di Sol è la migliore, ma il suo intervallo di punteggio osservato copre 23 punti. Gemini è notevolmente stabile, ma costa più di Sol con un punteggio inferiore. “Migliore” resta una frase che necessita di un oggetto.

Qwen 3.6 Flash ha anche completato l’esecuzione aggiornata sul target corrente – 375/425, 8/14, $0.047781 e 28 fallimenti di guardia – ma non faceva parte della baseline ripetuta sopra. Risultati precedenti di GPT OSS, Claude, Grok e Gemma locale rimangono osservazioni datate valide; non vengono introdotti di soppiatto in questa media come se il campionamento corrispondesse. Anche le quattro tracce candidate più recenti di LM Studio sono escluse: Langfuse registra i tentativi, ma nessuno ha completato con il token, l’output e le prove di persistenza richiesti per un punteggio del modello.

Poi l’ordine cambia quando usciamo dal comportamento sintetico degli strumenti e mettiamo gli agenti in laboratori reali.

Kimi contro GLM è particolarmente istruttivo. Sul recupero archivio, Kimi ha usato 11 chiamate a strumenti contro le 24 di GLM, ha ottenuto 10/10 contro 9/10 e ha costato meno. Sulla suite più ampia di 14 scenari, Kimi ha una media di 399,0/425 contro 397,3 di GLM, entrambi hanno una media di 10,33 scenari superati, e Kimi è sostanzialmente più costante – ma GLM costa $0,287614 contro $2,303873 di Kimi. Stessa famiglia di modelli. Diverse economie di compito. Diversa decisione di routing.

Le sweeps economiche e locali aggiungono un’altra route utile. In sweeps singole su larga scala di Juice Shop indurito, Qwen 3.6 Flash ha trovato 7 classi di vulnerabilità con prove per tutte e 7 in 21,4 secondi per $0,007271; Gemma 4 E4B locale ha prodotto 7/7 classi con prove per $0. Sono osservazioni su singolo target, non il confronto condiviso su 14 scenari di cui sopra, ma sono esattamente il tipo di economia del primo passaggio che un router può sfruttare.

Quindi sì, confrontate i modelli. Confrontateli solo nella corsia in cui hanno effettivamente corso. I risultati attuali nominano diversi vincitori: Sol per punteggio medio e superamenti; Gemini per coerenza e punteggio del giudice ad alta qualità; Flash per rapporto costo-prestazioni; Terra come percorso equilibrato; GLM per economia simile a Kimi; e Kimi per la fetta di recupero archivio verificato. La mappa di routing è costruita dalle leaderboard; non è una scusa per evitarle.

Se volete la versione lunga, inclusi metodologia, budget degli strumenti, controlli negativi e i modi in cui i modelli si imbarazzano quando un trascritto di comando contiene già la risposta, leggete Security Agents Need Model Routers, Not Model Rankings.

Il benchmark ha colto il benchmark

Il risultato più importante non è stata una vittoria del modello. È stata una perdita del valutatore.

Il primo report di recupero archivio ha dato a Kimi 5/10 e a GLM 9/10. Il task in sé è stato un successo: entrambi gli agenti hanno recuperato harbor-lantern-47, e un controllo unzip -t -P indipendente lato host ha provato che la password funzionava mentre le alternative no.

Il problema era il payload del giudice. Applicava un audit raw-Cybench di strumenti vietati a un task nativo di ExploitHunter in cui erano previste scritture di prove. Stesso output del modello. Stessa traccia salvata. Rubrica sbagliata.

Rimuovete l’audit irrilevante e 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; una verifica API in sola lettura il 17 luglio ha confermato entrambi i valori sugli ID di traccia persistenti.

Quello scarto di cinque punti è il motivo per cui ExploitHunter memorizza tracce, prove, versioni del valutatore, costi, token, budget degli strumenti e fallimenti degli harness invece di appiattire una valutazione in un unico numero eroico. Un benchmark che non può essere auditato è solo un altro modello che fa un’affermazione sicura di sé.

Le prove sono il prodotto

La novità qui non è che un LLM possa enumerare route, inviare una richiesta HTTP o suggerire una patch. Sappiamo che può farlo. La parte difficile è assicurarsi che l’indagine rimanga ispezionabile quando esce dal contesto del modello.

ExploitHunter mantiene memoria persistente del progetto e cronologia dei thread, ma il record durevole è la pipeline delle prove: cosa è stato tentato, sotto quale approvazione, contro quale target autorizzato, e cosa è tornato. I risultati possono poi alimentare il tracciamento delle remediation, l’analisi delle varianti, il lavoro sui percorsi di attacco e un report con citazioni anziché un blob di prosa sicuro di sé.

Quel design ha un vantaggio egoistico: rende il sistema più facile da debuggare. Quando l’agente perde qualcosa, abusa degli strumenti, inventa una conclusione o non riesce a salvare un artefatto, il problema è visibile. Possiamo sistemare il prodotto invece di discutere con uno screenshot di una bolla di chat.

Eseguilo localmente. Usalo responsabilmente.

ExploitHunter è con licenza MIT, open source, e progettato per lavoro che sei autorizzato a svolgere. Il repository include un target locale di Juice Shop indurito e laboratori di rete multi-servizio per testare il flusso di lavoro senza puntare un agente su 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.

Inizia con un target che possiedi o per cui hai esplicita autorizzazione a testare. Registra il perimetro. Lascia che l’agente faccia un piano. Approva l’azione che intendi effettivamente. Conserva le ricevute.

Questa è la versione noiosa della sicurezza agentica.

È anche la versione che voglio al mio fianco quando inizia la parte interessante.

Prossimi passi

Il prossimo compito non è una grande affermazione sull’hacking autonomo. Si tratta di rendere il ciclo di ricerca più affidabile: reportistica migliore per esecuzioni ripetute, validazione delle prove più rigorosa, maggiore copertura dei modelli locali, visibilità delle approvazioni più chiara e percorsi più rapidi da un risultato verificato a una patch che un umano voglia integrare.

Gli agenti di sicurezza non hanno bisogno di più permessi per improvvisare. Hanno bisogno di vincoli migliori, ricevute migliori e un modo per essere utili prima che arrivi il conto.

Snapshot di valutazione verificato il 17 luglio 2026. Le metriche sopra provengono dalle esecuzioni documentate del repository di Hard Juice Shop, Docker-network, local tool-behavior e LM Studio preflight runs, con le corrispondenti tracce Langfuse controllate in sola lettura. Descrivono quelle condizioni di valutazione, non una garanzia di prestazioni su ogni target.