Docker Hub, oltre 10.000 immagini con credenziali esposte: a rischio anche una banca nazionale e una società Fortune 500

Più di 10.000 immagini di container pubblicate su Docker Hub rivelano dati che dovrebbero restare protetti, tra cui credenziali per ambienti di produzione, database CI/CD e chiavi di accesso a modelli LLM. Secondo l’analisi sarebbero coinvolte poco più di 100 organizzazioni, inclusa almeno una società Fortune 500 e una grande banca nazionale, a conferma di come il problema non riguardi solo realtà minori.

Docker Hub è il più grande registro pubblico di container, usato dagli sviluppatori per pubblicare, condividere e distribuire immagini pronte all’uso che includono tutto il necessario per eseguire un’applicazione. Proprio per questo, errori nella fase di creazione delle immagini possono avere un impatto ampio, propagando segreti e credenziali lungo l’intera catena di sviluppo e distribuzione del software.

L'analisi è stata condotta da Flare, azienda specializzata in threat intelligence, che ha riscontrato la presenza di ben 10.456 immagini che esponevano almeno una chiave o un dato sensibile, delineando un problema strutturale nella gestione delle credenziali in ambito container.

Fra i dati sensibili più frequentemente individuati nel report di Flare spiccano i token di accesso a servizi di intelligenza artificiale, in particolare per provider come OpenAI, Hugging Face, Anthropic, Gemini e Grok. Nel complesso, i ricercatori hanno contato circa 4.000 chiavi legate a modelli AI, un numero che mostra quanto l’integrazione dell’IA nelle applicazioni stia spesso avvenendo senza adeguata attenzione alla sicurezza delle credenziali.

Schema dell'esposizione di dati sensibili tramite immagini Docker - Fonte: Flare

Ancora più allarmante è il fatto che il 42% delle immagini analizzate contenesse almeno cinque valori sensibili diversi, tra chiavi, token e credenziali di vario tipo. Secondo Flare, queste esposizioni multiple costituiscono un rischio critico perché offrono, da una singola immagine, un potenziale accesso completo a ambienti cloud, repository Git, pipeline CI/CD, integrazioni di pagamento e altre componenti centrali dell’infrastruttura IT.

Inclusione impropria di dati riservati nelle immagini Docker: oltre 100 aziende coinvolte

Esaminando 205 namespace presenti su Docker Hub, i ricercatori sono riusciti a identificare 101 aziende colpite da esposizioni di dati sensibili all’interno delle immagini. Il campione è composto soprattutto da piccole e medie imprese, ma include anche alcune grandi realtà, a testimonianza di come la gestione delle credenziali nei container sia una sfida trasversale alle dimensioni aziendali. La maggioranza delle organizzazioni interessate appartiene al mondo dello sviluppo software, seguite da aziende attive nei mercati industriali e in ambito AI e sistemi intelligenti. Più di dieci realtà del comparto finanziario e bancario risultano avere dati sensibili esposti, elemento particolarmente delicato data la natura regolamentata e critica di questo settore.

Tra gli errori più frequenti, Flare evidenzia l’uso improprio dei file .ENV, spesso inclusi direttamente nelle immagini o nei layer del container. Questi file, per loro natura, contengono variabili di ambiente con credenziali di database, chiavi di accesso al cloud, token e altri dati di autenticazione di progetto, che dovrebbero invece essere gestiti con meccanismi separati dalle immagini distribuite pubblicamente. I ricercatori hanno rilevato token API per servizi AI hardcoded all’interno di script Python, file config.json, configurazioni YAML, oltre a token GitHub e credenziali per molteplici ambienti interni. In alcuni casi, informazioni sensibili erano persino presenti nel manifest dell’immagine Docker, il file che descrive meta-informazioni sull’immagine stessa, rendendo ancora più banale l’estrazione delle chiavi da parte di un attaccante.

Una parte significativa dei leak individuati sembra avere origine da account di tipo shadow IT, ossia profili Docker Hub che sfuggono ai meccanismi di controllo più stringenti dell’azienda. Si tratta spesso di account personali di sviluppatori o di contractor esterni, utilizzati per test o progetti paralleli, dove le regole di sicurezza vengono applicate in modo meno rigoroso rispetto ai repository ufficiali.

