Nel 2026 una campagna di attacco alla supply chain ha mostrato quanto sia fragile la sicurezza delle pipeline CI/CD quando si fa affidamento su componenti di terze parti non bloccati in modo rigoroso. Due GitHub Actions molto usate per automatizzare la gestione di issue e commenti sono state disabilitate nuovamente dopo essere tornate accessibili online per alcune ore.
Il punto critico non è stato solo il ripristino dei repository, ma il fatto che i tag di rilascio continuavano a puntare a contenuti malevoli introdotti mesi prima. In pratica, qualunque workflow che richiamava quelle Actions tramite un tag di versione ha ripreso automaticamente a scaricare ed eseguire il payload alla prima esecuzione successiva.
Il codice dannoso era stato inserito il 18 maggio 2026 e aveva come obiettivo il furto di credenziali e segreti presenti nelle pipeline, con successiva esfiltrazione verso un server controllato dagli attaccanti. Questo tipo di attacco è particolarmente pericoloso perché sfrutta la fiducia implicita negli strumenti di automazione e colpisce nel momento in cui i segreti sono disponibili in memoria o nelle variabili di ambiente, spesso con privilegi elevati su repository e ambienti di build.
La riattivazione dei repository a metà settembre ha evidenziato un rischio spesso sottovalutato nella sicurezza software: i tag sono mutabili e possono essere reindirizzati a contenuti diversi nel tempo. Se un progetto usa una GitHub Action con un riferimento del tipo nome-action@v2 o v2.2.1, sta delegando la propria sicurezza allo stato corrente del repository upstream. Non serve un nuovo exploit, non serve nuova infrastruttura, non serve una modifica del workflow. Basta che quel riferimento torni raggiungibile e contenga ancora codice compromesso.
Per ridurre l’esposizione, le buone pratiche di sicurezza CI/CD includono:
- Pinning a commit SHA noto e verificato.
- Rotazione immediata dei secrets potenzialmente esposti.
- Audit dei log di esecuzione per individuare run anomale o improvvisamente riuscite dopo periodi di errori.
- Controllo della cronologia del repository per commit inattesi.
- Rimozione o sostituzione di Actions non essenziali, privilegiando fornitori affidabili e revisioni periodiche delle dipendenze di automazione.