Strumenti & App

Anthropic lancia OSS Scanner: controlli di sicurezza AI gratis per l’open source

Il servizio cerca falle nei progetti idonei, ma i rapporti arrivano senza una verifica umana.

Roberto Felicetti
Roberto Felicetti
9 ottobre 2026·7 min di lettura
Anthropic lancia OSS Scanner: controlli di sicurezza AI gratis per l’open source
Foto di Brecht Corbeel da Unsplash

La sicurezza delle app che usi dipende anche da piccoli componenti software che non hai mai sentito nominare. Molti sono open source, cioè progetti il cui codice è accessibile e può essere utilizzato secondo le condizioni della relativa licenza. Se una libreria impiegata da migliaia di servizi contiene una falla, il problema può propagarsi ben oltre il progetto in cui è nato.

È su questi componenti condivisi che Anthropic vuole intervenire con OSS Scanner, annunciato l’8 ottobre 2026. Il servizio offre ai progetti open source idonei controlli di sicurezza periodici e gratuiti, effettuati con i modelli di intelligenza artificiale dell’azienda. L’adesione è volontaria: non si tratta di una scansione imposta a tutti i progetti pubblici. Lo spiegano l’annuncio tecnico di Anthropic e la pagina del servizio.

La novità non è soltanto che un’AI cerchi errori nel codice. È la scelta di inviare rapidamente ai responsabili dei progetti rapporti non controllati prima da una persona. Può ridurre il tempo tra scoperta e segnalazione, ma trasferisce a chi mantiene il software una parte importante del lavoro di verifica.

Perché una falla in un piccolo progetto riguarda milioni di persone

Un’applicazione moderna assomiglia a un edificio costruito con materiali provenienti da molti fornitori. Il team che la sviluppa scrive una parte del codice, ma usa anche librerie esterne per gestire file, connessioni o accessi. Nella catena di fornitura del software — l’insieme dei componenti da cui dipende un programma — un difetto in un elemento riutilizzato può interessare prodotti molto diversi tra loro.

Il rapporto Open Source Security and Risk Analysis 2026 di Black Duck ha rilevato componenti open source nel 98% delle basi di codice commerciali esaminate; l’87% conteneva almeno una vulnerabilità già nota. Sono risultati relativi ai progetti sottoposti agli audit dell’azienda, non una misura di tutto il software esistente. Mostrano però perché migliorare la sicurezza dei componenti condivisi abbia effetti potenzialmente ampi.

Per chi usa un’app, la protezione non dipende quindi solo da quanto è attenta l’azienda che la vende. Conta anche la capacità dei responsabili delle librerie sottostanti di individuare i problemi, valutarne l’impatto e pubblicare correzioni. È a questi responsabili — spesso chiamati maintainer — che OSS Scanner si rivolge.

Che cosa fa OSS Scanner, dal controllo al rapporto

OSS Scanner esamina il repository, cioè l’archivio che contiene il codice e la storia delle sue modifiche. Secondo Anthropic, il sistema usa i suoi modelli più capaci, tra cui Claude Mythos, e invia ai responsabili una raccolta di possibili problemi dopo la prima analisi. I controlli successivi cercano sia difetti introdotti nel frattempo sia falle sfuggite alle scansioni precedenti; Anthropic non promette una frequenza identica per ogni progetto.

Ogni segnalazione può includere una spiegazione del difetto, un caso di prova riproducibile — istruzioni o dati con cui verificare se il problema si manifesta — e una proposta di correzione, quando disponibile. In alcuni casi il sistema prova anche a individuare la modifica che ha introdotto l’errore. È la differenza tra ricevere un avviso generico, come «questa porta potrebbe non chiudersi», e avere indicazioni su quale porta controllare e come ripetere il guasto.

Una segnalazione non è una falla confermata

I rapporti di OSS Scanner sono generati dall’AI e inviati senza revisione umana preventiva. Una possibile vulnerabilità deve essere riprodotta, valutata nel contesto del progetto e corretta prima di considerare risolto il rischio.

I numeri: risultati promettenti, ma da leggere con cautela

Anthropic afferma di aver individuato, nei sei mesi precedenti al lancio, oltre 29.000 possibili vulnerabilità nei progetti esaminati. Di queste, dichiara di aver potuto sottoporre a revisione e classificazione manuale circa 6.000. Il divario spiega la scelta di offrire un percorso più rapido ai progetti disposti a ricevere risultati ancora da verificare: trovare indizi con l’AI può essere più veloce che controllarli uno per uno. I 29.000 casi non vanno quindi interpretati come altrettante falle confermate.

In una verifica preliminare descritta da Anthropic, esperti hanno esaminato 97 segnalazioni classificate come gravi o critiche, relative a 48 progetti. Ottantacinque, pari a circa l’88%, soddisfacevano i criteri del suo processo di segnalazione verificata; delle altre dodici, undici riguardavano problemi reali ma duplicati o già noti, mentre una era errata. È un risultato riferito a quel campione di segnalazioni importanti, non un tasso di accuratezza dimostrato per tutti i futuri rapporti di OSS Scanner.

Anthropic riporta anche il riscontro di alcuni progetti coinvolti nei test: secondo il responsabile di wolfSSL citato dall’azienda, 72 dei 74 rapporti ricevuti erano validi. La stessa Anthropic riconosce però che il sistema può sopravvalutare la gravità di un problema o fraintendere il modello di minaccia, cioè la descrizione di chi potrebbe attaccare il software e in quali condizioni. Un difetto osservato in una prova, per esempio, non ha necessariamente lo stesso impatto in un prodotto distribuito agli utenti.

