Chainguard presenta Harness per individuare vulnerabilità nei modelli di IA di frontiera

Il 14 ottobre 2026 Chainguard ha presentato Chainguard Harness, una soluzione che usa Claude Mythos 5.1 di Anthropic per individuare vulnerabilità sfruttabili in una build live e isolata dell’applicazione di un’organizzazione e fornire ogni vulnerabilità verificata insieme a una soluzione consigliata. Lo stesso giorno l’azienda ha aperto una lista d’attesa per la versione beta e ha reso la soluzione acquistabile tramite Claude Marketplace di Anthropic.

Nel suo annuncio, Chainguard ha dichiarato che, finora, i modelli di frontiera capaci di effettuare l’individuazione di vulnerabilità nel codice proprietario e open source sono stati perlopiù accessibili soltanto a un gruppo selezionato di organizzazioni che svolgono attività di sicurezza difensiva per infrastrutture critiche. Secondo l’azienda, Harness rende questa capacità accessibile alle organizzazioni che non dispongono di modelli di frontiera o delle competenze in ambito sicurezza e ingegneria necessarie per usarli autonomamente.

L’amministratore delegato e cofondatore Dan Lorenc ha dichiarato nel comunicato dell’azienda: «Ogni volta che abbiamo sottoposto del codice a Harness, ha individuato vulnerabilità gravi e sfruttabili, anche in software già sottoposto a numerose scansioni e in codice che gestisce infrastrutture critiche». Ha aggiunto che Harness offre ai team di sicurezza un’altra possibilità per ottenere vulnerabilità verificate e soluzioni che i loro ingegneri possono distribuire.

Come funziona Harness

L’annuncio di Chainguard descrive un processo in cinque fasi. I clienti collegano i repository tramite l’app Chainguard per GitHub con accesso in sola lettura oppure caricano un archivio del codice sorgente. Harness compila l’applicazione a partire dal codice sorgente esattamente come verrebbe distribuita in produzione e la avvia all’interno di una microVM isolata. Mythos 5.1 esamina quindi l’applicazione in esecuzione alla ricerca di difetti logici, vulnerabilità di injection e problemi di esaurimento delle risorse, analizzando il codice sorgente, la cronologia Git, il codice sorgente delle dipendenze e la configurazione della build e osservando le risposte dell’applicazione live.

Il contenimento avviene in due fasi. Durante la fase di preparazione, un modello distinto compila l’applicazione, recupera le dipendenze e gli strumenti necessari e la avvia all’interno della microVM, che viene poi sospesa. Nella fase di ricerca, la microVM viene riavviata per Mythos 5.1, senza accesso alla rete in uscita né credenziali al suo interno; il modello dispone soltanto di una shell e dei pacchetti realizzati da Chainguard. Il ciclo dell’agente si svolge al di fuori della sandbox, quindi vengono registrati ogni chiamata agli strumenti e ogni comando impartito dal modello. Il codice sottoposto a test viene trattato come dato non attendibile, una misura che, secondo l’azienda, protegge dalle iniezioni di prompt nascoste nel codice analizzato.

Ogni exploit viene riprodotto in una nuova microVM; se non riesce ogni volta, la vulnerabilità non viene inclusa nel rapporto. Ogni soluzione consigliata viene verificata allo stesso modo: l’exploit deve riuscire sul codice attuale del cliente e fallire dopo l’applicazione della soluzione. Il rapporto consegnato contiene una sintesi per i dirigenti, la gravità e l’impatto di ogni vulnerabilità, i passaggi per verificarla e una soluzione consigliata, formulata per la base di codice del cliente. Prima della consegna, un ingegnere Chainguard identificato per nome esamina e approva ogni soluzione e ogni rapporto.

Secondo l’annuncio, il modello è gestito esclusivamente dal personale di Chainguard: nessuno al di fuori dell’azienda può impartirgli istruzioni o vedere i suoi risultati grezzi. Quando Harness individua un difetto in una dipendenza open source anziché nel codice del cliente, Chainguard coordina la divulgazione con i manutentori del progetto a monte; una volta risolto il problema a monte, la build corretta viene distribuita tramite Chainguard Repository. Il comunicato chiama Athena questa procedura di divulgazione, ovvero il processo di Chainguard per la divulgazione coordinata delle vulnerabilità.

