13.000 screenshot interni sono finiti su GitHub pubblico, e nessun attaccante li ha messi lì

I ricercatori di sicurezza hanno trovato più di 13.000 screenshot interni provenienti da oltre 300 organizzazioni presenti in repository GitHub pubblici. Gli screenshot non sono stati rubati. Sono stati pubblicati dagli agenti di codifica che le organizzazioni stavano usando, durante il normale lavoro.

La scoperta, riportata dalla società di sicurezza Glow, è una delle fughe di dati più istruttive degli ultimi tempi, perché le solite supposizioni non valgono. Non c'è stata alcuna violazione, nessuna credenziale compromessa e nessun insider malevolo. Uno strumento automatizzato ha fatto ciò che gli è stato detto, e ciò che gli è stato detto si è rivelato includere il commit di file che non avrebbero mai dovuto lasciare l'edificio.

Come uno screenshot finisce in un repository pubblico

Gli agenti di codifica acquisiscono screenshot per motivi sensati. Quando a un agente viene chiesto di verificare che una modifica all'interfaccia utente abbia funzionato, apre un browser, carica la pagina, cattura un'immagine e la confronta con il risultato atteso. Quell'immagine è una prova. Molti agenti la salvano nella directory di lavoro, così che il passaggio possa essere riesaminato in seguito.

Da lì, il percorso verso un repository pubblico è breve. Se la directory di lavoro dell'agente è la cartella del progetto, e la cartella del progetto è un repository git, allora uno screenshot scritto su disco è a un solo `git add` di distanza dall'essere incluso in un commit. Se l'agente esegue commit e push come parte del suo flusso di lavoro normale, e nulla filtra i nuovi file, lo screenshot finisce verso qualunque remote punti il repository.

Ora ripetete questo su migliaia di esecuzioni, in centinaia di organizzazioni, per mesi. Nessuno ha deciso di pubblicare screenshot interni. È stato il comportamento predefinito degli strumenti a farlo, e nessun passaggio della catena effettuava controlli.

Perché non è un piccolo errore

Uno screenshot interno è spesso più rivelatore di quanto le persone si aspettino. Può mostrare una dashboard con nomi di clienti, un pannello di amministrazione con i prezzi, un ambiente di staging, un bug tracker o una finestra di chat nell'angolo dello schermo. Può mostrare lo stato di un prodotto non ancora lanciato. Nell'insieme, 13.000 immagini da 300 organizzazioni sono una mappa di ciò su cui quelle aziende stavano lavorando.

Le immagini persistono anche. Un commit inviato a un repository pubblico rimane nella cronologia anche dopo che il file viene eliminato dalla versione corrente, a meno che la cronologia non venga riscritta. Quindi l'esposizione non si risolve con un successivo commit di pulizia, che è il passo a cui la maggior parte dei team penserebbe per primo.

Perché gli agenti peggiorano la situazione

Uno sviluppatore umano che acquisisce uno screenshot per una pull request di solito lo guarda prima di allegarlo. L'immagine è proprio lì, e la persona decide se è sicuro condividerla. Quel momento di giudizio è il filtro, e nella maggior parte dei casi funziona.

Un agente non ha un momento del genere. Ottimizza per completare l'attività, e salvare un artefatto fa parte del completamento dell'attività. Nulla nel ciclo chiede se l'artefatto sia sensibile, perché nulla nel ciclo è attrezzato per saperlo. L'agente non è imprudente nel senso umano. Sta facendo esattamente ciò che dicevano le istruzioni.

Questa è la stessa lezione che emerge in diverse aree della progettazione degli agenti. I permessi che andavano bene per una persona che digita comandi non vanno bene per un sistema che agisce alla velocità della macchina e non si stanca mai. Un essere umano che inserisce uno screenshot in un commit una volta a settimana è una svista. Un agente che lo fa a ogni esecuzione su una flotta è una conseguenza delle policy.

Come si presenta la soluzione

I controlli che avrebbero potuto prevenirlo non sono esotici. Una voce `.gitignore` per le directory degli screenshot è il più semplice, e funziona solo se qualcuno la scrive prima che l'agente venga eseguito. Un hook pre-commit che cerca file immagine in determinati percorsi intercetta ciò che il file di ignore manca. Assegnare agli agenti una directory di appoggio fuori dal repository per gli artefatti temporanei rimuove il problema alla fonte.

Nessuno di questi dipende dal rilevare che un'immagine è sensibile. Dipendono dal decidere in anticipo dove può andare l'output dell'agente. Questa è una decisione di progettazione, e deve essere presa dal team che esegue gli agenti, perché l'agente non può prenderla.

Perché i numeri continuano a crescere

Il conteggio di 13.000 immagini da 300 organizzazioni non è una cifra fissa. È un'istantanea dei repository pubblici al momento della scansione, e il numero aumenterà man mano che più team adottano agenti e più repository vengono inviati. I ricercatori hanno scansionato repository pubblici, il che significa che il totale reale, inclusi i repository privati dove si è verificato lo stesso errore, è inconoscibile dall'esterno.

Le organizzazioni colpite non sono tutte piccole. La scoperta ne nomina più di 300, un insieme che comprende startup e aziende più grandi che usano gli stessi strumenti per agenti. Questa è la natura di un problema di comportamento predefinito: non rispetta le dimensioni dell'azienda, perché ogni azienda che usa lo strumento eredita lo stesso default.

Cosa non dice il rapporto

La scoperta non sostiene che nessuna delle immagini esposte sia stata usata in modo malevolo, e non ci sono prove che qualcuno al di fuori dei progetti le abbia setacciate. Il danno è potenziale anziché dimostrato: il materiale era pubblico, e chiunque avrebbe potuto guardarlo. Nei casi correlati in cui il danno è stato dimostrato, come credenziali scritte in un file pubblico, il danno è immediato.

Inoltre, non ci dice quante delle immagini fossero sensibili in modo significativo. Alcune sono quasi certamente screenshot di una pagina di test vuota. Ma una fuga di dati si giudica dall'elemento peggiore, non dalla media, e 13.000 immagini in 300 organizzazioni significano che l'elemento peggiore è probabilmente davvero rivelatore.

Lo schema che c'è dietro

La scoperta di Glow è uno di un gruppo di rapporti simili. I ricercatori hanno dimostrato che gli agenti di codifica fanno riferimento a pacchetti software inesistenti, che gli attaccanti possono sfruttare registrando quei nomi. Altri hanno scoperto agenti che scrivono credenziali o token in luoghi in cui non dovrebbero. Il filo conduttore è che gli agenti producono artefatti come effetto collaterale del lavoro, e ogni artefatto è una potenziale fuga di dati.

La lettura rassicurante è che si può risolvere e dipende soprattutto da igiene operativa. La lettura meno rassicurante è che il settore sta implementando agenti più velocemente di quanto stia costruendo le protezioni attorno al loro output. Un'azienda che controlla ciò che i suoi agenti leggono spesso non controlla ciò che scrivono.

Cosa fare questa settimana

Se un team esegue agenti di codifica sui repository, vale la pena fare subito alcuni controlli. Verificate se la directory di lavoro dell'agente è dentro il repository, se screenshot o log finiscono lì e se il passaggio di commit filtra qualcosa. Controllate la cronologia del repository oltre all'albero corrente per file immagine che non dovrebbero essere pubblici. E assegnate agli agenti un percorso di appoggio fuori dall'albero per qualsiasi cosa temporanea.

Niente di tutto ciò richiede nuovi strumenti. Richiede di decidere che l'output dell'agente, come l'input dell'agente, è qualcosa che un team controlla di proposito, non per caso.