Fughe di segreti in Claude Code: Apiiro trova credenziali in 1.122 file GitHub pubblici

Le fughe di segreti in Claude Code hanno portato sotto esame le approvazioni salvate di Anthropic, dopo che Apiiro ha segnalato credenziali in 1.122 file di impostazioni GitHub pubblici. La sua ricerca del 5 novembre descrive una funzionalità che ricorda comandi contenenti segreti. Per la pubblicazione è però necessario un altro passaggio: eseguire il commit e il push del file risultante.

La tensione sta tra una scorciatoia utile e il record sensibile che crea. Gli sviluppatori approvano un'operazione per completare il lavoro, mentre il software conserva informazioni che meritano una protezione separata. Una decisione sull'esecuzione diventa una decisione sulla conservazione, spesso senza che l'utente consideri queste opzioni come distinte.

Anthropic ha riconosciuto il problema, sottolineando al contempo che il file delle impostazioni dovrebbe restare locale. Cursor offre un confronto utile perché la sua documentazione affronta anch'essa l'esecuzione autonoma e i relativi rischi. Tra questi prodotti, la domanda è come i sistemi di autorizzazione possano preservare la praticità senza creare un altro luogo in cui si accumulano credenziali.

Cosa misura realmente il rilevamento delle fughe di segreti in Claude Code

La ricerca sull'esposizione delle credenziali di Apiiro ha esaminato 104.185 copie pubbliche di .claude/settings.local.json. Ha identificato 1.379 segreti distinti nei 1.122 file segnalati. I ricercatori non hanno testato tali credenziali, quindi il conteggio non dimostra accessi funzionanti o intrusioni riuscite.

Il dato principale misura i file esposti, non gli account compromessi. Questa distinzione è importante per la risposta agli incidenti, le decisioni di acquisto e qualsiasi affermazione sulla gravità del rilevamento. La presenza di una credenziale costituisce un motivo per indagare, mentre la sua validità e le sue autorizzazioni determinano le conseguenze immediate.

Il flusso di lavoro sottostante è familiare. Un assistente di coding propone un'operazione, lo sviluppatore la esamina e un'approvazione persistente riduce le interruzioni future. La conseguenza inattesa emerge quando l'approvazione salvata conserva informazioni che lo sviluppatore considerava temporanee.

Si consideri un controllo su un database di staging come scenario illustrativo. Lo sviluppatore ha bisogno che l'assistente indaghi su una connessione non riuscita e approva un comando contenente informazioni di autenticazione. Completare quel controllo non richiede che la credenziale diventi un artefatto di progetto durevole.

Eppure un record di approvazione può conservare proprio le informazioni necessarie all'operazione. Il suo scopo sembra amministrativo, il che rende facile separarlo mentalmente da password e token di accesso. Questa separazione diventa pericolosa quando i revisori presumono che la configurazione contenga preferenze anziché dati operativi sensibili.

Il repository pubblico aggiunge un altro confine. Informazioni prima disponibili sulla macchina di uno sviluppatore diventano accessibili a chiunque possa leggere il progetto. La funzionalità di approvazione e il flusso di pubblicazione richiedono quindi un esame separato.

Sarebbe eccessivo affermare che selezionare l'opzione invia automaticamente le password a GitHub. La sequenza riportata implica una persistenza locale seguita dalla pubblicazione tramite il controllo di versione, il sistema che registra e condivide le modifiche al progetto. Ogni fase crea un'opportunità di prevenzione.

Sarebbe inoltre riduttivo descrivere il problema esclusivamente come un commit eseguito con negligenza. Il comportamento del prodotto determina quale materiale sensibile esista affinché qualcuno possa sottoporlo a commit. Un flusso di pubblicazione più sicuro aiuta, ma evitare copie non necessarie delle credenziali affronta una parte più a monte del problema.

Il cambiamento rilevante riguarda ciò che i team devono considerare durante la revisione. Le impostazioni dell'agente meritano attenzione insieme al codice dell'applicazione e alla configurazione di deployment. Un file può influenzare la sicurezza attraverso le informazioni che conserva, anche quando non contiene alcun programma eseguibile.

