Tag mobili e fork bomb CI: due errori che hanno bruciato segreti e minuti runner

Novanta minuti per accorgersene: un tag mobile ha letto $GITHUB_TOKEN e ha pushato codice su un branch ignorato dai più¹. La stessa settimana, una coda di 1.100 job ha divorato settimane di minuti runner in sei ore, senza un test rosso a segnalarlo¹.

Il primo incidente nasce da un’azione non pinnata. some-org/setup-toolchain@v1 non puntava a uno SHA. Il tag è cambiato, la nuova versione ha eseguito uno script post-install, ha letto il token predefinito e ha effettuato un push remoto. Un reviewer ha notato un nome di step diverso e ha fermato tutto dopo novanta minuti. Molti team non hanno quel margine¹.

Il secondo episodio è una tempesta di concorrenza. Ogni push su un branch di pull request avviava una matrice completa. Nessuna run veniva cancellata. Un contributore ha fatto partire un loop di force-push notturno. La coda è salita a 1.100 job. I minuti Linux sono costati cari, anche se le build erano verdi¹.

Questi guasti non emergono nei workflow di esempio. Esplodono quando il CI tocca sistemi reali. L’integrazione di citrolabs/ego-lite, un toolkit che consegna sessioni di browser già loggate a processi agent, ha imposto una revisione dell’architettura del pipeline¹.

La proposta è netta: separare i domini di fiducia. Il gate delle pull request è input non affidabile. Qui si lavora con permessi in sola lettura e senza segreti. Le esecuzioni fidate vivono altrove, in una zona separata e con criteri propri¹.

La lezione operativa del primo incidente è semplice: pinnare le azioni a uno SHA. Un tag è un alias, può spostarsi senza preavviso. Un hash blocca il contenuto eseguibile. In un contesto dove un’azione può leggere $GITHUB_TOKEN, questa scelta distingue tra controllo e speranza¹.

Dal secondo incidente arriva un altro principio: gestire l’inerzia delle code. Se ogni push accende una matrice completa e niente cancella il superfluo, un banale errore umano può saturare la capacità in poche ore. Il costo arriva anche quando tutto passa a verde. I log rumorosi non rimpiazzano una politica di cancellazione delle run obsolete¹.

Un dettaglio ha tradito il primo problema: il nome di uno step cambiato. La difesa non è l’attenzione del singolo. Serve ridisegnare la superficie d’attacco del pipeline, riducendo ciò che un componente di terzi può toccare. Strumenti che forniscono sessioni browser già loggate, come citrolabs/ego-lite, allargano il perimetro operativo del CI e aumentano l’urgenza di questa separazione¹.

Chi gestisce CI può agire oggi. Spostare segreti e permessi fuori dal gate PR azzera il rischio che un tag mobile li legga. Limitare la matrice su eventi rumorosi e chiudere in automatico le run superate blocca la crescita delle code. Entrambe le mosse costano poco, e prevengono le due classi di incidenti viste sopra¹.

Checklist immediata: pin delle azioni a SHA; nessun segreto nel gate PR; permessi in sola lettura sul contesto non fidato; cancellazione automatica delle run obsolete; matrici ridotte su push frequenti; monitoraggio di coda e minuti consumati¹.