Anthropic OSS Scanner offre audit gratuiti per l'open source, ma i maintainer devono vagliare l'output dell'AI

L'8 ottobre Anthropic ha lanciato Anthropic OSS Scanner, offrendo ai progetti open source idonei audit ricorrenti sulle vulnerabilità senza costi. Il servizio rappresenta una significativa espansione della ricerca sulla sicurezza assistita dall'AI. Trasferisce però anche un onere importante sui maintainer, poiché i report arrivano senza validazione umana.

Questo compromesso definisce il lancio. Anthropic afferma che i suoi modelli possono esaminare più codice di quanto i suoi ricercatori di sicurezza possano revisionare manualmente. OSS Scanner elimina quel collo di bottiglia della revisione inviando risultati grezzi direttamente ai progetti partecipanti.

Il momento è delicato per i maintainer open source. Google ha recentemente sospeso parti del proprio programma di ricompense per vulnerabilità open source dopo aver ricevuto volumi crescenti di segnalazioni automatizzate non valide. Anche il progetto curl ha concluso il proprio bug bounty dopo che i maintainer hanno avuto difficoltà con invii di bassa qualità.

Anthropic ritiene che i suoi report offrano ora prove molto migliori rispetto alle segnalazioni generate dall'AI che in precedenza avevano frustrato i maintainer. I primi riscontri dei progetti supportano questa affermazione in casi selezionati. Tuttavia, il servizio pubblico non ha ancora dimostrato come la sua accuratezza terrà su una gamma più ampia di repository.

Anthropic OSS Scanner scambia la revisione umana con la velocità

Anthropic OSS Scanner offre ai maintainer un accesso più tempestivo a potenziali vulnerabilità, ma ogni progetto partecipante diventa responsabile della convalida delle conclusioni del modello.

Secondo il lancio di OSS Scanner, i progetti partecipanti ricevono scansioni periodiche dai modelli più avanzati di Anthropic. Questi modelli includono Claude Mythos, sviluppato da Anthropic per attività avanzate di cybersicurezza.

I report sono interamente generati dal modello. Anthropic non promette che un ricercatore di sicurezza verificherà una segnalazione prima che raggiunga il progetto. L'azienda avverte esplicitamente che i report possono essere errati o non validi.

Ogni report è progettato per includere più di una posizione di codice sospetta. Anthropic afferma di fornire una spiegazione, istruzioni di riproduzione e una patch proposta quando disponibile. Un report può anche includere un'analisi della cronologia del codice che identifica quando è comparso il difetto sospetto.

Queste prove sono importanti perché i maintainer necessitano di un metodo ripetibile per distinguere una vulnerabilità reale da un output del modello apparentemente plausibile. Un riproduttore concreto consente a un ingegnere di eseguire il codice pertinente e osservare se il comportamento segnalato si verifica davvero.

Una patch proposta può abbreviare il passaggio successivo. Non elimina la necessità di revisione, test, controlli di compatibilità e coordinamento a valle. Le correzioni di sicurezza talvolta modificano comportamenti su cui utenti o software dipendente fanno affidamento senza rendersene conto.

Anthropic ha testato la pipeline con decine di progetti open source prima di rendere l'iscrizione più ampiamente disponibile. Secondo l'azienda, queste prime scansioni hanno prodotto centinaia di report. Anthropic afferma che più segnalazioni potrebbero essere combinate in exploit di esecuzione di codice remoto non autenticata.

Si tratta di una categoria grave di vulnerabilità, perché un attaccante può potenzialmente eseguire codice senza prima effettuare l'accesso al sistema interessato. Tuttavia, Anthropic non ha pubblicato una valutazione indipendente completa di questi primi risultati.

Il lancio amplia il lavoro che Anthropic gestiva in precedenza tramite un programma di divulgazione coordinata delle vulnerabilità. In quel processo, i ricercatori di sicurezza esaminavano le segnalazioni prima di notificare i maintainer. La divulgazione pubblica seguiva generalmente una tempistica definita.