Questo amplia il significato di modifica sensibile. I revisori devono considerare ciò che un file rivela oltre a ciò che fa fare all'applicazione. I record delle autorizzazioni si collocano direttamente a questa intersezione.

Un file di impostazioni locali è una promessa con condizioni

La documentazione sulle impostazioni locali di Anthropic afferma che le approvazioni Bash persistenti diventano regole di autorizzazione in .claude/settings.local.json. Bash è una shell di comandi utilizzata per eseguire programmi. Quando scrive per la prima volta il file nelle condizioni documentate, Claude Code aggiunge un'esclusione alla configurazione Git ignore globale dello sviluppatore.

La documentazione identifica separatamente .claude/settings.json come configurazione di progetto condivisa che i team possono sottoporre a commit. I file locali creati manualmente richiedono una propria esclusione. Queste distinzioni chiariscono il confine previsto, ma attribuiscono anche importanza al modo in cui il file è stato generato.

Definire un file locale non impone, di per sé, la privacy. Il suo nome comunica un'intenzione alle persone, mentre i controlli del repository determinano se viaggia con il progetto. Si tratta di protezioni correlate con diverse condizioni di fallimento.

Un'esclusione globale appartiene all'ambiente di uno sviluppatore. Un'esclusione a livello di progetto appartiene al flusso di lavoro del repository. Questa differenza conta ogni volta che i team si aspettano che una convenzione di sicurezza sopravviva a cambiamenti di macchine, collaboratori o ambienti di sviluppo.

Si consideri il passaggio di consegne di un progetto come esempio analitico. L'autore originale sa quali file contengono stato personale e quali file appartengono al controllo del codice sorgente. Un nuovo collaboratore vede la struttura delle directory senza necessariamente ereditare questa comprensione.

Il problema diventa organizzativo quando ogni collaboratore deve ricostruire la stessa distinzione. Una regola che dipende da conoscenze personali richiede attenzione ripetuta. Una regola rappresentata nella politica condivisa del progetto è più facile da esaminare e discutere.

Nessuno dei due approcci elimina la necessità di esaminare ciò che entra in un commit. Un'esclusione è una convenzione preventiva, mentre la modifica sottoposta a commit è l'effettiva decisione di pubblicazione. I team dovrebbero valutare entrambi, invece di presumere che la presenza di uno garantisca l'altro.

Anche la terminologia merita attenzione. Le impostazioni suggeriscono solitamente preferenze innocue, come opzioni di visualizzazione o comportamento dell'editor. Un file delle autorizzazioni può contenere un record molto più sensibile perché il suo contenuto ha origine in operazioni reali.

Questa discrepanza mette sotto pressione il design del prodotto. Se il software conserva gli argomenti dei comandi, dovrebbe aiutare gli utenti a comprendere tale persistenza prima che trattino il file come una configurazione ordinaria. L'avviso pertinente deve essere vicino alla decisione che crea il record.

Esiste qui un legittimo vincolo di usabilità. Richiedere agli utenti di ispezionare ogni dettaglio di implementazione renderebbe l'assistente più difficile da usare e incoraggerebbe approvazioni superficiali. La sfida progettuale consiste nel rendere visibile la conseguenza rilevante senza sovraccaricare l'operazione stessa.

Per gli acquirenti aziendali, questa diventa una domanda concreta di valutazione. Gli amministratori possono spiegare quali file dell'agente siano sicuri da condividere, quali restino personali e quali possano contenere dati sensibili? Le risposte di un prodotto dovrebbero allinearsi ai controlli del repository effettivamente utilizzati dai dipendenti.

Le autorizzazioni di Claude Code spiegate attraverso la documentazione forniscono il modello previsto. Il test pratico è se quel modello resti comprensibile durante la collaborazione quotidiana. La documentazione stabilisce aspettative; il comportamento osservabile determina se i team possano seguirle in modo affidabile.

La scorciatoia scambia richieste ripetute con dati persistenti