Chi può iscriversi e che cosa deve preparare

Gratuito non significa disponibile automaticamente per qualunque progetto. Anthropic valuta le richieste caso per caso, dando rilievo ai software consolidati che incidono sulla sicurezza degli utenti o delle infrastrutture: contano, per esempio, l’esposizione ad attacchi remoti e il numero di altri progetti che ne dipendono. L’azienda dichiara inoltre di verificare che a richiedere l’adesione sia davvero un responsabile principale del progetto.

La richiesta si presenta tramite una pull request, una proposta di modifica a un repository, nel progetto GitHub dedicato. Occorre indicare quale repository analizzare, a quale indirizzo inviare i rapporti e come preparare l’ambiente necessario a eseguire il software. Quest’ultima istruzione è contenuta in un Dockerfile, un file che descrive i passaggi per costruire l’ambiente di lavoro. Gli indirizzi inseriti nel file di configurazione pubblico devono essere scelti tenendo conto della loro visibilità.

Si può aggiungere una guida che delimiti quali comportamenti considerare rischiosi e quali test evitare: è un modo per dare all’AI le «istruzioni del cantiere» prima dell’ispezione. Anthropic prevede anche la possibilità di ricevere rapporti cifrati via email e di mettere in pausa le segnalazioni. Secondo la documentazione, le analisi vengono eseguite in ambienti isolati senza accesso a Internet dopo la preparazione dell’ambiente.

Prima di richiedere OSS Scanner, un progetto dovrebbe verificare:

  • di rientrare nei criteri di rilevanza e di poter dimostrare chi ne è responsabile
  • di avere un contatto affidabile per ricevere rapporti di sicurezza
  • di poter preparare l’ambiente di analisi richiesto
  • di avere tempo e competenze per verificare segnalazioni non revisionate

Il compromesso: più rapidità, più lavoro di verifica

Per un progetto con un gruppo di sicurezza organizzato, ricevere presto molti indizi può essere utile: permette di stabilire quali casi riprodurre per primi. Per un piccolo team già sommerso dalle segnalazioni, gli stessi messaggi possono diventare un carico difficile da gestire. Anthropic presenta infatti OSS Scanner come un’opzione soprattutto per chi riesce già a trattare i rapporti gravi verificati e vuole spingersi oltre. Per gli altri progetti, afferma di voler mantenere il proprio percorso di comunicazione delle falle controllate da persone.

Cambia anche la gestione della pubblicazione delle falle. Anthropic dichiara di non applicare ai risultati non verificati di OSS Scanner una scadenza automatica di 90 giorni per la divulgazione pubblica: non vuole imporre ai responsabili un conto alla rovescia per rapporti che l’azienda stessa non ha ancora controllato. Se una segnalazione sarà poi verificata manualmente attraverso il percorso ordinario, potranno applicarsi le regole di quel processo a partire dalla notifica della verifica.

È una distinzione essenziale. Pubblicare troppo presto i dettagli di una falla confermata potrebbe aiutare chi vuole sfruttarla; trattare ogni sospetto come un’emergenza, invece, potrebbe consumare il tempo necessario a risolvere i problemi reali. La velocità di scoperta ha valore solo se è accompagnata dalla capacità di decidere cosa correggere e di distribuire la correzione.

Come si colloca rispetto a OSS-Fuzz e Claude Security

OSS Scanner non inaugura i controlli gratuiti sull’open source. Google presentò OSS-Fuzz nel dicembre 2016: il servizio usa il fuzz testing, una tecnica che sottopone i programmi a numerosi input generati per far emergere errori e comportamenti inattesi. L’analogia è quella di provare una serratura con moltissime combinazioni insolite per scoprire quando si inceppa.

OSS Scanner segue un’impostazione diversa: affida ai modelli AI l’analisi del codice e la produzione di spiegazioni, prove riproducibili e possibili modifiche. I due approcci possono essere complementari, non intercambiabili. Anthropic cita OSS-Fuzz come fonte d’ispirazione per offrire controlli continuativi ai progetti open source importanti.

Va distinto anche da Claude Security, l’offerta commerciale con cui Anthropic permette ai clienti aziendali di analizzare e correggere il proprio codice. OSS Scanner, invece, copre i costi delle analisi per i progetti open source ammessi e invia i risultati ai loro responsabili. Non è un abbonamento gratuito generalizzato a Claude Security, né uno strumento che ogni utente può avviare su qualsiasi applicazione.

La sfida decisiva è trasformare i rapporti in correzioni

OSS Scanner rientra nella più ampia iniziativa Anthropic Cyber Mission, con cui l’azienda dichiara di voler sostenere chi difende software e infrastrutture. La sua stessa spiegazione individua il punto critico: verificare, comunicare e correggere le vulnerabilità richiede ancora lavoro umano, anche quando l’AI accelera la ricerca dei possibili difetti.

Il successo del servizio non si misurerà soltanto contando quante segnalazioni produce. Conterà quante risultano utili ai progetti, quante portano a correzioni e quanto tempo fanno risparmiare senza creare nuovo rumore. Per chi usa quotidianamente app e servizi, il beneficio sarebbe concreto ma poco visibile: problemi individuati e risolti nei componenti condivisi prima di diventare incidenti nei prodotti finali.

Potrebbe interessarti

Resta un passo avanti.

Ogni settimana, le migliori notizie su AI e tecnologia, selezionate per te.

Iscrivendoti accetti la nostra Privacy Policy.
Puoi cancellarti in qualsiasi momento.