OSS Scanner crea un canale rapido separato. Le sue segnalazioni automatizzate vengono inviate privatamente via email ai maintainer e Anthropic afferma che non le pubblicherà automaticamente secondo la propria scadenza standard di divulgazione.

Se Anthropic in seguito convalida una segnalazione attraverso il proprio programma con revisione umana, quel report può entrare nel processo di divulgazione esistente dell'azienda. Fino ad allora, il report automatizzato rimane un invio privato non verificato.

La distinzione è essenziale. Anthropic non offre una certificazione che il software iscritto sia sicuro. Offre un'ulteriore fonte di ipotesi sulle vulnerabilità, supportate da prove riproducibili nei casi in cui il sistema riesce.

I numeri spiegano perché Anthropic ha cambiato processo

Il servizio esiste perché i modelli di Anthropic possono generare segnalazioni candidate molto più rapidamente di quanto i suoi ricercatori possano convalidarle.

Anthropic afferma di aver scoperto più di 29.000 vulnerabilità candidate durante la scansione di importanti progetti software nei sei mesi precedenti. I suoi ricercatori hanno revisionato manualmente circa 6.000 report nel periodo.

Ciò lascia più di 23.000 segnalazioni candidate al di fuori del processo di revisione umana completato. Alcune rappresenteranno problemi di sicurezza reali. Altre saranno duplicati, fraintendimenti, difetti a basso impatto o conclusioni errate del modello.

Anthropic afferma inoltre che i maintainer hanno richiesto sempre più spesso l'accesso in blocco al suo output non verificato. L'azienda riferisce di aver inviato quasi 5.000 segnalazioni non convalidate ai progetti che avevano chiesto di ricevere tutto ciò che era disponibile.

Questi dati spiegano la logica operativa alla base di Anthropic OSS Scanner. Continuare a richiedere la revisione manuale limiterebbe il numero di repository che Anthropic potrebbe coprire. Eliminare tale requisito aumenta contemporaneamente copertura, frequenza e incertezza.

L'azienda collega questo cambiamento al miglioramento delle prestazioni dei modelli. Anthropic afferma che i modelli linguistici individuavano meno del 20 percento delle vulnerabilità nel benchmark CyberGym all'inizio del 2025. Afferma che il risultato ha superato l'85 percento nel 2026.

Un benchmark è un insieme standardizzato di test, non una garanzia delle prestazioni sul campo. I repository reali contengono sistemi di build insoliti, presupposti non documentati, codice generato e confini di sicurezza specifici del progetto.

Un modello può inoltre identificare un autentico difetto software senza valutarne correttamente l'impatto sulla sicurezza. Una lettura fuori dai limiti in un'utility di test irraggiungibile presenta un rischio diverso rispetto a una esposta tramite un servizio di rete.

I numeri di Anthropic rivelano un secondo vincolo. Individuare potenziali problemi non è più l'unica risorsa scarsa. Verifica, prioritizzazione, correzione e divulgazione stanno diventando le parti più difficili del flusso di lavoro.

Questa transizione crea pressione sui progetti privi di team di sicurezza dedicati. Una grande libreria infrastrutturale può dipendere da un piccolo gruppo di maintainer che gestisce già richieste di funzionalità, regressioni, problemi di packaging e supporto alla comunità.

Anche un report ben strutturato richiede attenzione. Qualcuno deve riprodurre il comportamento, confermare le versioni interessate, valutare la sfruttabilità, progettare una correzione sicura e coordinare le release.

Da tempo i team di sicurezza usano analisi statica, fuzzing e scansione delle dipendenze per identificare comportamenti sospetti. Il fuzzing immette input inattesi nel software per rivelare crash o altri malfunzionamenti.

La scansione delle vulnerabilità con AI aggiunge un livello di ragionamento. Un modello può esaminare relazioni tra funzioni, dedurre il comportamento previsto, ispezionare la cronologia delle versioni e costruire un test mirato.

