Nel lessico della sicurezza cloud, esistono incidenti che fanno rumore e altri che, proprio perché evitati in tempo, rischiano di passare sotto traccia. Il caso CodeBreach rientra in questa seconda categoria. Una configurazione errata all’interno di AWS CodeBuild, il servizio di continuous integration gestito da Amazon, ha creato una finestra di esposizione tale da consentire, almeno in teoria, la compromissione dei repository GitHub utilizzati dallo stesso AWS per sviluppare componenti fondamentali della propria piattaforma. Secondo i ricercatori di Wiz, se sfruttata in modo malevolo, questa falla avrebbe potuto aprire la strada a un attacco alla supply chain di portata superiore a quello di SolarWinds.

Il punto centrale non è tanto l’esistenza di una vulnerabilità in sé, quanto la sua collocazione. CodeBuild, infatti, non è un servizio periferico, ma un ingranaggio critico nei processi di sviluppo e rilascio software di AWS. I ricercatori hanno dimostrato che un difetto nei filtri dei webhook, causato dall’assenza di due semplici caratteri nelle espressioni regolari, rendeva possibile aggirare i controlli pensati per bloccare l’esecuzione di build provenienti da contributori non fidati. Un errore apparentemente banale, ma con implicazioni sistemiche.

Il meccanismo di difesa coinvolto, basato sul parametro ACTOR_ID, serviva a consentire l’avvio delle pipeline solo a un insieme ristretto di identità GitHub approvate. Tuttavia, l’uso di regex non ancorate permetteva a un attaccante di registrare un’identità che contenesse come sottostringa quella di un maintainer legittimo. Dal punto di vista del motore di matching, il filtro risultava valido, mentre dal punto di vista della sicurezza era un bypass completo.

Una volta ottenuta l’esecuzione del codice all’interno dell’ambiente di build, la catena di escalation diventava sorprendentemente lineare. I ricercatori di Wiz hanno inserito in una pull request apparentemente innocua una dipendenza NPM malevola, progettata per estrarre le credenziali GitHub disponibili durante il processo di build. In pochi istanti, tali credenziali hanno consentito di assumere privilegi amministrativi sul repository, inclusa la possibilità di approvare modifiche, scrivere direttamente sul branch principale ed esfiltrare segreti. In termini di supply chain, si tratta del punto di non ritorno.

infrastruttura AWS

Crediti: Shutterstock

La gravità del caso aumenta se si considera l’ampiezza dell’ecosistema coinvolto. Tra i repository vulnerabili figuravano infatti l’AWS SDK per JavaScript, librerie crittografiche e progetti ampiamente utilizzati da sviluppatori e aziende. Il JavaScript SDK, in particolare, è presente in circa due terzi degli ambienti cloud, compresa la console di gestione AWS. Un’iniezione di codice malevolo a ridosso di una release settimanale avrebbe potuto propagarsi rapidamente a milioni di applicazioni, trasformando un singolo repository compromesso in un vettore globale.

AWS ha dichiarato che nessun ambiente cliente è stato impattato e che la vulnerabilità è stata corretta entro 48 ore dalla segnalazione, accompagnando il fix con audit estesi e ulteriori misure di mitigazione. Dal punto di vista operativo, la risposta è stata rapida e strutturata, mentre da quello strategico il caso mette in luce una fragilità condivisa dall’intero settore. Come infatti sottolineato dagli stessi ricercatori, il problema non è specifico di AWS, ma riguarda l’architettura di fiducia implicita che governa molti flussi CI/CD moderni.

L’automazione, pilastro dello sviluppo software contemporaneo, si basa su presupposti di fiducia che spesso non vengono riesaminati con sufficiente rigore. Le pipeline sono progettate per velocizzare, non per diffidare, e quando a queste pipeline vengono concessi privilegi elevati e accesso a segreti sensibili, il confine tra produttività e rischio diventa estremamente sottile.

Il fatto poi che un attacco di questo tipo richieda competenze tecniche relativamente ordinarie rende il quadro ancora più preoccupante; è per questo che la sicurezza della supply chain non può più essere trattata come una proprietà emergente, affidata a controlli saltuari o a configurazioni ereditate. È una disciplina che richiede invece verifica continua, assunzione di fallibilità e un ripensamento profondo del modello di fiducia su cui poggia l’intero ciclo di vita del software cloud.