Una vulnerabilità in una libreria open source può entrare in un sito, in un gestionale o in un servizio cloud senza che l’azienda abbia scritto una sola riga del codice difettoso. È il rischio della supply chain software: ogni progetto dipende da componenti sviluppati e mantenuti da comunità che spesso hanno meno tempo e risorse di quanto richieda la sicurezza.
L’8 ottobre 2026 Anthropic ha annunciato OSS Scanner, un servizio sperimentale e volontario che usa i suoi modelli più capaci per analizzare periodicamente progetti open source, individuare possibili vulnerabilità e proporre correzioni. Per una PMI non è un nuovo antivirus da installare, né una scorciatoia che sostituisce aggiornamenti, test e revisione umana. È però un segnale importante: l’intelligenza artificiale sta entrando nel processo di ricerca e correzione dei difetti da cui dipendono anche WordPress, plugin, framework e applicazioni aziendali.
Che cos’è OSS Scanner
OSS Scanner fa parte della nuova Anthropic Cyber Mission, iniziativa dedicata alla difesa delle infrastrutture critiche e del software open source. Il servizio è opt-in: sono i maintainer dei progetti idonei a richiedere l’adesione. Anthropic dichiara che le scansioni saranno periodiche, gratuite e svolte dai suoi modelli di frontiera, incluso Claude Mythos.
Il punto più interessante non è soltanto la scoperta di un errore. Ogni segnalazione può includere un esempio riproducibile, la spiegazione tecnica, l’individuazione della modifica che ha introdotto il problema e, quando disponibile, una patch candidata. Questo formato prova ad avvicinare l’analisi automatica al lavoro reale di chi deve verificare, correggere e distribuire una nuova versione.
L’accesso non è indiscriminato. I maintainer principali possono candidare il progetto con una pull request; l’idoneità viene valutata caso per caso, considerando soprattutto l’impatto su infrastrutture e sicurezza degli utenti. Quindi una software house non deve dare per scontato di poter caricare il proprio repository privato nel servizio. Anthropic distingue infatti OSS Scanner dal prodotto Claude Security rivolto alle imprese.
I numeri comunicati da Anthropic, letti con prudenza
Nella fase precedente, collegata a Project Glasswing, Anthropic afferma di avere individuato oltre 29.000 vulnerabilità candidate in sei mesi. Circa 6.000 sono state sottoposte a revisione e triage manuale; quasi 5.000 segnalazioni non verificate sono state inviate direttamente ai maintainer che avevano chiesto di riceverle. Sono dati forniti dal produttore e non equivalgono a 29.000 falle confermate.
Un test più circoscritto ha sottoposto a penetration tester 97 segnalazioni classificate come critiche o ad alta gravità, distribuite su 48 progetti. Secondo Anthropic, 85 — l’88% — hanno superato la soglia prevista dal suo processo di divulgazione coordinata. Delle 12 restanti, 11 riguardavano problemi reali ma duplicati e una sola è risultata non valida. È un risultato promettente, ma il campione è selezionato, concentrato sui casi più gravi e non misura l’affidabilità di tutte le segnalazioni prodotte.
La stessa azienda riconosce due limiti essenziali: gli output del nuovo canale rapido saranno interamente generati dal modello, senza revisione umana, e possono contenere errori o valutazioni di gravità gonfiate. Un report automatico va quindi trattato come un’ipotesi tecnica da riprodurre e contestualizzare, non come una prova definitiva.
Perché riguarda anche le PMI italiane
Molte piccole e medie imprese non mantengono progetti open source critici, ma ne sono utilizzatrici quotidiane. Un sito WordPress combina core, tema, plugin, librerie PHP e JavaScript. Un gestionale web può dipendere da centinaia di pacchetti. Un’applicazione mobile incorpora SDK esterni. Migliorare la capacità dei maintainer di trovare e correggere vulnerabilità può ridurre il tempo tra l’introduzione del difetto e la disponibilità della patch.
Il beneficio, però, arriva all’azienda solo se la catena operativa funziona fino in fondo. Una patch pubblicata ma non installata non protegge il sito. Un aggiornamento applicato senza backup e collaudo può interrompere un servizio. Il caso recente di WordPress 7.1.1 e del piano di aggiornamento per le PMI mostra perché inventario, ambiente di test e verifica successiva restano indispensabili.
C’è anche un effetto organizzativo. Se gli strumenti AI aumentano il volume delle segnalazioni, il collo di bottiglia si sposta verso la validazione: bisogna distinguere i problemi sfruttabili dai falsi positivi, stimare l’impatto sul proprio contesto e scegliere la priorità. Anthropic stessa collega la nuova iniziativa alla difficoltà di verificare e correggere rapidamente tutto ciò che i modelli riescono a trovare.
Un piano pratico in cinque passi
1. Costruire l’inventario delle dipendenze
Per prima cosa serve sapere da quali componenti dipendono i servizi più importanti. Per ogni sito o applicazione registrare almeno versione del core, plugin o pacchetti principali, responsabile tecnico, modalità di aggiornamento e criticità del servizio. Dove possibile, mantenere una software bill of materials, anche semplice e generata dagli strumenti già usati nello sviluppo.
2. Assegnare responsabilità e tempi
Definire chi riceve gli avvisi, chi verifica l’esposizione e chi autorizza la messa in produzione. Una segnalazione critica non dovrebbe restare in una casella condivisa senza proprietario. Stabilire obiettivi realistici: per esempio presa in carico entro poche ore per vulnerabilità critiche sfruttate attivamente e una finestra più ampia per problemi medi senza evidenze di abuso.
3. Validare prima di intervenire
Un report prodotto dall’AI deve essere riprodotto in un ambiente isolato. Occorre controllare la versione interessata, le condizioni necessarie all’attacco, la raggiungibilità del componente e l’effetto della patch. Per i fornitori esterni, chiedere una risposta documentata: versione installata, esposizione effettiva, mitigazione temporanea e data prevista per l’aggiornamento.
4. Aggiornare con una procedura reversibile
Backup verificato, staging, test funzionali, aggiornamento, controllo dei log e piano di rollback sono ancora la sequenza corretta. L’automazione può velocizzare scansione e preparazione della correzione; non elimina il rischio operativo. Nei servizi esposti al pubblico conviene aggiungere monitoraggio degli errori e un controllo manuale dei percorsi più importanti subito dopo il rilascio.
5. Misurare il processo
Tre indicatori sono più utili del numero grezzo di alert: tempo medio dalla segnalazione alla valutazione, tempo dalla conferma alla correzione e quota di dipendenze critiche con versioni supportate. Aggiungere il tasso di falsi positivi aiuta a capire se lo strumento sta riducendo il rischio o soltanto generando lavoro.
Cosa non cambia
OSS Scanner non autorizza a testare sistemi altrui, non sostituisce un penetration test concordato e non garantisce che un progetto sia privo di vulnerabilità. Non basta neppure ricevere una patch proposta dal modello: il codice va revisionato, testato e distribuito secondo le regole del progetto. Inoltre, l’annuncio non promette copertura per ogni libreria utilizzata dalle aziende.
Serve infine una separazione netta dei permessi. Un agente o uno scanner incaricato di analizzare codice non dovrebbe poter pubblicare autonomamente modifiche in produzione, leggere segreti non necessari o approvare da solo la propria patch. Sono gli stessi principi di minimo privilegio, supervisione e tracciabilità descritti nelle sette regole pratiche per usare agenti AI in sicurezza.
La decisione utile per una PMI
Per la maggior parte delle PMI, la novità non richiede di iscriversi subito a OSS Scanner. Richiede invece una domanda concreta ai responsabili interni e ai fornitori: se domani arriva una patch urgente per una dipendenza open source, sappiamo dove viene usata e quanto tempo impieghiamo a distribuirla in sicurezza?
Le organizzazioni che mantengono un progetto open source ad alto impatto possono valutare l’idoneità del servizio e la capacità del team di gestire report non revisionati. Le altre dovrebbero usare l’annuncio come occasione per aggiornare inventario, flusso di triage e accordi con i fornitori. Il vantaggio dell’AI nella sicurezza non nasce dal numero di vulnerabilità trovate, ma dalla velocità con cui una segnalazione valida diventa una correzione verificata e realmente installata.
Fonti
- Anthropic — Launching an opt-in vulnerability-finding service for open-source software, 8 ottobre 2026.
- Anthropic — Introducing the Anthropic Cyber Mission, 8 ottobre 2026.