Questi account “ombra” possono diventare il vettore ideale per la pubblicazione accidentale di immagini contenenti segreti, senza che i team di sicurezza ne vengano a conoscenza in tempi rapidi. L’assenza di monitoraggio centralizzato sugli asset Docker utilizzati al di fuori dei canali ufficiali aumenta il rischio che le credenziali esposte restino accessibili a lungo e vengano sfruttate per attacchi mirati.

Flare segnala che circa il 25% degli sviluppatori che ha accidentalmente esposto segreti su Docker Hub si è accorto del problema e ha rimosso il dato sensibile dall’immagine o dal manifest nel giro di 48 ore. Questa reazione relativamente rapida suggerisce una certa consapevolezza del rischio, almeno in una parte della comunità, e la volontà di rimediare all’errore una volta individuato.

Il nodo critico, però, è che nel 75% dei casi il segreto esposto non viene revocato dopo la rimozione dall’immagine, lasciando quindi la chiave tuttora valida sul sistema di destinazione. Chiunque abbia acquisito quel token o quella password durante il periodo di esposizione può continuare a utilizzarli anche successivamente, trasformando un leak temporaneo in una porta d’ingresso persistente per futuri attacchi.

Quando più dati sensibili sono esposti nella stessa immagine, un aggressore può combinare diverse credenziali per muoversi lateralmente all’interno di un’infrastruttura aziendale. Per esempio, un token di accesso al cloud insieme a un accesso al repository Git e a una chiave per un sistema di pagamento può permettere non solo la compromissione di un singolo servizio, ma il controllo dell’intera catena applicativa.

L’inclusione di segreti direttamente nel container, inoltre, ne facilita la diffusione incontrollata, perché le immagini possono essere scaricate, clonate, riutilizzate e memorizzate in cache su più registry o nodi di esecuzione. Ciò amplia la superficie di attacco e rende complessa la bonifica completa, soprattutto se le chiavi non vengono invalidate sui sistemi di origine.

Flare raccomanda con forza agli sviluppatori di evitare di memorizzare segreti all’interno delle immagini container, abbandonando la pratica di inserire credenziali direttamente in file di configurazione o variabili di ambiente persistenti. In parallelo, viene suggerito di abbandonare l’uso di credenziali statiche e a lunga durata, optando per token a vita limitata e meccanismi di rotazione automatica.

Un altro punto chiave è la centralizzazione della gestione dei dati sensibili e riservati tramite soluzioni dedicate, come vault o secret manager, che permettono di controllare in modo granulare chi può accedere a quali chiavi, e di revocarle rapidamente in caso di compromissione. In questo modello, i container recuperano i segreti in fase di run-time da un servizio esterno, evitando che restino incorporati nei layer e riducendo il rischio di leakage accidentale.

Per le aziende, la raccomandazione è di implementare scansioni attive e continue lungo l’intero ciclo di vita dello sviluppo software, non solo sui repository di codice ma anche sulle immagini container generate dalle pipeline CI/CD. Strumenti di detection automatica possono individuare pattern riconducibili a chiavi, token e password, bloccando la pubblicazione di immagini contenenti dati sensibili.

Quando viene rilevata un’esposizione, è fondamentale procedere non solo alla rimozione del segreto dall’immagine, ma anche alla revoca immediata delle chiavi compromesse e all’invalidamento delle sessioni esistenti. Senza questa fase, il rischio residuo resta elevato, perché i dati potrebbero essere già stati copiati da terzi e utilizzati per future intrusioni anche in assenza di ulteriori indicatori di compromissione.

Il caso individuato da Flare rappresenta un nuovo campanello d’allarme per l’ecosistema DevOps, che sempre più spesso si affida a Docker e ai container per automatizzare sviluppo, test e deployment. La rapidità e la flessibilità offerte da questi strumenti rischiano di essere compromesse se la sicurezza delle credenziali non viene considerata una componente centrale del processo.

La presenza di migliaia di token legati a piattaforme di intelligenza artificiale mostra inoltre come la corsa all’adozione dei modelli AI stia avvenendo in molti casi senza adeguate pratiche di secret management. Per evitare che le chiavi di accesso a servizi costosi e critici diventino un obiettivo facile per gli attaccanti, sarà necessario integrare in modo più rigoroso la sicurezza nel ciclo di vita delle applicazioni AI-enabled, dalla scrittura del codice alla pubblicazione delle immagini su registri pubblici come Docker Hub.