La praticità delle approvazioni persistenti è facile da comprendere. Gli sviluppatori vogliono che un assistente continui il lavoro di routine senza interrompere ogni passaggio. Un sistema che richiede ripetutamente la stessa decisione incoraggia gli utenti a cercare autorizzazioni più ampie o durature.

Il compromesso centrale è tra meno interruzioni e le informazioni conservate per renderle possibili. L'autorizzazione all'esecuzione e la conservazione delle credenziali meritano decisioni separate, anche quando l'interfaccia le presenta insieme.

Un modo utile per valutare il design è separare capacità e dati. La capacità descrive ciò che l'agente può fare, come eseguire un'operazione di sviluppo approvata. I dati includono gli argomenti specifici e il materiale di autenticazione fornito durante un'esecuzione.

Preservare la capacità non richiede necessariamente di preservare ogni dato. Tuttavia, rimuovere gli argomenti può modificare il significato di una regola. Un'approvazione più ampia potrebbe autorizzare operazioni che l'utente non ha mai inteso consentire, creando un diverso problema di sicurezza.

Ecco perché eliminare semplicemente il testo sospetto dai comandi salvati costituisce una specifica di design incompleta. Il prodotto deve preservare l'ambito voluto dall'utente evitando al contempo una conservazione non necessaria. Il comportamento risultante deve inoltre restare comprensibile quando un'operazione richiede nuovamente un'autorizzazione.

I riferimenti alle credenziali offrono un'altra direzione progettuale. Un comando può fare riferimento a un valore fornito separatamente invece di incorporarlo direttamente. Ciò riduce la necessità che un record di approvazione contenga la credenziale stessa.

Anche i riferimenti richiedono attenzione. Un programma potrebbe stampare un valore risolto, un messaggio di errore potrebbe rivelarlo, oppure un altro artefatto potrebbe conservare l'output. Evitare una password letterale in un record riduce l'esposizione senza stabilire una protezione completa.

Qui la storia diventa rilevante oltre un particolare pulsante. Il software per agenti produce record per supportare continuità, debugging e collaborazione. Ogni record dovrebbe avere uno scopo definito, un pubblico e una politica di conservazione proporzionata al suo contenuto.

L'apparente memoria dell'assistente può oscurare queste domande. Gli utenti vivono una conversazione che prosegue il lavoro, mentre l'implementazione può creare file con regole di condivisione diverse. I team di prodotto devono rendere visibili i confini che comportano conseguenze.

La documentazione sulla sicurezza degli agenti in background di Cursor offre un confronto utile. Descrive macchine virtuali isolate, accesso a Internet ed esecuzione automatica del terminale. Avverte inoltre che istruzioni malevole possono portare al furto di dati tramite prompt injection, in cui contenuti non attendibili reindirizzano il comportamento di un agente.

Questo confronto non dimostra che Cursor condivida il comportamento di archiviazione delle approvazioni riportato per Claude Code. Mostra che i design concorrenti distribuiscono la responsabilità in modo diverso tra esecuzione, isolamento e revisione dell'utente. Gli acquirenti dovrebbero confrontare separatamente questi meccanismi invece di scegliere un prodotto soltanto in base alla sua modalità di approvazione.

L'isolamento limita l'ambiente in cui viene eseguita un'operazione. L'approvazione decide se un'operazione procede. La gestione delle credenziali determina quali dati sensibili entrano nell'ambiente e quali record restano successivamente.

Questi controlli si rafforzano a vicenda quando i loro confini sono espliciti. Diventano confusi quando una decisione riuscita a un livello viene trattata come prova che ogni altro livello sia sicuro. Un'operazione autorizzata può comunque lasciare un record inappropriato.

I rischi per la sicurezza di Claude Code meritano quindi una valutazione a livello di flusso di lavoro. La domanda utile è quali informazioni generi un'attività approvata, dove tali informazioni persistano e chi possa recuperarle in seguito.

Anthropic riconosce la lacuna, ma la modalità automatica non è un certificato di correzione

