nealbridges/vulnhunterScanner di sicurezza per AI agentica che ragiona come un attaccante sul codice sorgente, conferma le vulnerabilità sfruttabili con PoC eseguibili e guida le correzioni test-first attraverso le competenze hunt, fix e verify.
[!NOTE] Un fork mantenuto di VulnHunter di Capital One (Apache-2.0) — creato per funzionare su qualsiasi agent harness, non solo Claude Code. Il focus di questo fork: portabilità dell'harness, validazione degli exploit in sandbox (containerizzata) e PoC a impatto misurato. Vedi Perché le modifiche · Cosa cambia questo fork · I numeri.
Dal pattern-matching alla dimostrabilità.
VulnHunter è uno strumento di sicurezza AI agentico open-source che applica un'analisi proattiva, attacker-first, direttamente al codice sorgente.
A differenza dei tradizionali scanner SAST passivi, che segnalano pattern sospetti e spesso causano falsi positivi, VulnHunter ragiona come un avversario. Identifica quali difetti sono effettivamente sfruttabili, mappa i potenziali percorsi di attacco e propone correzioni mirate e supportate da evidenze.
Le moderne supply chain del software sono profondamente interconnesse. Una singola vulnerabilità in un componente open-source ampiamente utilizzato può propagarsi simultaneamente a migliaia di aziende.
VulnHunter è stato sviluppato internamente presso Capital One e reso open-source per la comunità. Questo fork porta avanti quel lavoro — stessa metodologia, rielaborata per funzionare su qualsiasi agent harness, con validazione degli exploit in sandbox (containerizzata) e PoC a impatto misurato come roadmap. Vedi Cosa cambia questo fork.
Avvertenza dual-use VulnHunter svolge attività di cybersecurity dual-use (scoperta e sfruttamento di vulnerabilità). Aspettati dei guardrail: la maggior parte dei modelli disponibili in commercio applica salvaguardie cyber dual-use, e un comportamento di sfruttamento aggressivo può attivare limiti di frequenza o flag di utilizzo. Lo sviluppo e il testing di VulnHunter sono stati eseguiti su modelli open-weight forniti dalla comunità — de-risked, abliterated e uncensored — che sono i modelli che probabilmente conteranno per l'uso organizzativo in futuro. Esegui l'audit solo su codice che possiedi o che sei altrimenti autorizzato ad analizzare.
[!IMPORTANT] Prerequisiti e requisiti del modello La metodologia di VulnHunter è costruita per funzionare su modelli open-weight forniti dalla comunità — quelli de-risked, abliterated e uncensored che le organizzazioni possono effettivamente distribuire. È richiesto un modello di ragionamento capace; il modello più potente offerto dal tuo harness dà i risultati migliori, ma la metodologia non dipende dal modello frontier di uno specifico vendor. Fornisci tu stesso l'accesso al modello.
| Capacità | Upstream (Capital One) | Questo fork | Stato |
|---|---|---|---|
| Portabilità dell'harness | Le skill invocano specificamente Claude Code; l'installer punta a ~/.claude/skills; i gate del modello hardcodano Opus; l'harness fissa claude-opus-4-8 | Le skill sono file di prompt portabili tra harness (qualsiasi harness con una directory skills + subagent); contratto d'ambiente VULNHUNT_SKILLS_DIR / VULNHUNT_AGENTS_DIR / VULNHUNT_BIN_DIR / VULNHUNT_HOST_CMD / VULNHUNT_MODEL; i gate del modello riformulati in "il modello di ragionamento più capace del tuo harness" | Rilasciato |
| Installer senza supposizioni | install.sh presume ~/.claude/skills | Directory esplicite, rispetta la semantica di GROK_HOME, scrive il launcher vh in VULNHUNT_BIN_DIR/~/.local/bin, installa la skill vulnhunter-run + la definizione dell'agent; equivalenti .cmd per Windows aggiornati | Rilasciato |
Skill operatore vulnhunter-run | — (assente) | Operatore unattended: clone → hunt → find-results → scrive/valida il manifest della scansione, con regole di stop esplicite e nessuna improvvisazione | Rilasciato |
| Hardening di benchmark/judge | Modello fisso + retry di base | Modello via ambiente, configurazione di retry/backoff, tracciamento dei punti di perdita con pipeline analyze_misses, tracciamento della cronologia per singolo finding | Rilasciato |
| Linguaggio dei report neutrale rispetto all'harness | Prosa specifica per Claude in tutte le skill | Linguaggio degli strumenti neutrale rispetto all'harness (Agent → subagent, Claude CLI → sessione dell'harness) | Rilasciato |
| Validazione degli exploit sandbox-first | I test degli exploit possono essere tracce statiche; scelta del runtime ad hoc | Provisioning del runtime Docker-first; il runtime registrato per ogni finding; severità Media+ deve essere eseguita | In corso |
| PoC a impatto misurato | I PoC sono documenti; l'impatto è asserito | PoC eseguibile + numero di impatto nel finding (righe esposte, richieste amplificate, ore-chiave bloccate) | In corso |
La metodologia di VulnHunter è per natura host-agnostica: è procedura di prompt, non binding a uno strumento. Il progetto upstream è cresciuto dentro Claude Code — una scelta coerente, e la giusta prima casa. Ma il panorama degli agent harness si è ampliato, e una metodologia di sicurezza che si installa in uno solo di essi smette di essere una capacità di audit e inizia a essere una funzionalità di un vendor. Questo fork apporta quattro modifiche, ciascuna con una motivazione.
Ogni skill qui è un file di prompt portabile con un contratto d'ambiente esplicito (VULNHUNT_SKILLS_DIR, VULNHUNT_AGENTS_DIR, VULNHUNT_MODEL, VULNHUNT_HOST_CMD), e i gate del modello ora richiedono il modello di ragionamento più capace del tuo harness invece di un prodotto specifico. Meglio significa: la stessa metodologia si installa in qualunque harness il tuo team già utilizzi — e diventa comparabile tra harness nelle esecuzioni di benchmark, che è come viene sviluppato questo fork.
L'installer upstream copiava le skill in ~/.claude/skills incondizionatamente. Su una macchina che esegue due harness — o un harness con una home rilocata — quella supposizione installa nel posto sbagliato, silenziosamente. L'installer del fork chiede, o accetta variabili d'ambiente, e fallisce in modo rumoroso con l'istruzione esatta quando la risposta manca. Meglio significa: sicuro su macchine multi-harness, corretto con home rilocate, rumoroso invece che silenzioso quando mal configurato.
Il design originale richiede già falsificazione e test degli exploit. Ciò che lasciava aperto era quanto duramente lavorare per eseguirli effettivamente: traccia statica, test mockato o un vero server containerizzato. In un benchmark di sei esecuzioni contro un singolo commit, quella discrezionalità ha prodotto da 3 a 42 finding — e verdetti opposti sullo stesso sink, uno dimostrato contro un mock, uno chiuso da un test contro un server reale. Questo fork aggiunge una procedura di provisioning del runtime (Docker-first, registrata per ogni finding) e una disciplina dei PoC in cui l'impatto è misurato — righe trapelate, ×-amplificazione, ore-chiave bloccate — non narrato. Meglio significa: la validità di un finding non dipende più da quale modello ha avuto l'istinto di avviare un container. (In corso — il piano di build è sulla roadmap pubblica; chiedi nelle issue o tieni d'occhio le Discussions del repo.)