La prima vulnerabilità resa pubblica in vLLM

L’annuncio è arrivato un giorno dopo la pubblicazione da parte di Chainguard della prima vulnerabilità individuata da Harness e resa pubblica. In un articolo di ricerca del 13 ottobre 2026, l’azienda ha dichiarato che Harness aveva individuato un bug in vLLM, un motore open source per la distribuzione di modelli linguistici di grandi dimensioni, che consentiva a un client di forzare la restituzione dell’output della richiesta di un altro client su un motore condiviso. Il difetto riguardava allowed_token_ids, un parametro della richiesta che limita i token che il modello può generare: al termine di una richiesta, la relativa riga in una tabella condivisa delle restrizioni veniva riassegnata senza cancellare la restrizione precedente, perciò una richiesta successiva poteva ereditare i limiti del client precedente. Il bug interessava le versioni di vLLM precedenti alla v0.31.0.

Chainguard ha dichiarato di aver riprodotto l’exploit in tutte e tre le prove. L’azienda ha segnalato l’impatto sulla sicurezza ai manutentori di vLLM il 23 settembre 2026; la correzione è stata inclusa nella versione v0.31.0 il 2 ottobre 2026 e l’avviso GHSA-6cxc-2vcg-w5qc è stato pubblicato il 6 ottobre 2026. Il bug figurava nel sistema pubblico di tracciamento delle segnalazioni di vLLM dal 28 maggio 2026, classificato come un normale bug. vLLM ha attribuito al problema un livello di gravità basso; secondo l’articolo, la correzione consisteva in una modifica di una riga, oltre a una correzione correlata.

Secondo l’articolo, l’esecuzione su vLLM è durata 10 ore e 48 minuti, ha elaborato circa 115 milioni di token e ha esaminato 30 parti del progetto; 37 vulnerabilità candidate sono state riprodotte su un host pulito e 13 hanno superato la revisione tecnica. Chainguard ha dichiarato di aver eseguito Harness su oltre 65 progetti e convalidato oltre 680 vulnerabilità, alcune delle quali sono oggetto di divulgazione coordinata. Secondo l’articolo, il lavoro su Harness è nato dalla partecipazione di Chainguard al Project Glasswing di Anthropic.

Accesso alla versione beta e disponibilità sul marketplace

Inizialmente Chainguard sta aprendo l’accesso a un gruppo limitato di organizzazioni. La pagina del prodotto Harness specifica che la soluzione è in versione beta ed è una Technology Preview ai sensi dell’Accordo quadro sui servizi e sulla licenza di Chainguard.

Harness è presente nel Marketplace di Claude di Anthropic, dove la scheda indica che i clienti con un impegno già in essere con Anthropic possono avvalersene tramite la procedura di richiesta di acquisto del marketplace. Nel comunicato, Chainguard afferma che Anthropic gestisce la fatturazione: i clienti Anthropic possono quindi aggiungere Harness senza avviare una procedura di acquisto separata e consolidare le spese per l’IA.

Al lancio, gli ingegneri di Chainguard gestiscono Harness per conto dei clienti: possono eseguirlo sugli artefatti open source che Chainguard già distribuisce e fornire build corrette tramite Chainguard Repository, oppure eseguirlo sul codice sorgente di un cliente e consegnare un rapporto, verificato da un ingegnere, con i risultati convalidati, la relativa gravità e il relativo impatto, le istruzioni per riprodurli e le misure correttive consigliate.

Nel comunicato, Daniela Hurtado, responsabile del settore commerciale della cybersicurezza di Anthropic, ha affermato che modelli come Mythos 5.1 possono individuare vulnerabilità passate inosservate per anni e che Harness affianca al modello misure di isolamento, riproduzione e revisione umana, così da verificare ogni risultato prima che venga comunicato a un cliente. Le organizzazioni possono iscriversi alla lista d’attesa per la beta tramite la pagina di Harness di Chainguard.