Un errore di configurazione nel servizio AWS CodeBuild avrebbe potuto compromettere numerosi repository GitHub dell'azienda di Seattle, inclusi quelli contenenti il codice di applicazioni critiche come l'AWS JavaScript SDK, libreria fondamentale che alimenta l'intera console AWS. La vulnerabilità, scoperta ad agosto scorso dai ricercatori di Wiz, società specializzata in sicurezza cloud, è stata risolta da Amazon Web Services nel giro di 48 ore, ma i dettagli vengono resi pubblici solo ora.
L'episodio solleva interrogativi rilevanti sulla sicurezza della supply chain del software, dove un singolo difetto può propagarsi rapidamente attraverso l'ecosistema digitale. Il sistema di integrazione continua CodeBuild gestisce pipeline automatizzate che compilano e testano codice in ambienti cloud, e una sua compromissione avrebbe potuto estendersi potenzialmente a migliaia di applicazioni dipendenti dalle librerie AWS.
Il problema tecnico risiedeva in un filtro regex (espressione regolare) utilizzato per scansionare l'output dei log alla ricerca di credenziali sensibili da nascondere. Secondo i ricercatori, bastava che mancassero due caratteri in questo pattern di riconoscimento per consentire a attaccanti non autenticati di infiltrarsi nell'ambiente di compilazione e sottrarre credenziali privilegiate. "Questo dimostra la potenza e il rischio delle vulnerabilità della supply chain", ha dichiarato Yuval Avrahami, coautore del report, spiegando perché gli attacchi alla catena di fornitura del software siano in crescita esponenziale.
La scoperta è avvenuta dopo un tentativo concreto di attacco all'estensione Amazon Q per Visual Studio Code. Un malintenzionato aveva sfruttato proprio un progetto CodeBuild mal configurato per compromettere il repository GitHub dell'estensione e iniettare codice malevolo nel ramo principale. Il codice dannoso è stato poi incluso in una release scaricata dagli utenti, anche se il payload finale non ha funzionato per un errore di battitura. L'esecuzione sui dispositivi degli utilizzatori finali ha tuttavia dimostrato concretamente la gravità del rischio.
Amazon ha risposto implementando protezioni aggiuntive a tutti i processi di compilazione contenenti token GitHub o altre credenziali in memoria. L'azienda ha inoltre condotto un audit completo di tutti gli ambienti di build pubblici e analizzato i log di tutti i repository pubblici, insieme ai registri CloudTrail associati. AWS sostiene di aver determinato che nessun altro attore aveva sfruttato la vulnerabilità e che non vi è stato alcun impatto sulla confidenzialità o integrità degli ambienti dei clienti o dei servizi AWS.
Le dichiarazioni ufficiali del colosso di Seattle vanno tuttavia valutate con spirito critico. L'assenza di evidenze negli audit non equivale necessariamente a una certezza assoluta che nessun attaccante abbia scoperto e sfruttato la falla prima della sua correzione. La finestra temporale dell'esposizione rimane sconosciuta, così come il livello di sofisticazione necessario per individuare autonomamente la vulnerabilità prima della disclosure di Wiz.
Kellman Meghu, chief technology officer presso Deepcove Cybersecurity, sostiene che il problema non rappresenterebbe un rischio enorme per sviluppatori che non espongono pubblicamente CodeBuild. Tuttavia, aggiunge una considerazione più ampia sulla governance dello sviluppo software: utilizzare servizi pubblici come GitHub non sarebbe appropriato per la gestione e il deployment del codice enterprise. Le aziende dovrebbero possedere repository privati, su GitLab o server git proprietari, rendendo impossibile questo tipo di attacco se i threat actor non possono visualizzare il repository.
I ricercatori di Wiz raccomandano agli utenti di AWS CodeBuild di implementare diverse misure preventive: abilitare il nuovo controllo Pull Request Comment Approval, utilizzare runner ospitati da CodeBuild per gestire i trigger tramite workflow GitHub, e verificare che i pattern regex nei filtri webhook siano ancorati correttamente. Sul fronte delle credenziali, suggeriscono di generare token di accesso personale unici e granulari per ciascun progetto, limitandone rigorosamente i permessi al minimo indispensabile.
L'incidente evidenzia come la complessità crescente degli ambienti di sviluppo cloud-native moltiplichi le superfici di attacco. Mentre i fornitori di servizi cloud investono massicciamente in sicurezza perimetrale e crittografia, configurazioni errate in strumenti di automazione possono vanificare queste protezioni. La questione solleva interrogativi più ampi sulla responsabilità condivisa nella sicurezza cloud: dove terminano le responsabilità del fornitore e dove iniziano quelle del cliente quando si tratta di configurazioni predefinite potenzialmente rischiose?