Abbiamo assistito recentemente alla backdoor e all'enorme problema di sicurezza introdotto nella libreria XZ utils. Questo genere di attacco si definisce "supply chain attack" e non è importante quanto tempo ci si metta per realizzarlo, ma l'effetto devastante che avrà. Questo può anche rientrare nella categoria del repo-jacking, in quanto si utilizza un repository particolarmente utilizzato, per esempio nel mondo open source, per iniettare malware, o comunque un qualsiasi genere di contenuto malevolo, che poi andrà a cambiare il comportamento originale del software di quel repository, causando danni agli utilizzatori finali.

In GitHub, per esempio, è molto probabile che facciamo uso di GitHub Actions create da terze parti. Alcune sono più affidabili di altre, in quanto hanno il "bollino" di verified creator rilasciato direttamente da GitHub (es. GitHub stesso, Microsoft, AWS etc.), poiché subiscono un processo di revisione molto stringente, in quanto devono appunto dare qualità. Altre, invece, sono semplicemente open source e di rado ci prendiamo del tempo per fare i dovuti check di sicurezza per validare quel software. Anche avendo persone dedicate, sarebbe opportuno fare dei controlli su base regolare, per verificare ogni singolo aggiornamento delle GitHub Actions e, questo, è sempre più complesso e porta via sempre più tempo.

Tuttavia, se vogliamo stare un po' più tranquilli, possiamo sfruttare una sintassi molto particolare delle GitHub Actions che ci permettono di fare locking su uno specifico commit:

steps:
- name: My Action
  uses: actions/javascript-action@4be183afbd08ddadedcf09f17e8e112326894107

Infatti, anziché usare un numero di versione (come ad esempio solo la major o il classico SemVer a tre cifre), GitHub Actions supporta anche la reference diretta sul commit SHA. Sebbene per un qualche tipo di attacco specifico sia possibile fare tampering dello SHA-1, è un caso estremamente raro. Usare questo meccanismo di linking sui commit ci garantisce una sicurezza in più, in quanto la GitHub Actions non cambierà ad ogni singola run del workflow, ma rimarrà su una versione che abbiamo avuto modo di verificare in modo opportuno con i nostri sistemi o con dei tool appositi.