Boris Cherny, del team di Claude Code, ha affrontato la segnalazione nella discussione sulla sicurezza delle autorizzazioni. Ha dichiarato che Claude Code storicamente non disponeva di un meccanismo di rimozione dei segreti e ha raccomandato la modalità automatica e la scansione dei segreti nel repository. Ha inoltre descritto possibili misure di protezione per la prototipazione, incluso un rilevamento di base dei segreti.

Un lettore ha chiesto se la modalità automatica potesse comunque raggiungere il percorso di approvazione problematico. Cherny ha riconosciuto l'osservazione. I suoi commenti attestano una risposta attiva, ma non dimostrano che sia stata rilasciata una correzione completa.

Una misura di protezione proposta deve essere verificata rispetto al guasto che dovrebbe prevenire. Ridurre le approvazioni manuali e impedire la persistenza delle credenziali sono obiettivi correlati, con criteri di accettazione diversi. Le prove a favore dell'uno non dovrebbero sostituire quelle relative all'altro.

La posizione scettica è semplice. Se un'operazione sensibile crea ancora un record di approvazione contenente una credenziale, modificare la modalità di esecuzione predefinita mantiene rilevante quel percorso. Una risposta deve affrontare l'artefatto risultante oltre alla frequenza delle richieste.

Esiste inoltre una ragionevole motivazione dietro l'enfasi di Anthropic su un minor numero di interruzioni per le autorizzazioni. Richieste ripetute possono assorbire attenzione senza produrre una revisione accurata. Migliorare questa esperienza è utile, purché il miglioramento non diventi un'affermazione generale sulla sicurezza.

Il disaccordo riguarda in parte il punto in cui debba risiedere l'applicazione delle regole. Alcuni utenti vogliono restrizioni fisse che valgano indipendentemente dall'interpretazione di un agente. Altri preferiscono una valutazione automatica in grado di distinguere l'attività ordinaria dalle operazioni sensibili.

Questi approcci rispondono a una domanda diversa da quella relativa alla presenza di password nei record salvati. Un rigido confine di esecuzione può coesistere con un'eccessiva conservazione dei dati. Un revisore automatico può ridurre le interruzioni pur necessitando di regole esplicite su ciò che viene scritto su disco.

La valutazione aziendale dovrebbe mantenere queste domande separate. Un acquirente può apprezzare l'esecuzione automatica delle attività e richiedere comunque un comportamento di archiviazione prevedibile. Il prodotto dovrebbe dimostrare entrambe le cose con risultati osservabili, anziché chiedere ai clienti di dedurre l'una dall'altra.

Un esercizio di verifica credibile userebbe credenziali artificiali in un progetto controllato. Ispezionerebbe il record di approvazione e gli altri artefatti risultanti dopo l'operazione. Esaminerebbe inoltre il comportamento quando un file locale sensibile è già tracciato.

Si tratta di condizioni di valutazione proposte, non di affermazioni su test completati da Anthropic. Descrivono le prove necessarie per distinguere una risposta promettente da un miglioramento dimostrato. Risultati pubblicati consentirebbero ai clienti di valutare la portata di qualsiasi cambiamento.

Le fughe di segreti di Claude Code espongono anche una sfida comunicativa. Consigliare agli utenti di abilitare un altro controllo è utile, ma lascia aperta la questione di quale responsabilità il prodotto stesso si assumerà. Note di rilascio chiare dovrebbero spiegare sia la nuova protezione sia le condizioni rimanenti.

La conclusione più equa è circoscritta e operativa. Anthropic riconosce la preoccupazione, gli utenti hanno sollevato casi limite pertinenti e l'efficacia delle modifiche proposte richiede osservazione. Né il rigetto né una dichiarazione di completa risoluzione sono coerenti con le prove disponibili.

I team di sicurezza ereditano un diverso tipo di revisione del repository

Per i team di sicurezza, la pressione immediata riguarda la visibilità. Le revisioni delle applicazioni spesso si concentrano sul codice eseguito in produzione. Le impostazioni generate dagli agenti possono creare esposizione prima che l'applicazione stessa modifichi il proprio comportamento.

