La decisione di rendere open source ZCode non ha il sapore di una scelta di trasparenza maturata a tavolino. Arriva dopo segnalazioni di sicurezza arrivate dalla community e si presenta come una riparazione pubblica. Il repository su GitHub include client desktop, workspace web, backend, Agent CLI e runtime: un pacchetto ampio, che consegna il progetto alla verifica collettiva. Ma il cuore della mossa è tecnico, non simbolico. Nella versione 3.14.0 del client sono stati rimossi la funzione Repo Wiki e il flusso che generava e caricava snapshot dei repository locali.

La società ha dichiarato di aver completato la remediation e si è scusata con gli utenti. Ha inoltre confermato che i dati di codice citati dalla community non sono conservati e non sono mai stati usati per l'addestramento dei modelli. Per sostenere la ricostruzione ha coinvolto due soggetti terzi: la China Academy of Information and Communications Technology (CAICT) e NSFOCUS. Le valutazioni convergono su un punto: il bucket OSS su Alibaba Cloud denominato zcode-prod è in stato di zero dati e gli oggetti al suo interno risultano eliminati. NSFOCUS aggiunge che nel client 3.14.0 non è stato identificato alcun percorso funzionale capace di generare snapshot dei repository locali o trasmettere file locali all'esterno.

Vale la pena leggere questa sequenza non come un semplice incidente chiuso, ma come un cambio di incentivi. Rendere open source il codice dopo una crisi di fiducia sposta parte dell'onere della verifica sulla community e costruisce una narrazione di trasparenza. Tuttavia, open source non equivale a sistema sicuro. Il problema segnalato non era nel codice sorgente in sé, ma in un comportamento del prodotto: la generazione e il caricamento di snapshot locali. La correzione vera è la rimozione di quel flusso. La pubblicazione del codice serve soprattutto a rendere verificabile che la correzione esista davvero.

C'è un secondo livello. La conferma dello stato di zero dati da parte di CAICT e NSFOCUS riguarda il bucket al momento della verifica, dopo la remediation. Non risponde a domande più scomode: per quanto tempo i dati sono rimasti accessibili, chi vi ha avuto accesso prima della cancellazione e se il bucket avesse autorizzazioni troppo permissive. La fonte non fornisce questi dettagli. Resta anche da capire come funzionerà il nuovo processo di segnalazione delle vulnerabilità: la società promette ricompense in base alla gravità, ma l'efficacia dipenderà da tempi di risposta, criteri di classificazione e capacità di non ripetere l'errore.

Per chi sviluppa o valuta strumenti di assistenza al codice, la vicenda è un promemoria concreto: i client desktop e i workspace web possono interagire con alberi di file locali in modi non immediatamente visibili. La scelta di eseguire una parte dello stack in locale, o di ispezionare il codice prima dell'adozione, non è una questione astratta. Il repository ora rende possibile un audit indipendente del backend e del runtime. Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per confrontare i trade-off, ma non è una decisione da prendere sulla base di questa singola vicenda.

La storia di ZCode segnala anche un cambiamento strutturale: i ricercatori di sicurezza stanno usando le vulnerabilità degli assistenti di sviluppo per ottenere non solo patch, ma aperture di codice e audit esterni. È un esito che potrebbe diventare più frequente quando il software tocca repository locali e dati di sviluppo. Il confine tra incidente di sicurezza e spinta alla trasparenza diventa sottile, e i vendor potrebbero imparare a usare l'open source come strumento di gestione reputazionale. La differenza, per gli utenti, sarà nella qualità del codice pubblicato e nella reale capacità della community di farsi sentire prima che il danno si verifichi.