Anthropic afferma che i suoi modelli talvolta hanno seguito nuove piste investigative dopo che le tecniche convenzionali non avevano trovato nulla. Ricerche precedenti includevano l'esame della cronologia del controllo di versione e la scrittura di programmi proof-of-concept per vulnerabilità sospette.

Questo ragionamento più ampio può individuare difetti che gli strumenti basati su pattern non colgono. Può anche produrre una narrazione convincente ma errata. La qualità delle prove allegate conta quindi più della fluidità della spiegazione.

I maintainer open source diventano il livello finale di verifica

Il servizio gratuito di Anthropic sposta dai maintainer l'oneroso calcolo dei modelli, ma non elimina il costo umano del triage di sicurezza.

I maintainer principali devono aderire tramite il repository di iscrizione del progetto. Inviano una pull request contenente dettagli di configurazione e istruzioni per compilare il software.

Ogni progetto fornisce un indirizzo del repository, un contatto principale per la sicurezza e un Dockerfile. Un Dockerfile descrive l'ambiente e i comandi necessari per compilare il progetto all'interno di un container.

I progetti possono anche fornire un modello di minaccia. Questo documento spiega quali asset sono importanti, dove entrano dati non attendibili e come i maintainer classificano la gravità.

Questo contesto può prevenire evidenti fraintendimenti. Altrimenti, uno scanner potrebbe trattare un comportamento intenzionale come una vulnerabilità o sopravvalutare l'importanza di codice che non gestisce mai input non attendibili.

Anthropic compila i progetti partecipanti all'interno di macchine virtuali isolate. La configurazione può utilizzare l'accesso alla rete per recuperare le dipendenze richieste. L'analisi di sicurezza effettiva viene eseguita senza accesso a Internet all'interno di sandbox rinforzate.

Le segnalazioni vengono quindi inviate via email ai contatti designati dal progetto. I maintainer possono richiedere la consegna crittografata pubblicando una chiave OpenPGP nella configurazione di iscrizione.

Il servizio è limitato ai progetti open source che soddisfano i requisiti. Anthropic afferma che l'idoneità rispecchia i criteri usati dal programma OSS-Fuzz di Google. I progetti dovrebbero avere un impatto critico sull'infrastruttura o sulla sicurezza degli utenti.

Questo standard rende OSS Scanner diverso da uno strumento pubblico che chiunque può puntare contro qualsiasi repository. Anthropic controlla le iscrizioni e copre il costo di calcolo dei modelli per i progetti accettati.

L'azienda applica inoltre metodi di scansione più sperimentali e ad alta intensità di token rispetto a quelli usati nel suo prodotto commerciale generale per la sicurezza. Questa scelta posiziona il servizio open source come banco di prova per audit più approfonditi.

I maintainer mantengono il controllo dopo l'iscrizione. Possono modificare la configurazione, aggiornare le istruzioni di build, sospendere la scansione o ritirare il progetto tramite un'altra pull request.

Decidono inoltre cosa fare con ogni segnalazione. Anthropic non crea automaticamente una issue pubblica, non assegna un identificatore di vulnerabilità e non impone una scadenza di divulgazione all'output automatizzato grezzo.

Questo approccio riduce la probabilità che un report errato accusi pubblicamente un progetto di distribuire una falla sfruttabile. Evita inoltre di esporre dettagli tecnici prima che i maintainer abbiano valutato una patch.

Tuttavia, la consegna privata non risolve i vincoli di capacità. Un piccolo progetto può comunque ricevere più report credibili di quanti i suoi volontari possano elaborare. Anthropic non ha annunciato un limite universale al volume dei report.

I progetti avranno bisogno di proprie regole di gestione iniziale. Un flusso di lavoro pratico dovrebbe separare i problemi riproducibili e raggiungibili dall'esterno dai crash che richiedono condizioni irrealistiche.

I team necessitano anche di registrazioni tecniche durature. Una base di conoscenza ingegneristica ricercabile può preservare i passaggi di riproduzione, le versioni interessate, le decisioni sulle patch e le attività di follow-up.

