El 14 de octubre de 2026, GitHub abrió el acceso en vista previa pública a los lockfiles de dependencias de workflow para GitHub Actions. La función aborda un punto ciego conocido de los pipelines de CI/CD: un workflow que referencia una acción por su etiqueta (uses: owner/action@v3) puede ejecutar código distinto de una ejecución a otra si esa etiqueta se mueve, incluso tras un compromiso del repositorio de la acción. Los lockfiles fijan cada dependencia a un commit revisado, sin cambiar la sintaxis de los workflows existentes.
El problema: etiquetas que pueden moverse
En un workflow típico de GitHub Actions, las referencias por etiqueta o rama no garantizan nada sobre la estabilidad del código que se ejecuta: un mantenedor puede reasignar una etiqueta a un nuevo commit, de forma intencionada o tras una toma de control del repositorio. Es uno de los vectores de ataque a la cadena de suministro más documentados en las plataformas de CI/CD, y hasta ahora la única defensa fiable era fijar manualmente cada acción a un hash de commit, una práctica que casi nunca se mantenía actualizada.
Cómo funcionan los lockfiles
La implementación llega como una extensión del CLI de GitHub, gh actions-lock, que genera un archivo .github/workflows/actions.lock. Ese archivo registra los commits que deben usarse para cada acción, incluidas sus dependencias transitivas y los workflows reutilizables invocados. La adopción se hace workflow por workflow: una vez incorporado un workflow, todas sus dependencias deben figurar en el lockfile, y GitHub Actions ejecuta entonces exactamente los commits registrados.
gh extension install github/gh-actions-lock
gh actions-lock init
gh actions-lock verifyEl comando verify comprueba que el lockfile está actualizado sin modificar ningún archivo, lo que permite integrarlo como comprobación obligatoria en una pull request en lugar de ejecutarlo solo en local.
Dependabot y política de aplicación
Cuando Dependabot abre una actualización de versión para una acción ya bloqueada, regenera automáticamente la entrada correspondiente del lockfile en la misma pull request, sin configuración adicional. Junto a esto, una política «Require lockfile», también en vista previa pública, permite a un administrador imponer el uso de lockfiles a nivel de empresa, organización o repositorio.
| Nivel | Quién lo activa | Efecto |
|---|---|---|
| Repositorio | Administrador del repositorio | Impone el lockfile solo a los workflows de ese repositorio |
| Organización | Administrador de la organización | Impone el lockfile a todos los repositorios de la organización |
| Empresa | Administrador de la empresa | Impone el lockfile a todas las organizaciones vinculadas |
Bloquear una dependencia fija una revisión concreta, pero no garantiza que esa revisión sea segura: la revisión del código sigue siendo responsabilidad del equipo que la adopta.
github/gh-actions-lock.La adopción sigue siendo voluntaria mientras un administrador no active la política «Require lockfile», lo que da tiempo a los equipos para migrar primero sus workflows más sensibles, normalmente los que tocan el despliegue o la publicación de paquetes. Para un equipo que ya practica el endurecimiento sistemático de sus entornos de producción, el lockfile de workflow encaja en la misma lógica: reducir la superficie de ataque eliminando las referencias móviles en lugar de vigilarlas después.
Puesta en marcha
La extensión se instala desde el repositorio público github/gh-actions-lock, junto al resto de herramientas de línea de comandos que los equipos ya usan en el día a día del desarrollo web. Tras la generación, el lockfile y los cambios de workflow que conlleva deben revisarse y confirmarse como cualquier otro cambio de configuración de CI.
Para quedarse con esto
- Los lockfiles de workflow fijan cada acción de GitHub Actions a un commit concreto, en lugar de una etiqueta o rama que puede moverse.
- La adopción se hace workflow por workflow mediante la extensión
gh actions-lock, con una comprobación integrable en CI. - Dependabot regenera automáticamente las entradas del lockfile durante las actualizaciones de versión.
- Existe una política de aplicación en tres niveles, pero sigue siendo opcional hasta que un administrador la active.
- El bloqueo protege frente al desplazamiento de una etiqueta, no frente a una dependencia ya maliciosa en el momento en que se fija.
Este tipo de función debería haber existido desde hace tiempo: fijar una acción a un hash de commit es una buena práctica conocida desde hace años, pero casi nadie la mantiene a mano. Automatizar el bloqueo y vincularlo a Dependabot cambia las reglas del juego, siempre que los equipos activen de verdad la política de aplicación en lugar de dejar el lockfile como una opción que todos olvidan. — Simon Janvier
Para profundizar: el anuncio oficial en el changelog de GitHub.
