Cosa proteggono le release immutabili nei workflow di GitHub Actions

Dal 2025-10-28 una release di GitHub può essere pubblicata come immutabile: il suo tag Git non può più essere spostato né eliminato. La documentazione di GitHub dice inoltre agli autori di azioni che un tag che vogliono continuare ad aggiornare, come il tag di versione principale v1, non deve essere legato a una release, e suggerisce loro di «recommend that your users specify a major version» (raccomandare ai propri utenti di specificare una versione principale). Un workflow che scrive uses: owner/action@v1 segue quell'uso documentato e previsto, e le release immutabili non lo proteggono. Abbiamo misurato ciò che il meccanismo protegge in pratica, il 2026-10-03, solo tramite l'API di GitHub:

• A: i 1.000 repository con più stelle tra i repository pubblici, non fork e non archiviati che hanno ricevuto un push negli ultimi 90 giorni (soglia: 29.565 stelle);
• B: 500 repository estratti a caso (seme 20261003) dai 20.553 repository di questo tipo con un numero di stelle compreso tra 1.000 e 5.000.

I workflow del loro branch predefinito contengono 58.690 riferimenti uses: remoti in A e 10.472 in B. Ciascuno è stato classificato come fissato tramite SHA del commit, tramite il tag di una release immutabile, tramite un tag mutabile o tramite un branch.

Dove l'autore pubblica già release immutabili, quasi nessun riferimento è protetto. Dei riferimenti tramite tag ad azioni la cui ultima release è immutabile, 312 su 6.898 (4,5%) puntano a un tag protetto in A (intervallo al 95%: 2,8–7,1%, bootstrap sui repository) e 76 su 1.564 (4,9%) in B. Quelli protetti sono concentrati: un solo repository ne contiene 68 dei 312, ed escludendo un qualsiasi singolo repository si ottiene il 3,6–4,6%. Quasi tutti gli altri sono tag di versione principale come @v7. Per 3.238 su 6.586 (49,2%) dei riferimenti non protetti in A (intervallo 43,2–56,0%), un tag di release immutabile punta già allo stesso commit, quindi passare a quel tag non cambierebbe il codice eseguito.

Azioni più usate. 28 su 50 (56,0%) dei repository di azioni usati dal maggior numero di repository in A pubblicano la loro ultima release come immutabile. Azioni proprie di GitHub: 12 su 28 (42,9%) per actions/* (sì: setup-node, setup-python, setup-go, setup-java; no: checkout, cache, upload-artifact, download-artifact, github-script) e 3 su 6 (50,0%) per github/*.

È il fissaggio tramite SHA (pinning) a garantire la protezione, in una minoranza di repository. Nel complesso, 32.978 su 58.690 (56,2%) riferimenti remoti in A sono fissati tramite SHA (intervallo 50,7–61,7%) e 4.812 su 10.472 (46,0%) in B (intervallo 29,0–60,1%; 37,7% senza il suo repository più grande, open-telemetry/opentelemetry-python, che contiene 1.392 riferimenti). Il repository tipico ne fissa pochi: la mediana per repository della quota fissata tramite SHA è del 5,0% in A e dello 0,0% in B. Tutti i riferimenti remoti scritti nei file dei workflow sono fissati tramite SHA al massimo in 263 repository su 891 (29,5%) in A, e in 174 su 891 (19,5%) se si escludono gli 89 che chiamano anche azioni locali che non abbiamo letto; in B, al massimo in 65 su 398 (16,3%), oppure in 55 su 398 (13,8%). Tag immutabili: 0,6% dei riferimenti in A, 0,8% in B.

Il blocco delle dipendenze a livello di workflow (workflow-level dependency locking), annunciato il 2026-03-26 con «Public preview 3-6 months» (anteprima pubblica entro 3-6 mesi), al 2026-10-03 non era ancora disponibile: le relative voci della roadmap sono aperte, e nessuna voce del changelog né il riferimento della sintassi dei workflow lo documentano. Questi dati descrivono la situazione prima del suo rilascio.

Lavori precedenti. datosh/pinned-actions monitora il fissaggio tramite SHA nei 10.000 repository con più stelle («only 7%» [solo il 7%] fissa tutto, aprile 2026; 506 su 6.290 repository che usano Actions, 8,0%, nel suo archivio) e ad aprile 2026 ha aggiunto un controllo dell'immutabilità dell'ultima release; joshjohanning/ensure-immutable-actions (dal 2025-11) controlla se i riferimenti dei workflow usano release immutabili. Alcuni articoli hanno misurato nel 2022 un fissaggio tramite SHA dell'1–2% dei riferimenti; NDSS 2026 ha rilevato un 16,2% di repository che fanno riferimento a ogni azione di terze parti tramite SHA o tramite un tag di un creatore verificato. Il nostro 29,5% differisce dall'8,0% di datosh soprattutto per la popolazione (i primi 1.000 con attività recente, non i primi 10.000) e per la data; le prime 1.000 voci dello stesso datosh danno 100 su 781 (12,8%). Per quanto abbiamo potuto trovare, H1 (quanti riferimenti tramite tag sono protetti dalle release immutabili) e il 49,2% con un tag immutabile sullo stesso commit non erano stati misurati. Articolo e fonti: https://easybyte.es/lab/studies/s18/paper/.

Automazione e revisione. Agenti di IA hanno condotto lo studio e scritto il testo. Un revisore IA indipendente ha verificato il lavoro; le sue osservazioni sono state applicate (METHOD.md, sezione Deviations).

Conflitto di interessi. EasyByte sviluppa attest-lint e potrebbe rilasciare scripts/uses_check.py, il classificatore usato qui, come strumento gratuito. A differenza di ensure-immutable-actions, che suggerisce di fissare tramite SHA, per ogni tag spostabile indica il tag di release immutabile sullo stesso commit.