Questa documentazione diventa importante quando più report condividono una causa alla radice. Senza di essa, maintainer diversi possono ripetere la stessa indagine o applicare correzioni incoerenti tra i vari branch.

La scansione delle vulnerabilità con AI affronta ora una prova di accuratezza

La domanda centrale non è più se un modello di AI possa trovare vulnerabilità, ma se possa fornire abbastanza segnale verificato da giustificare l'attenzione dei maintainer.

Le prove iniziali più solide di Anthropic provengono da progetti che hanno testato il sistema. Noah Misch, collaboratore di PostgreSQL, ha affermato che diversi report hanno identificato difetti e incluso correzioni quasi utilizzabili.

Anton Arapov di OpenSSL Corporation ha confrontato favorevolmente l'output grezzo con le segnalazioni umane. Ha sottolineato il valore di ricevere un exploit funzionante, perché gli ingegneri possono testarlo direttamente.

Il risultato segnalato più specifico è arrivato da wolfSSL. Secondo i commenti pubblicati da Anthropic, il progetto ha ricevuto 74 segnalazioni e ne ha ritenute valide tutte tranne due. Cinque segnalazioni sono diventate record Common Vulnerabilities and Exposures, comunemente chiamati CVE.

Questo risultato implica un'elevata precisione in una prima distribuzione. Non stabilisce lo stesso tasso tra linguaggi di programmazione, tipi di progetto, configurazioni di build e modelli di minaccia.

Il campione proviene inoltre dal materiale di lancio di Anthropic. L'azienda non ha pubblicato un set di dati completo che mostri tutte le segnalazioni accettate, respinte, duplicate e contestate del suo progetto pilota.

Una misurazione indipendente richiederà più che contare le segnalazioni. I ricercatori dovrebbero esaminare validità, gravità, duplicazione, tempo necessario per riprodurre il problema, tempo necessario per applicare una correzione e numero di regressioni causate dalle correzioni suggerite.

Anche l'impegno richiesto ai maintainer è una metrica importante. Uno scanner che individua più difetti reali può comunque creare un onere netto se ogni segnalazione valida arriva in mezzo a molti falsi positivi convincenti.

Questo rischio non è teorico. Altre comunità open source hanno sperimentato un'ondata di segnalazioni automatiche di vulnerabilità prive di prove adeguate.

Google ha dichiarato di aver sospeso una parte del suo Open Source Software Vulnerability Rewards Program dopo un consistente aumento delle segnalazioni automatiche. Secondo la spiegazione dell'azienda, la maggior parte di tali invii non era valida.

Il progetto curl ha concluso il proprio bug bounty nel gennaio 2026. I suoi maintainer avevano ripetutamente avvertito che le segnalazioni generate dall'AI stavano consumando tempo senza apportare un corrispondente valore per la sicurezza.

Anche i maintainer di Linux hanno descritto le segnalazioni automatiche duplicate come difficili da gestire. Più persone possono eseguire strumenti simili, individuare lo stesso schema dubbio e inviare indipendentemente proposte quasi identiche.

Il design opt-in di Anthropic affronta in parte questo problema. Solo i maintainer autorizzati iscrivono un progetto e le segnalazioni vengono inviate direttamente ai contatti designati. Non esiste alcuna ricompensa economica che incentivi soggetti esterni a massimizzare il volume degli invii.

Il riproduttore obbligatorio alza inoltre lo standard probatorio. Una segnalazione che mostra un comportamento osservabile è più utile di una che si limita a etichettare come pericoloso uno schema di codice.

Tuttavia, un riproduttore può dimostrare un crash senza provare l'esistenza di un percorso di attacco significativo. Può inoltre dipendere da un'opzione di build artificiale o da una configurazione che gli utenti reali non adottano mai.

Le patch candidate rappresentano un'altra fonte di incertezza. Una patch può silenziare un test lasciando intatta la vulnerabilità sottostante. Può anche introdurre un bug diverso o compromettere la compatibilità a valle.

