La etiqueta revisada no es el código que corre: lockfiles en Actions

Revisas un pull request que añade uses: some-org/deploy-action@v4 a un workflow. La acción parece correcta, la apruebas y se ejecuta. Un mes después el mismo workflow vuelve a correr, sigue apuntando a v4 y ejecuta código que nadie de tu equipo ha leído. En tu repositorio no cambió nada. Lo que se movió fue la etiqueta. El 14 de octubre de 2026 GitHub lanzó en vista previa pública los lockfiles de workflow para cerrar justo ese hueco, y están disponibles en los planes Free y Team además de Enterprise Cloud.

Por qué un workflow revisado no es una ejecución revisada

Las etiquetas y las ramas se pueden mover después de revisar un workflow. GitHub describe el riesgo sin rodeos: si una acción está comprometida, una etiqueta o rama movida puede meter código malicioso en tus ejecuciones sin ningún cambio en tu repositorio. El historial de diffs sigue limpio, la protección de rama nunca salta y el cambio solo existe en el repositorio de otra persona. Para un workflow que guarda una clave de despliegue o un token de registro, eso es lo único que importa.

Qué fija el lockfile

Según GitHub, el lockfile te deja mantener referencias legibles como @v4 en el workflow mientras Actions ejecuta los commits exactos que bloqueaste. Se genera con la extensión gh actions-lock de GitHub CLI, que escribe .github/workflows/actions.lock con commits revisables para tus acciones, sus dependencias transitivas y las dependencias de los workflows reutilizables que llamas. Si la etiqueta se mueve después, GitHub dice que la ejecución sigue usando el commit registrado.

En qué se diferencia de fijar SHA a mano

La solución manual de siempre, como práctica general, es escribir el SHA completo de 40 caracteres del commit en la línea uses:. Funciona, pero cuesta leerlo, es fácil olvidarse de actualizarlo y solo fija la acción que nombraste. Si esa acción es compuesta y llama a otras acciones por etiqueta, esas referencias internas siguen pudiendo moverse. El lockfile cubre esa capa transitiva. Y con Dependabot, según GitHub, una actualización de versión de una acción en un workflow ya incorporado regenera la entrada correspondiente del lockfile en el mismo pull request, de modo que el pin y la actualización se revisan juntos.

Adoptarlo sin un cambio de golpe

La extensión de GitHub permite incorporar los workflows de uno en uno. Una vez incorporado, un workflow tiene que tener entradas en el lockfile para sus dependencias, y sus ejecuciones usan los commits registrados. La misma extensión puede detectar un lockfile desactualizado sin modificar archivos, lo que encaja con un paso de CI que haga fallar el pull request cuando el lock se quede atrás. Los administradores a nivel de repositorio, organización o empresa también pueden activar la política "Require lockfile", igualmente en vista previa pública.

Un primer paso práctico: elige el workflow de tu repositorio que guarda el secreto más delicado, normalmente el de despliegue, ejecuta gh actions-lock sobre él, lee los commits que registra y añade a la CI la comprobación de lockfile desactualizado. Luego pasa al siguiente workflow. GitHub agradece a Andrew Nesbitt, François Proulx, Jesse Houwing y William Woodruff su colaboración en la función. Fuente: GitHub Changelog, workflow lockfiles in public preview.