Come funziona
Dal link a un repository alle vulnerabilità verificate
La pipeline ricalca quella descritta da Anthropic per il suo OSS Scanner: modello delle minacce, audit, doppia verifica, causa radice, patch. È basata sui modelli Claude più avanzati disponibili tramite un'API pubblica.
- 1
Clone sicuro
Recuperiamo il branch che hai richiesto con un git clone superficiale, filtrato per blob, tramite HTTPS. Gli hook di Git sono disabilitati, i link simbolici vengono estratti come file normali e ogni protocollo diverso da HTTPS viene rifiutato. Gli indirizzi di rete privati sono bloccati, quindi non è possibile indirizzare lo scanner verso host interni.
Il contenuto del repository non viene mai eseguito: niente build, installazioni di pacchetti o test. La copia di lavoro viene eliminata al termine della scansione.
- 2
Inventario e classificazione dei rischi
Ogni file sorgente di testo viene elencato con il relativo linguaggio e le dimensioni. Il codice vendorizzato, i file generati, i bundle minificati e i file di lock vengono ignorati. A ogni file viene assegnato un punteggio di rischio basato su sink pericolosi — copie in memoria, esecuzione di shell, deserializzazione, costruzione di query SQL, rendering di template, unione di percorsi, codice crittografico e di autenticazione — e su percorsi critici come parser, gestori di protocolli e instradamento delle richieste.
- 3
Modello delle minacce
Se il repository contiene .oss-scanner/threat_model.md (lo stesso file letto dallo scanner di Anthropic), SECURITY.md oppure un modello delle minacce che hai fornito al momento dell'iscrizione, lo scanner lo segue. Altrimenti, un modello legge il README, la struttura delle directory e i file a rischio più elevato e ne elabora uno: descrive il progetto, indica dove entra l'input non attendibile e cosa è fuori ambito.
Il modello delle minacce seleziona anche i file su cui concentrarsi, così l'audit dedica le risorse al codice che un attaccante può effettivamente raggiungere.
- 4
Audit
I file più rischiosi vengono raggruppati in grandi lotti con i numeri di riga e inviati a un modello di ragionamento insieme al modello delle minacce. Il modello cerca problemi che un revisore umano scrupoloso segnalerebbe:
- sicurezza della memoria: overflow, use-after-free, troncamento di interi
- injection: SQL, comandi, template, path traversal, SSRF
- logica di autenticazione, autorizzazione e gestione delle sessioni
- deserializzazione non sicura e confusione del parser
- uso improprio della crittografia e gestione dei segreti
Le scansioni rapide usano Claude Haiku con un budget moderato. Le scansioni approfondite per i progetti registrati usano Claude Sonnet e analizzano fino a quattro volte più codice.
- 5
Verifica indipendente
Ogni potenziale vulnerabilità viene inviata a un agente verificatore separato, con un contesto nuovo. Il suo compito è confutarla: tracciare il flusso dei dati, cercare eventuali validazioni in altre parti del codice e verificare se, secondo il modello delle minacce, l'input è davvero controllabile da un attaccante. Sopravvivono solo le vulnerabilità confermate o giudicate probabili dal verificatore; le altre vengono conteggiate come respinte.
Per le vulnerabilità che superano la verifica, l'agente descrive la causa radice, scrive un riproduttore e propone una patch minima come diff unificato.
- 6
Commit di introduzione e report
I duplicati con la stessa causa radice vengono raggruppati. git blame sulle righe vulnerabili individua il commit più recente che le ha modificate, di solito quello che ha introdotto il bug, così puoi aggiungere un tag Fixes: e determinare quali release sono interessate.
Il report viene salvato con un ID casuale e non indovinabile. Puoi esportarlo in Markdown per un avviso di sicurezza, in JSON per gli strumenti o in SARIF 2.1.0 per la scansione del codice di GitHub.
Cosa non fa lo scanner
- Non esegue il tuo codice, non lo compila e non recupera dipendenze.
- Non pubblica le vulnerabilità, non apre issue e non contatta nessuno, tranne i maintainer iscritti.
- Non conserva copie del codice sorgente dopo la scansione. I report contengono brevi estratti delle righe interessate.
- Non garantisce alcun risultato: i modelli non individuano alcuni bug e a volte ne segnalano di inesistenti. Un report senza vulnerabilità non è una certificazione di sicurezza.
Perché i riproduttori sono riservati
Chiunque può inserire il link a un repository pubblico, anche chi non ne è maintainer. La causa radice e la patch aiutano i difensori; una prova di concetto funzionante aiuta soprattutto gli attaccanti. Perciò i riproduttori restano nascosti finché qualcuno non aggiunge al repository un file token, a dimostrazione di poter distribuire una correzione. Questo segue le indicazioni del kernel Linux: i riproduttori dei bug individuati dall'IA vanno condivisi su richiesta del maintainer.
In cosa si distingue lo scanner di Anthropic
Anthropic esegue il proprio scanner in sandbox offline, compilando il progetto a partire da un Dockerfile. In questo modo gli agenti possono compilare ed eseguire il codice per confermare dinamicamente i bug. Usa i suoi modelli più potenti, tra cui Claude Mythos, che non è disponibile al pubblico. Noi analizziamo il codice staticamente con modelli Claude disponibili al pubblico. In compenso, chiunque può usare ossscanner.org in pochi minuti, senza presentare una richiesta né avere un Dockerfile.