I primi risultati giustificano un'attenzione prudente, non una fiducia automatica. Anthropic OSS Scanner deve dimostrare che il suo output resta utile dopo che l'adesione si sarà estesa oltre i progetti pilota collaborativi.

OSS Scanner integra gli strumenti di sicurezza esistenti

Anthropic sta posizionando il proprio scanner come un sistema di individuazione aggiuntivo, non come un sostituto di fuzzer, database di dipendenze, revisione del codice o divulgazione coordinata.

Il confronto storico più evidente è il servizio OSS-Fuzz di Google, che ha testato continuativamente importanti progetti open source con infrastrutture di fuzzing.

OSS-Fuzz è efficace quando gli strumenti possono generare input che esercitano comportamenti significativi del programma. È particolarmente utile per software che analizza file, messaggi di rete o altri dati non attendibili.

Tuttavia, il fuzzing dipende da harness di test e fallimenti osservabili. Alcuni errori di autorizzazione, difetti della logica di business e percorsi di attacco in più fasi non producono un crash immediato.

I modelli linguistici di grandi dimensioni possono ragionare su queste relazioni. Possono seguire i dati attraverso componenti diversi, considerare il modello di sicurezza dichiarato di un progetto e generare esperimenti mirati.

L'analisi statica tradizionale offre un altro termine di confronto. Esamina il codice sorgente senza eseguire l'intero programma e applica regole che identificano flussi o schemi rischiosi.

Gli analizzatori statici sono ripetibili e possono essere eseguiti a ogni modifica del software. La loro utilità dipende dalla qualità delle regole, dal supporto dei linguaggi e dalla capacità di un team di gestire avvisi ricorrenti.

L'analisi della composizione software si concentra sui pacchetti inclusi e sulle vulnerabilità note. Può indicare a un team che una dipendenza corrisponde a una versione interessata, ma di solito non individua un difetto sconosciuto in precedenza.

Il servizio di Anthropic prende di mira vulnerabilità sconosciute all'interno del codice sorgente. I suoi modelli non si limitano a confrontare un repository con un catalogo di vulnerabilità esistente.

La revisione umana resta necessaria in tutti questi approcci. Gli ingegneri della sicurezza comprendono il contesto di distribuzione, gli incentivi degli attaccanti, i requisiti di compatibilità e le conseguenze che vanno oltre l'ambiente di test immediato di uno scanner.

Gli strumenti possono anche rafforzarsi a vicenda. Un'ipotesi generata dall'AI può diventare un obiettivo di fuzzing. Il crash di un fuzzer può fornire a un modello prove concrete per l'analisi della causa radice.

Un modello può proporre una patch, mentre l'analisi statica e i test di regressione esaminano la modifica alla ricerca di nuovi problemi. L'analisi delle dipendenze può quindi identificare i prodotti a valle che necessitano di una release aggiornata.

La policy di disclosure standard di Anthropic resta rilevante quando i suoi ricercatori convalidano un problema. Tale policy prevede in genere una notifica seguita dalla divulgazione dopo 90 giorni o una volta rilasciata una patch.

La policy consente tempistiche più brevi per vulnerabilità critiche sfruttate attivamente. Descrive inoltre estensioni per i maintainer che stanno avanzando verso una correzione.

Le segnalazioni grezze di OSS Scanner operano al di fuori di questa tempistica automatica. Anthropic afferma che non le pubblicherà, a meno che non entrino successivamente in un processo sottoposto a revisione umana.

Questa separazione lascia ai maintainer spazio per indagare. Crea inoltre una questione di governance ancora senza risposta riguardo alle segnalazioni che restano irrisolte per lunghi periodi.

Anthropic afferma che potrebbe eventualmente introdurre periodi di disclosure per alcune segnalazioni automatiche ad alta gravità. L'azienda promette preavviso e la possibilità per i progetti di lasciare il servizio se questa policy dovesse cambiare.

Per ora, l'offerta privilegia l'accesso difensivo privato rispetto alla responsabilità pubblica. È una posizione di lancio ragionevole, ma dipende fortemente dal fatto che i maintainer partecipanti rispondano in modo responsabile.

