Le pull request malevole aumentano i rischi per i workflow di sviluppo ampiamente utilizzati

Una vulnerabilità recentemente evidenziata nei workflow CI/CD sta attirando l’attenzione sul modo in cui i progetti open source e di sviluppo cloud gestiscono i contributi al codice. Il problema riguarda le pull request malevole, che possono essere utilizzate per introdurre modifiche dannose nei processi automatizzati di build e rilascio se i controlli di revisione e convalida non sono sufficientemente efficaci.

Secondo il rapporto, la vulnerabilità dei workflow interessa diversi progetti e strumenti per sviluppatori noti, tra cui Microsoft’s Azure Sentinel, Google’s AI Agent Development Kit, Apache Doris, Workers SDK di Cloudflare e il formatter Black della Python Software Foundation. Sebbene questi progetti siano destinati a comunità e casi d’uso differenti, tutti si basano su pipeline di distribuzione del software che possono diventare obiettivi interessanti quando la fiducia nei contributori si sovrappone all’automazione.

I ricercatori di sicurezza e i maintainer hanno avvertito sempre più spesso che gli attacchi basati sulle pull request possono essere efficaci perché sfruttano le normali pratiche di collaborazione. In molti ambienti di sviluppo moderni, il codice proveniente da contributori esterni viene testato automaticamente prima dell’integrazione. Se questi controlli non sono adeguatamente isolati, un attaccante potrebbe riuscire a influenzare le fasi di build, esporre segreti o introdurre modifiche difficili da individuare durante una revisione ordinaria.

Perché il problema è importante

Anche quando una pull request non modifica direttamente i sistemi di produzione, può comunque creare seri rischi lungo tutta la catena di fornitura del software. Una compromissione nella fase di sviluppo può propagarsi ai rilasci successivi, alla distribuzione dei pacchetti e agli ambienti degli utenti.

• L’automazione può eseguire codice non attendibile durante la revisione o i test.
• Segreti, token o chiavi di firma possono essere esposti se i controlli della pipeline sono deboli.
• I progetti considerati affidabili possono diventare punti di ingresso per abusi più ampi della catena di fornitura.

Il rapporto sottolinea la necessità di adottare garanzie più solide nei workflow dei contributori, tra cui autorizzazioni più restrittive, una gestione più sicura dei segreti e un’esecuzione CI/CD maggiormente limitata per i contributi esterni. Per i team che gestiscono strumenti e infrastrutture ampiamente utilizzati, la conclusione è semplice: la comodità della collaborazione non dovrebbe mai andare a scapito della sicurezza della pipeline.