Un repository GitHub pubblico chiamato “Private-CISA” ha esposto credenziali sensibili legate a infrastrutture governative statunitensi. La notizia, anticipata da KrebsOnSecurity, ha creato imbarazzo dentro CISA, Cybersecurity and Infrastructure Security Agency, l’ente che coordina la difesa informatica federale, improvvisamente ritrovatosi al centro di uno dei casi più evidenti di cattiva gestione dei segreti digitali. Il problema non riguarda soltanto password lasciate in chiaro; parliamo di chiavi cloud, accessi privilegiati e dettagli operativi interni pubblicati in un repository accessibile pubblicamente per un periodo ancora non chiarito.
La vicenda assume un peso particolare perché CISA rappresenta uno dei pilastri della cybersecurity nazionale USA. L’agenzia nacque nel 2018 all’interno del Department of Homeland Security con il compito di proteggere infrastrutture critiche, reti federali e operatori strategici. Negli anni ha promosso campagne aggressive contro l’uso di password deboli, contro l’hardcoding delle credenziali nel codice e contro le cattive pratiche DevOps. Il punto è che l’incidente descritto da Krebs sembra violare esattamente le regole che l’agenzia impone abitualmente a fornitori e amministrazioni. Questa storica e indimenticabile esternazione ci sta proprio bene!
CISA: credenziali AWS pubblicate in chiaro
Secondo quanto riportato da KrebsOnSecurity, il repository conteneva informazioni relative ad account AWS GovCloud, l’ambiente Amazon dedicato a enti governativi statunitensi e contractor che trattano dati sensibili o classificati. GovCloud utilizza regioni isolate rispetto all’infrastruttura AWS standard e applica requisiti specifici legati alle disposizioni normative più stringenti.
Esporre credenziali di questo tipo non significa lasciare online una semplice password. Una chiave di AWS IAM, il sistema di gestione degli accessi e dei permessi, se associata a privilegi amministrativi può permettere di accedere a bucket S3 per l’archiviazione dei dati, immagini usate per creare macchine virtuali, snapshot contenenti copie dei volumi di unità di memorizzazione, piattaforme CI/CD per automazione e distribuzione del software, secret manager per la gestione di credenziali e workload Kubernetes eseguiti nell’infrastruttura cloud federale.
Le informazioni pubblicate sembravano includere anche dettagli relativi ai processi interni di build e distribuzione software: conoscere l’architettura operativa di un’organizzazione governativa riduce drasticamente il tempo necessario per preparare campagne offensive mirate.
Perché GitHub resta uno dei principali punti di fuga
Molti incidenti recenti condividono uno schema ricorrente. Gli sviluppatori inseriscono temporaneamente una chiave API o una password in file YAML, script Terraform, workflow GitHub Actions oppure variabili hardcoded. La credenziale finisce in un commit; successivamente il repository diventa pubblico oppure il dato rimane accessibile nella cronologia Git anche dopo la rimozione apparente.
GitHub Actions rappresenta uno dei vettori più problematici: Workflow CI/CD configurati male possono stampare segreti nei log, esportare token come variabili d’ambiente o propagare credenziali verso fork pubblici.
Nel 2025, CISA aveva diffuso un avviso di sicurezza sulla compromissione della action tj-actions/changed-files, componente usato in migliaia di repository GitHub per rilevare automaticamente i file modificati. Gli attaccanti riescono a ottenere token di accesso e chiavi riservate leggendo i log delle pipeline CI/CD, cioè i processi automatizzati utilizzati per compilare, testare e distribuire il software.
Il problema dell’hardcoded secret
Le password in chiaro dentro il codice non sono una novità: già nei primi anni 2000 i penetration tester trovavano frequentemente credenziali embedded nei sorgenti Java, PHP o negli script shell amministrativi. Oggi però la situazione è peggiorata per almeno tre motivi: velocità di sviluppo più alta, enorme diffusione del cloud e uso massiccio di repository condivisi.
Una credenziale hardcoded tende inoltre a sopravvivere più del previsto: GitGuardian sostiene che oltre il 60% dei segreti individuati anni fa risultano ancora validi: significa che molte imprese scoprono la fuga ma non ruotano realmente le chiavi compromesse.
Nel caso CISA, Guillaume Valadon di GitGuardian ha definito la fuga di dati “la peggiore” osservata nella sua carriera. L’affermazione può sembrare estrema; tuttavia assume un significato diverso se si considera la natura dell’organizzazione coinvolta: una società privata può subire un danno economico o reputazionale. Un ente governativo responsabile della sicurezza nazionale apre invece implicazioni operative e politiche molto più ampie.
Nel complesso, GitGuardian ha rilevato quasi 29 milioni di segreti esposti pubblicamente su GitHub nel solo 2025; una crescita superiore al 30% rispetto all’anno precedente. API key, token OAuth, password, chiavi SSH e credenziali cloud finiscono continuamente nei repository pubblici: la superficie di attacco creata dagli strumenti di sviluppo e dall’utilizzo di configurazioni insicure cresce più velocemente della capacità delle aziende di controllare queste problematiche.
Una lezione scomoda per tutto il settore
L’incidente CISA dimostra quanto sia fragile la cybersecurity anche nelle organizzazioni più esposte: non basta pubblicare linee guida o framework NIST per evitare errori basilari. La disciplina quotidiana conta più delle policy scritte.
Esiste anche un aspetto culturale davvero cruciale. Molte strutture continuano infatti a trattare i repository Git come semplici strumenti di collaborazione; in realtà sono diventati archivi operativi critici che spesso contengono l’intera mappa tecnica di un’organizzazione. Chiavi cloud, configurazioni Kubernetes, workflow CI/CD, script Terraform e certificati finiscono tutti nello stesso punto.
CISA spinge da tempo sul concetto di Secure by Design e sulla responsabilità dei produttori software: una fuga di credenziali così ampia rischia inevitabilmente di indebolire la credibilità del messaggio pubblico dell’agenzia.