Cosa determinerà l'efficacia del servizio

Tre segnali mostreranno se Anthropic OSS Scanner diventerà un'infrastruttura di sicurezza utile oppure un'altra esigente fonte di segnalazioni automatiche.

Il primo segnale è l'esperienza dei progetti appena iscritti. I riscontri del progetto pilota di Anthropic provenivano da team affermati, con una solida competenza tecnica e processi di sicurezza maturi.

Un'adesione più ampia metterà alla prova lo scanner su linguaggi, architetture e modelli di manutenzione diversi. I risultati dovrebbero rivelare se la sua accuratezza iniziale si trasferisce oltre un gruppo selezionato.

Le correzioni documentate pubblicamente forniranno prove utili. Riferimenti a commit, record CVE e retrospettive dei maintainer possono mostrare quali segnalazioni hanno prodotto miglioramenti significativi della sicurezza.

L'attribuzione è facoltativa, ma Anthropic incoraggia i progetti a includere un identificatore della segnalazione dello scanner nei commit pertinenti. Tali identificatori possono aiutare l'azienda a misurare quali segnalazioni hanno portato a patch.

Il secondo segnale è la qualità delle segnalazioni nel tempo. Anthropic dovrebbe infine pubblicare dati aggregati su precisione, duplicazione, gravità e remediation, senza esporre vulnerabilità irrisolte.

La misura più informativa non sarà il numero totale di potenziali segnalazioni. Sarà la proporzione che i maintainer riproducono, accettano e correggono senza un'indagine eccessiva.

Un tasso di falsi positivi in calo rafforzerebbe l'argomentazione di Anthropic secondo cui i modelli linguistici hanno superato un'importante soglia di utilità. Costi di triage in aumento la indebolirebbero.

Il terzo segnale è come reagiranno gli altri programmi di sicurezza. Google prevede di riesaminare il proprio processo di ricompense open source sospeso dopo aver affrontato invii automatici non validi.

Un'implementazione riuscita di Anthropic potrebbe influenzare gli standard probatori utilizzati da bug bounty e programmi di disclosure. Riproduttori e patch testabili potrebbero diventare requisiti attesi per qualsiasi segnalazione generata da una macchina.

Un'implementazione scadente potrebbe incoraggiare filtri più rigorosi. I maintainer potrebbero respingere per impostazione predefinita le segnalazioni automatiche, a meno che un'organizzazione riconosciuta non effettui una convalida umana.

Anthropic deve anche prestare attenzione all'adattamento degli attaccanti. Le stesse capacità dei modelli che individuano risultati difensivi possono aiutare ricercatori malevoli a investigare software ampiamente distribuito.

L'azienda afferma di applicare controlli di accesso e monitoraggio alle capacità cyber avanzate. OSS Scanner limita ulteriormente l'esposizione operando in ambienti isolati e consegnando privatamente le segnalazioni.

Queste misure non possono eliminare la corsa più ampia. I modelli continueranno a migliorare e capacità simili si diffonderanno tra provider, aziende di sicurezza e sistemi locali.

Questo rende la velocità di remediation sempre più importante. Individuare per primi una vulnerabilità offre poca protezione se un progetto non riesce a riprodurre, correggere, testare e distribuire la soluzione prima che gli attaccanti la sfruttino.

I maintainer open source dovrebbero valutare il servizio come un input di sicurezza aggiuntivo, non come un verdetto sul proprio codice. I progetti idonei possono esaminare i requisiti di adesione e decidere se dispongono di sufficiente capacità di triage.

La domanda migliore non è se uno scanner AI commetta occasionalmente errori. Ogni tecnica di sicurezza ha dei limiti. La domanda è se le segnalazioni di Anthropic facciano risparmiare più tempo di ingegneria di quanto ne consumino.

Anthropic OSS Scanner deve ora dimostrare questo equilibrio pubblicamente. Gli esiti per i maintainer nei prossimi mesi conteranno più del volume di vulnerabilità che i suoi modelli dichiarano di trovare.