Qué protegen las versiones inmutables en los flujos de trabajo de GitHub Actions

Desde el 2025-10-28, una versión (release) de GitHub puede publicarse como inmutable: su etiqueta de Git ya no se puede mover ni eliminar. La documentación de GitHub también indica a los autores de acciones que una etiqueta que quieran seguir actualizando, como la etiqueta de versión principal v1, no debe vincularse a una versión, y les sugiere «recommend that your users specify a major version» (que recomienden a sus usuarios especificar una versión principal). Un flujo de trabajo que escribe uses: owner/action@v1 sigue ese uso documentado y previsto, y las versiones inmutables no lo protegen. Medimos lo que el mecanismo protege en la práctica el 2026-10-03, solo a través de la API de GitHub:

• A: los 1000 repositorios con más estrellas entre los repositorios públicos que no son bifurcaciones (forks) ni están archivados y que han recibido algún push en los últimos 90 días (umbral: 29.565 estrellas);
• B: 500 repositorios extraídos al azar (semilla 20261003) de los 20.553 repositorios de ese tipo que tienen entre 1000 y 5000 estrellas.

Sus flujos de trabajo de la rama predeterminada contienen 58.690 referencias uses: remotas en A y 10.472 en B. Cada una se clasificó como fijada por SHA de commit, por la etiqueta de una versión inmutable, por una etiqueta mutable o por una rama.

Donde el autor ya publica versiones inmutables, casi ninguna referencia está protegida. De las referencias por etiqueta a acciones cuya última versión es inmutable, 312 de 6898 (4,5 %) apuntan a una etiqueta protegida en A (intervalo del 95 %: 2,8–7,1 %, bootstrap por repositorios), y 76 de 1564 (4,9 %) en B. Las protegidas están concentradas: un solo repositorio reúne 68 de las 312, y al excluir cualquier repositorio individual se obtiene un 3,6–4,6 %. Casi todas las demás son etiquetas de versión principal como @v7. En 3238 de 6586 (49,2 %) de las referencias no protegidas de A (intervalo 43,2–56,0 %), una etiqueta de versión inmutable ya apunta al mismo commit, así que cambiar a ella no alteraría el código que se ejecuta.

Acciones más usadas. 28 de 50 (56,0 %) de los repositorios de acciones que más repositorios de A usan publican su última versión como inmutable. Acciones propias de GitHub: 12 de 28 (42,9 %) en actions/* (sí: setup-node, setup-python, setup-go, setup-java; no: checkout, cache, upload-artifact, download-artifact, github-script) y 3 de 6 (50,0 %) en github/*.

La fijación por SHA es la que aporta la protección, en una minoría de repositorios. En conjunto, 32.978 de 58.690 (56,2 %) referencias remotas de A están fijadas por SHA (intervalo 50,7–61,7 %), y 4812 de 10.472 (46,0 %) en B (intervalo 29,0–60,1 %; 37,7 % sin su repositorio más grande, open-telemetry/opentelemetry-python, que reúne 1392 referencias). El repositorio típico fija pocas: la mediana por repositorio de la proporción fijada por SHA es del 5,0 % en A y del 0,0 % en B. Todas las referencias remotas escritas en los ficheros de flujo de trabajo están fijadas por SHA como máximo en 263 de 891 (29,5 %) repositorios de A, y en 174 de 891 (19,5 %) si se descartan los 89 que además llaman a acciones locales que no leímos; en B, como máximo en 65 de 398 (16,3 %), o en 55 de 398 (13,8 %). Etiquetas inmutables: 0,6 % de las referencias en A y 0,8 % en B.

El bloqueo de dependencias a nivel de flujo de trabajo (workflow-level dependency locking), anunciado el 2026-03-26 con «Public preview 3-6 months» (versión preliminar pública en 3-6 meses), aún no se había lanzado el 2026-10-03: sus elementos de la hoja de ruta siguen abiertos, y no lo documenta ninguna entrada del registro de cambios ni la referencia de sintaxis de flujos de trabajo. Estas cifras describen la situación anterior a su lanzamiento.

Trabajos previos. datosh/pinned-actions sigue la fijación por SHA en los 10.000 repositorios con más estrellas («only 7%» [solo un 7 %] fija todas sus referencias, abril de 2026; 506 de 6290 repositorios que usan Actions, el 8,0 %, en su archivo) y añadió en abril de 2026 una comprobación de inmutabilidad de la última versión; joshjohanning/ensure-immutable-actions (desde 2025-11) comprueba si las referencias de los flujos de trabajo usan versiones inmutables. Varios artículos midieron en 2022 una fijación por SHA del 1–2 % de las referencias; NDSS 2026 halló un 16,2 % de repositorios que referencian todas las acciones de terceros por SHA o por una etiqueta de un creador verificado. Nuestro 29,5 % difiere del 8,0 % de datosh sobre todo por la población (los 1000 primeros con actividad reciente, no los 10.000 primeros) y por la fecha; las 1000 primeras entradas del propio datosh dan 100 de 781 (12,8 %). Hasta donde hemos podido encontrar, H1 (cuántas referencias por etiqueta quedan protegidas por las versiones inmutables) y el 49,2 % con una etiqueta inmutable en el mismo commit no se habían medido. Artículo y fuentes: https://easybyte.es/lab/studies/s18/paper/.

Automatización y revisión. Agentes de IA realizaron el estudio y redactaron el texto. Un revisor de IA independiente comprobó el trabajo; sus observaciones se aplicaron (METHOD.md, apartado Deviations).

Conflicto de intereses. EasyByte desarrolla attest-lint y podría publicar scripts/uses_check.py, el clasificador usado aquí, como herramienta gratuita. A diferencia de ensure-immutable-actions, que sugiere fijaciones por SHA, este indica para cada etiqueta movible la etiqueta de versión inmutable que apunta al mismo commit.