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) — realizzato 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, con approccio 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 percorsi di attacco prospettici e propone correzioni mirate e supportate da evidenze.
Le moderne supply chain software sono profondamente interconnesse. Una singola vulnerabilità in un componente open-source ampiamente utilizzato può propagarsi a migliaia di aziende contemporaneamente.
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 sul duplice uso VulnHunter svolge attività di cybersecurity a duplice uso (scoperta e sfruttamento di vulnerabilità). Aspettati dei guardrail: la maggior parte dei modelli disponibili in commercio applica salvaguardie cyber per il duplice uso, e comportamenti di sfruttamento aggressivi possono attivare limiti di frequenza o flag di utilizzo. Lo sviluppo e i test di VulnHunter sono stati eseguiti su modelli open-weight forniti dalla comunità — de-risked, abliterated e uncensored — che sono i modelli probabilmente rilevanti per l'uso organizzativo in futuro. Verifica solo codice che possiedi o che sei altrimenti autorizzato a verificare.
[!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 fornitore. 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 codificano Opus; l'harness fissa claude-opus-4-8 | Le skill sono file di prompt portabili tra harness (qualsiasi harness con una directory delle skill + 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 presuppone ~/.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 operativa vulnhunter-run | — (assente) | Operatore non presidiato: clone → hunt → find-results → scrive/valida il manifest della scansione, con regole di arresto esplicite e nessuna improvvisazione | Rilasciato |
| Rafforzamento di benchmark/giudice | Modello fisso + retry di base | Modello tramite ambiente, configurazione di retry/backoff, tracciamento dei punti di perdita della pipeline analyze_misses, tracciamento della cronologia per singolo finding | Rilasciato |
| Linguaggio dei report neutro rispetto all'harness | Prosa specifica per Claude in tutte le skill | Linguaggio degli strumenti neutro 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 con 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 indipendente dall'host: è procedura di prompt, non vincolo 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 fornitore. 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 nell'harness che il tuo team già utilizza — e diventa confrontabile tra harness nelle esecuzioni di benchmark, che è il modo in cui questo fork viene sviluppato.
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 evidente con l'istruzione esatta quando la risposta manca. Meglio significa: sicuro su macchine con più harness, corretto con home rilocate, evidente invece che silenzioso in caso di errata configurazione.
Il design originale richiedeva già falsificazione e test di exploit. Ciò che lasciava aperto era quanto duramente lavorare per eseguirli effettivamente: traccia statica, test con mock o un vero server containerizzato. In un benchmark di sei esecuzioni contro un singolo commit, tale 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 runtime (Docker-first, registrata per ogni finding) e una disciplina PoC in cui l'impatto è misurato — righe esposte, amplificazione ×, ore-chiave disperse — non narrato. Migliore 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 segui le Discussions del repo.)
