E' notizia proprio di questi giorni quella riguardante diversi attacchi alla supply chain delle GitHub Action che, in particolare, ha visto colpite tj-actions/changed-files (per elencare i file cambiati in un commit) e reviewdog/actions-setup (per inizializzare il tool di code review). La tipologia di attacco è la medesima, passata inizialmente inosseravata tramite il merge di qualche PR o di versioni generate da fork dei repository originali, ha colpito ed estratto secret in diversi repository.

La domanda a questo punto sorge spontanea: come ci difendiamo?

La risposta a questa domanda non è facile, come d'altronde non è semplice il mondo che gira attorno alla security. Tuttavia, possiamo intervenire con diverse azioni. La prima azione utile, è quella di bloccare tutte le GitHub Action di cui la provenienza è incerta e non verificabile:

Tutte le GitHub Action rilasciate da GitHub stessa, oppure da partner verificati, ci consentono di avere un livello aggiuntivo di sicurezza su ciò che ci portiamo dentro i nostri repository. Se vogliamo essere ancora più stringenti, possiamo tuttavia limitare completamente il comportamento e farci tutte le Action custom.

In aggiunta, non dovremmo mai utilizzare le GitHub Action puntando ad un tag o, peggio, ad una versione non specificata:

- uses: actions/checkout@v4
  with:
    ref: 'main'

Questo perchè le Action usano comunque semantic versioning (quindi X.Y.Z), pertanto indicare la v4 in termini generici come in questo caso, significa che potrà essere usata l'ultima versione rilasciata della major 4. Ad ogni run del workflow, quindi, potrebbe essere utilizzata una action differente (4.0.0, 4.0.1, 4.1.2 etc.), che potrebbe produrre risultati, o portare implicazioni di sicurezza, differenti. Questa la versione corretta:

- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
  with:
    ref: 'main'

In questo caso abbiamo puntato allo SHA del commit che corrisponde ad una versione specifica (in questo caso la 4.2.2). Poiché gli SHA dei commit sono immutabili, questo assicura che venga sempre presa la stessa versione ad ogni run.

E' sicuramente un modello differente di lavorare, in cui prestiamo maggiore attenzione alla sicurezza a fronte di un leggero effort: in questo caso la complessità sta nel trovare lo SHA relativo alla versione corretta e fare l'analisi con dei tool di sicurezza di ciò che è stato rilasciato in quella specifica versione della Action, in modo tale che un update possa andare sempre a buon fine. Non è nemmeno necessario preoccuparsi più di tanto, perchè alla fine anche Dependabot funziona con gli SHA e quindi le proposte arriveranno in automatico.