Oltre 10.000 container Docker con credenziali esposte in pubblico: come può succedere?

La supply chain software comprende tutti i processi, strumenti e componenti necessari per sviluppare, distribuire e aggiornare applicazioni: repository Git, pipeline CI/CD, container, librerie open source, servizi cloud e modelli AI. Ogni passaggio di questa catena si basa su credenziali, token e chiavi di accesso per automatizzare la comunicazione tra strumenti e garantire la continuità dei servizi. Un’analisi elaborata da Flare rivela che oltre 10.000 immagini Docker pubblicate su Docker Hub in un solo mese contenevano segreti attivi, tra cui credenziali di sistemi di produzione, chiavi API per servizi cloud e token per modelli AI avanzati.

L’esposizione di dati di questo tipo rappresentano una falla critica: un singolo segreto esposto può permettere a un attaccante di ottenere accesso diretto alle infrastrutture critiche altrui, compromettendo l’intera catena di distribuzione software e causando problemi su intere linee di business.

Un ecosistema di sviluppo sempre più dipendente dai segreti

Microservizi, componenti AI-as-a-Service e infrastrutture cloud dinamiche dominano lo sviluppo software: i segreti (intesi come credenziali, token, password,…) sono diventati un perimetro di sicurezza cruciale. Da un lato, infatti, sono indispensabili per l’automazione e la comunicazione tra strumenti, dall’altro risultano incredibilmente fragili se non gestiti correttamente.

Flare ha rilevato che un numero enorme di segreti rimane in circolazione, con scarsa rotazione, audit sporadici e gestione centralizzata quasi assente.

A rendere il quadro più complesso si aggiungono pratiche che andrebbero sempre evitate: hardcoding di API key dentro codice Python, file YAML, config.json, .env inserite per errore durante la fase di build dell’immagine, credenziali embeddate nei Dockerfile o addirittura nei manifest caricati su Docker Hub.

Il fenomeno non riguarda solo le piccole aziende: oltre 100 organizzazioni risultano coinvolte, inclusa una società Fortune 500 e una banca nazionale, spesso ignare della fuga di dati.

La scoperta conferma un nuovo paradigma negli attacchi informatici: gli aggressori non devono più violare i sistemi con exploit complessi, perché le chiavi vengono spesso “consegnate” loro, involontariamente, dagli sviluppatori stessi. Bastano soltanto un po’ di ricerche per far emergere queste informazioni.

Shadow IT: il vero acceleratore della crisi

Il termine Shadow IT indica tutti quei sistemi, software, servizi cloud o account utilizzati all’interno di un’organizzazione senza la conoscenza, l’approvazione o il controllo del reparto IT o della sicurezza aziendale. Si tratta di risorse “non ufficiali” adottate da dipendenti, contractor o team per motivi di produttività o comodità, che però creano punti ciechi di sicurezza. Alcuni esempi:

• Account personali su GitHub, Docker Hub, NPM usati per progetti aziendali.
• Servizi cloud come Google Drive, Dropbox, AWS utilizzati senza policy aziendali.
• App di messaggistica o strumenti di collaborazione non approvati ufficialmente.

Il rischio principale è che dati riservati, credenziali o configurazioni critiche siano esposte senza che l’azienda ne sia consapevole, creando vulnerabilità difficili da rilevare e mitigare.

Esaminando lo studio di Flare, in diversi casi i ricercatori hanno attribuito container compromessi a:

• Un contractor che mantiene 70 repository Docker con chiavi di clienti integrate nelle immagini.
• Un dipendente di una banca nazionale con oltre 430 immagini pubbliche, alcune contenenti token AI.
• Un archivio personale di un ingegnere che esponeva un GitHub token con privilegi amministrativi completi.

In tutti questi scenari, l’organizzazione titolare delle credenziali non aveva alcuna visibilità sulla fuga di dati. È insomma la dimostrazione tangibile che la superficie d’attacco nel 2025 non coincide più con l’infrastruttura ufficiale dell’azienda, ma con l’insieme disordinato di tool, device e account personali usati dai suoi collaboratori.

Raccomandazioni tecniche per non incorrere in problemi

Iniziamo col dire che nessun segreto dovrebbe mai essere memorizzato all’interno di un container. File di configurazione, Dockerfile, manifest, file .env, config.json, YAML o script Python non dovrebbero mai contenere credenziali attive: un’immagine che li include è compromessa per definizione e rappresenta un rischio immediato per l’intera infrastruttura.

Parallelamente, è fondamentale abbandonare le credenziali statiche e a lunga durata. Chiavi come AWS_SECRET_ACCESS_KEY, token persistenti di GitHub, Azure Client Secret o JSON di account Google Cloud Platform (GCP) devono essere sostituiti con identità effimere e basate su sessioni temporanee, come AWS STS con MFA, Identity Federation per GCP o Azure, Managed Identities o accessi OIDC a breve durata tramite Okta e Auth0. Questo approccio riduce drasticamente la finestra di esposizione in caso di fuga accidentale.

Un altro aspetto cruciale è la centralizzazione della gestione dei segreti. Strumenti come HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, 1Password Connect e CyberArk Conjur permettono di conservare, ruotare e distribuire credenziali in maniera sicura, evitando che possano essere replicate manualmente o sparse tra file temporanei e repository locali.

La protezione non si limita alla gestione dei segreti: è necessario implementare una scansione continua lungo tutto il ciclo di vita del software, monitorando repository Git, cronologie dei commit, pipeline CI/CD, container su Docker Hub, package registry, log di build e file temporanei. La tempestiva individuazione dei segreti esposti permette di intervenire prima che possano essere sfruttati da attaccanti o scanner automatizzati.

Infine, la semplice rimozione dei file contenenti credenziali non è sufficiente a mitigare il rischio. È indispensabile procedere con revoca immediata e automatizzata di chiavi cloud, token CI, credenziali AI, database e qualsiasi chiave di servizio. Solo in questo modo un’organizzazione può ridurre significativamente la finestra di esposizione e impedire che un segreto accidentalmente esposto diventi una porta di accesso alla propria infrastruttura critica.