La revisione deve seguire le informazioni sensibili lungo tutto il flusso di lavoro di sviluppo. Un file di configurazione merita attenzione in base al suo contenuto e alla sua destinazione. Il suo scopo amministrativo non rende innocue le informazioni al suo interno.

La protezione dei push di GitHub blocca il rilevamento di segreti supportati prima della pubblicazione. La sua documentazione distingue tra pattern specifici del provider, generici, personalizzati e rilevati dall'IA, con requisiti di configurazione variabili. I team devono quindi verificare la copertura effettivamente abilitata anziché presumere che ogni credenziale venga intercettata.

La presenza di uno scanner e la copertura dimostrata di uno scanner sono forme diverse di prova. Un token di servizio riconoscibile e una password ordinaria incorporata in un comando presentano sfide di rilevamento diverse. I test con esempi artificiali possono rivelare se il sistema configurato riconosce i pattern effettivamente utilizzati da un team.

Questo modifica la conversazione tra sviluppatori e personale di sicurezza. Lo sviluppatore necessita di un flusso di lavoro che continui a funzionare. Il team di sicurezza necessita di prove che i valori sensibili non entrino silenziosamente nel materiale destinato alla condivisione.

L'obiettivo comune dovrebbe essere un confine ripetibile. Lo stato personale dell'agente dovrebbe avere una destinazione esplicita, la configurazione condivisa dovrebbe avere uno standard di revisione chiaro e le credenziali rilevate dovrebbero arrivare a qualcuno che possa revocarle.

La risposta a un incidente deve inoltre separare il contenimento dalla bonifica. Le indicazioni di GitHub sulla rimozione dei dati sensibili danno priorità alla revoca o alla rotazione delle credenziali esposte. Spiegano che la rimozione storica richiede coordinamento e che le copie possono rimanere in cloni, fork e altri riferimenti.

Quest'ordine riflette la differenza tra una credenziale e il documento che la contiene. Modificare un documento cambia ciò che i lettori vedono in quella posizione. La revoca cambia se la credenziale continua ad autorizzare l'accesso.

Per un team sotto pressione, una bonifica visibile può sembrare il completamento perché il file problematico scompare dall'ultima visualizzazione. L'esito di sicurezza pertinente è se il valore esposto conserva autorità. La bonifica storica e la revisione degli accessi affrontano conseguenze aggiuntive.

La responsabilità diventa più difficile quando la persona che scopre il record non riesce a identificarne il proprietario. Uno sviluppatore potrebbe riconoscere il nome di un progetto senza sapere quale sistema abbia emesso un token. Una proprietà chiara accorcia il percorso dal rilevamento a un contenimento efficace.

I team necessitano anche di un modo per conservare l'insegnamento senza conservare il segreto. Una nota sull'incidente può descrivere il flusso di lavoro coinvolto, il servizio responsabile e la modifica preventiva. Dovrebbe evitare di copiare valori sensibili solo per rendere concreta la spiegazione.

Questa distinzione si applica anche a una base di conoscenza ricercabile. La conoscenza ingegneristica utile include procedure approvate e spiegazioni di fallimenti passati. Le credenziali appartengono a sistemi progettati per gestire l'accesso, anziché a materiale di riferimento generale.

I rischi di sicurezza di Claude Code sono più facili da governare quando la risposta ha responsabili nominati. Gli sviluppatori possono spiegare l'attività, i team della piattaforma possono applicare le convenzioni del repository e i proprietari dei servizi possono sostituire le credenziali di accesso. Il personale di sicurezza non dovrebbe dover ricostruire tutte queste relazioni durante un'indagine.

Il cambiamento organizzativo pratico è un perimetro di revisione più ampio. I team devono ispezionare ciò che l'assistente lascia dietro di sé insieme a ciò che modifica. Questo rende lo stato persistente dell'agente parte della normale governance ingegneristica.

Cosa dimostrerebbe che il percorso di esposizione si sta chiudendo?

Le prossime prove utili dovrebbero emergere nel comportamento del prodotto, nei controlli del repository e negli esiti della bonifica. Questi segnali affrontano parti diverse della sequenza segnalata. Insieme, possono mostrare se il percorso di esposizione originale diventa più difficile da riprodurre.

