Anthropic apre le scansioni gratuite ai progetti open source idonei. I report arrivano senza verifica umana preventiva: ecco come aderire, preparare il codice e valutare le segnalazioni.
OSS Scanner, annunciato da Anthropic l’8 ottobre 2026, offre scansioni periodiche gratuite ai progetti open source ammessi al programma. L’adesione è volontaria. La particolarità è il percorso accelerato: i manutentori ricevono le segnalazioni prodotte dai modelli senza attendere la revisione umana che precede le notifiche del programma CVD tradizionale. [1]
Per un piccolo gruppo di sviluppatori, avere più segnalazioni non equivale automaticamente a essere più sicuri. Il vantaggio arriva quando qualcuno riesce a leggerle, riprodurre il problema e intervenire. Conviene quindi valutare insieme la velocità dello scanner e il tempo disponibile nel progetto: una casella piena di report non risolti può diventare un nuovo arretrato, anche se ogni scansione è gratuita.
Il servizio fa parte della Cyber Mission di Anthropic, un’iniziativa che comprende anche il supporto alla difesa delle infrastrutture critiche. Questo contesto non cambia i requisiti di OSS Scanner: un progetto deve essere accettato, non basta rendere pubblico il codice. [4]
Secondo l’annuncio, i report includono un riproduttore e la spiegazione del problema; quando possibile, anche una bisezione per individuare l’introduzione del bug e una patch candidata. Anthropic avverte che possono esserci errori, duplicati o valutazioni di gravità eccessive. Nel controllo iniziale su 97 segnalazioni alte o critiche, 85 rispettavano i criteri del suo CVD, 11 erano duplicati e una era errata. Sono dati di quella valutazione, non una precisione garantita su ogni repository. [1]
Il dettaglio utile è la presenza di qualcosa da verificare. Un messaggio che indica una funzione sospetta e uno che fornisce un caso riproducibile richiedono lavori diversi. Anche una patch allegata va letta: potrebbe correggere il caso descritto restringendo un comportamento che altri utenti considerano legittimo. La velocità della scoperta e la qualità della correzione restano due aspetti separati.
Sintesi dei fatti documentati nell’articolo. I riferimenti sono riportati sotto lo schema.
Anthropic valuta l’idoneità caso per caso, con criteri simili a quelli di OSS-Fuzz: impatto sulle infrastrutture e sulla sicurezza, esposizione a input remoti e dipendenza di altri progetti. Prima dell’adesione verifica che il richiedente sia un manutentore principale. Per cifrare le email si può configurare una chiave pubblica GPG; in quel caso non sono ammessi destinatari aggiuntivi in copia. [2]
Un esempio illustrativo è una libreria che interpreta file ricevuti da utenti esterni. Nella richiesta avrebbe senso spiegare quali applicazioni la usano e dove il formato entra nel sistema. Per un programma impiegato solo in un contesto interno, occorrerebbe invece chiarire l’effettiva rilevanza. Questo non anticipa l’esito della candidatura: aiuta a descrivere il progetto senza ridurre tutto al numero di stelle su GitHub.
Il repository ufficiale richiede una configurazione project.yaml nella directory del progetto, con repository e contatto principale. Il Dockerfile prepara dipendenze e build. Il setup usa la rete; successivamente l’audit avviene senza Internet. La documentazione propone tools/validate.py per la configurazione e tools/check per costruire l’ambiente e aprire una shell senza rete nell’immagine pronta. [3]
La distinzione fra preparazione online e audit offline è concreta. Nell’esempio illustrativo di un progetto con test che scaricano dati al momento dell’esecuzione, la build potrebbe riuscire mentre la suite si fermerebbe nella fase senza rete. Una verifica utile consiste nel controllare quali dipendenze e dati siano già presenti nell’ambiente, prima di attribuire un errore allo scanner. Non occorre cambiare il progetto alla cieca: prima si identifica ciò che manca.
Un file opzionale sul modello delle minacce permette di descrivere input ostili, componenti esclusi, criteri di gravità e formato desiderato delle segnalazioni. Il repository consente di fornire questa guida insieme alla configurazione. [3]
Per il parser dell’esempio, una guida sensata distinguerebbe file provenienti dall’esterno e configurazione amministrativa fidata. Potrebbe anche chiedere al report di indicare le condizioni necessarie per raggiungere il codice sospetto. È più utile di una richiesta generica di trovare tutti i problemi: rende esplicito il contesto in cui una segnalazione verrà valutata, senza promettere che ogni istruzione sarà interpretata perfettamente.
Un flusso di lavoro illustrativo parte dall’identificazione della versione coinvolta e dalla lettura del riproduttore. Il manutentore può confrontare il comportamento descritto con il codice e con le segnalazioni già aperte, quindi controllare la patch proposta. Riprodurre il caso è una prova utile, ma non l’unico modo di analizzare un difetto: contano anche i requisiti del progetto e i percorsi effettivamente raggiungibili.
Per esempio, una modifica che rifiuta un input malformato andrebbe verificata sia sul caso segnalato sia su input validi vicini. Il secondo controllo può far emergere una regressione che il primo non mostra. Questa è una proposta operativa, non un test eseguito da noi né un risultato dello scanner. Vale la pena conservare versione, ambiente e condizioni della verifica, così che un altro sviluppatore possa comprenderla senza ricostruire tutta la discussione.
Project Glasswing è il precedente programma di Anthropic dedicato alla ricerca di vulnerabilità nel software critico. OSS Scanner riprende quell’esperienza, ma il suo percorso accelerato non va confuso con la validazione umana delle segnalazioni. [5]
OSS Scanner va distinto da Claude Security, il prodotto di scansione e proposta di patch destinato alle aziende. Anthropic segnala anche Claude for OSS, un programma separato che offre abbonamenti Max 20 x ai manutentori idonei. L’esistenza di questi strumenti non rende universale l’accesso al nuovo scanner. [1]
La configurazione disabled permette di sospendere i report. Le FAQ non impongono la finestra CVD di 90 giorni alle segnalazioni non validate. Se una viene poi verificata manualmente, Anthropic può divulgarla secondo la politica CVD, contando 90 giorni dalla notifica della validazione. L’azienda indica che potrà modificare in futuro alcune condizioni, con preavviso e possibilità di uscire. [2]
La scelta pratica dipende dal carico che il team può sostenere. Un gruppo con una persona disponibile al triage può iniziare organizzando un piccolo flusso di lettura, verifica e assegnazione. Chi ha già un arretrato consistente dovrebbe prima decidere chi lo gestirà. Lo scanner aggiunge capacità di ricerca; la decisione di correggere, rilasciare una versione e comunicarla agli utenti resta un lavoro da organizzare.
Analisi della risposta di Chrome ai dirottamenti dei ccTLD .gh, .sl e .as del 6 ottobre 2026, con focus su CRLSets, Certificate Transparency e l'uso di record CAA per prevenire l'emissione di certificati HTTPS non autorizzati.
Lo studio Truffle conta 543.699 credenziali databili ancora valide nei controlli di luglio 2026. Come leggere il campione e distinguere blocco del caricamento, avvisi e revoca.
Come creare una passkey Google, accedere dal telefono o dal computer e preparare il recupero. Requisiti, differenze fra i gestori e controlli da fare prima di perdere un dispositivo.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.