I progressi dovrebbero essere misurati in base alla persistenza impedita e alla ridotta autorità delle credenziali. Il solo linguaggio degli annunci non può dimostrare nessuno dei due risultati. Le prove più solide collegheranno una misura di protezione specifica a un cambiamento osservabile.

In primo luogo, occorre osservare un rilascio documentato di Claude Code che modifichi il modo in cui vengono archiviate le approvazioni sensibili. Il dettaglio decisivo è cosa accade quando un comando altrimenti legittimo contiene materiale di autenticazione. Un rilascio dovrebbe spiegare il record risultante e le circostanze che richiedono ancora l'intervento dell'utente.

La prova che i segreti sintetici non compaiano più nelle approvazioni salvate rafforzerebbe l'ipotesi di un miglioramento significativo del prodotto. La prova che gli stessi valori rimangano in un percorso di autorizzazione alternativo circoscriverebbe quella conclusione. Entrambi gli esiti sono più informativi di una dichiarazione generale su un'automazione più sicura.

L'ambito dei test conta quanto il comportamento principale. Un progetto nuovo e un repository con un file di impostazioni tracciato esistente rappresentano condizioni iniziali diverse. Un resoconto chiaro dovrebbe identificare quali condizioni copre la protezione.

In secondo luogo, occorre osservare controlli del repository che dimostrino copertura della configurazione dell'agente e delle credenziali incorporate nei comandi. Ciò include policy di esclusione chiare e rilevamento dei segreti testato. L'esito significativo è se un tentativo di pubblicazione viene bloccato o indirizzato a una revisione efficace.

Un documento di policy da solo lascia incerta l'esecuzione. Un esercizio controllato che mostri come le credenziali artificiali attivino la risposta prevista fornisce prove più solide. Errori ripetuti indebolirebbero la fiducia nella scansione come controllo compensativo.

Questo segnale è importante anche per i concorrenti. I fornitori possono descrivere gli ambienti di esecuzione in modo diverso, pur dovendo spiegare gli artefatti che conservano. Una documentazione chiara dei file generati, dei confini di condivisione e della gestione delle credenziali renderebbe i confronti più utili per gli acquirenti.

In terzo luogo, occorre osservare report di bonifica che distinguano i file rimossi dalle credenziali invalidate. L'aspetto del repository è facile da osservare, mentre l'accesso continuato richiede informazioni dal servizio responsabile. Un seguito credibile dovrebbe mantenere questi esiti separati.

I risultati di Apiiro non sono stati riprodotti indipendentemente qui e la sua raccolta non dovrebbe essere trattata come un campione casuale di tutti i progetti Claude Code. La popolazione segnalata consiste in file pubblicamente individuabili. Ciò limita le conclusioni sulla prevalenza dell'esposizione nell'insieme più ampio degli utenti.

Questi limiti lasciano intatta la preoccupazione ingegneristica centrale. Una funzionalità che conserva il contesto operativo necessita di una policy chiara per i dati sensibili. Gli utenti dovrebbero poter comprendere tale policy senza ricostruire l'implementazione durante una scadenza.

Per i team che valutano le fughe di segreti di Claude Code, iniziate dal record di approvazione che il vostro flusso di lavoro crea effettivamente. Usate credenziali sintetiche per esaminare ciò che persiste, quindi verificate quali controlli impediscono che quel materiale raggiunga un repository condiviso. Assegnate la responsabilità prima che una reale esposizione imponga la questione. Conservate le conclusioni come procedure che i colleghi possano seguire senza riprodurre valori sensibili. Quando credenziali autentiche compaiono in materiale condiviso, fate della loro autorità residua la prima domanda per il proprietario del servizio responsabile. Chiedete ai fornitori prove che affrontino l'archiviazione oltre all'esecuzione. La prossima revisione più utile è quella che risponde a una domanda concreta: dopo il completamento di un'attività approvata, quali informazioni sensibili rimangono e chi può ottenerle?