Un tag legible ya no es el código que se ejecuta
Los workflows de GitHub Actions son fáciles de leer cuando dicen uses: actions/checkout@v6. El problema de seguridad es que un tag es un nombre, no un objeto inmutable. Si el tag cambia después de la revisión, una ejecución posterior puede correr código distinto sin ningún cambio en tu repositorio.
El lanzamiento de lockfiles del 14 de octubre de 2026 cambia esa ruta de confianza. Un workflow incorporado puede conservar la referencia legible en YAML mientras GitHub ejecuta el commit exacto registrado en .github/workflows/actions.lock. El lockfile también registra dependencias transitivas de actions y referencias a reusable workflows, por lo que el límite de revisión es más amplio que las líneas uses de un único archivo.
Esto importa porque las dependencias de CI suelen ejecutarse con tokens del repositorio, credenciales de build, autoridad de release o acceso a artefactos. Un tag que cambia upstream puede modificar código privilegiado sin producir un diff local. El lockfile convierte esa resolución oculta en estado del repositorio que se puede revisar.
El cambio importante no es simplemente que GitHub fije las actions. Es que la resolución de dependencias pasa a ser un cambio explícito que puede protegerse con reglas de rama, code ownership y verificación de CI.
El lockfile registra código e identidad
La documentación de workflow dependency lockfiles describe dos secciones: workflows y dependencies. Cada entrada de dependencia registra la referencia escrita, el commit exacto al que resolvió y la identidad numérica del propietario y del repositorio.
Esos campos de identidad importan. El nombre de un repositorio puede transferirse o recrearse. GitHub usa owner_id y repo_id para confirmar en tiempo de ejecución que el repositorio detrás del nombre sigue siendo el que fue bloqueado. Por eso el control no es solo "ejecuta este SHA". Es "ejecuta este SHA desde esta identidad de repositorio".
El lockfile también cubre actions usadas por otras actions. Es una mejora práctica frente a fijar manualmente solo las dependencias de nivel superior. Una action revisada puede invocar otra internamente, y esa dependencia transitiva forma parte del código que ejecutará el runner.
Existe un límite importante. Las dependencias dentro de un reusable workflow quedan cubiertas por el lockfile del repositorio donde se define ese workflow, no por el lockfile del repositorio que lo llama. Si tu organización mantiene repositorios de workflows compartidos, también debes protegerlos. Una llamada bloqueada hacia un reusable workflow sin lockfile puede dejar parte del grafo de ejecución fuera del proceso de revisión del caller.
Mueve la atención de revisión al diff del lockfile
Un lockfile solo ayuda si sus cambios reciben el mismo nivel de revisión que un cambio en un manifest de dependencias.
La guía de locking indica que el archivo generado no debe editarse a mano. La extensión gh actions-lock resuelve dependencias, escribe el archivo y puede verificar si quedó desactualizado. Cuando una dependencia cambia de forma legítima, regenera el lockfile y revisa el diff resultante.
La pregunta útil para la revisión es sencilla: por qué cambió este commit?
Una actualización de versión debería explicar el nuevo commit upstream. Un cambio de identidad del propietario o del repositorio debería ser raro y merece investigación. Una rama o versión parcial como main o v3 no vuelve a resolverse automáticamente en cada ejecución una vez bloqueada, que es precisamente el objetivo. Aceptar una referencia upstream que se movió requiere un paso explícito de relock después de la revisión.
Pon .github/workflows/actions.lock bajo CODEOWNERS. Exige aprobación de las personas responsables de la seguridad del build. Añade una verificación para que una edición de workflow no pueda integrarse con un lockfile desactualizado. La guía de enforcement recomienda probar la política antes de activarla de forma amplia y mantener la verificación incluso después de aplicar enforcement.
El modelo operativo se parece así al de las dependencias de aplicación: una persona revisa un cambio de versión intencional, la automatización registra el objeto exacto resuelto y la política impide ejecutar cuando el estado registrado falta o está desactualizado.
Mantén las actualizaciones deliberadas sin congelar dependencias
El pinning crea un segundo problema si nadie se hace responsable de actualizar. Una dependencia inmutable que nunca se mueve también puede perder correcciones de seguridad.
GitHub integra los lockfiles con Dependabot. Cuando Dependabot actualiza la versión de una action en un workflow ya incorporado, puede regenerar la entrada correspondiente del lockfile en el mismo pull request. Así la referencia legible y el commit exacto que se ejecutará llegan juntos a la revisión.
La revisión todavía debe separar dos preguntas.
Primero, es esta la versión upstream que querías adoptar? Lee las notas de release de la action e inspecciona los cambios de código importantes en actions privilegiadas.
Segundo, resuelve el lockfile al repositorio y commit esperados? El lockfile responde a la identidad de ejecución. No responde si el código nuevo es bueno.
En workflows con mucha autoridad, mantén pequeña la superficie de dependencias. Los jobs de deployment, signing y publicación de paquetes deberían usar menos actions de terceros que los jobs normales de test. Da a cada job solo los permisos de GITHUB_TOKEN que necesita. El locking reduce el drift de dependencias, pero el mínimo privilegio limita el daño si el código que bloqueaste deliberadamente resulta ser malicioso o vulnerable.
Despliega el control, no solo un cambio de formato
Empieza por los workflows con más autoridad, no necesariamente por los que tienen más dependencias.
Haz un inventario de workflows de deployment, release, signing, infraestructura y acceso a secretos. Incorpora uno, genera el lockfile, inspecciona el grafo de dependencias y añade una verificación obligatoria. Ejecuta el flujo normal de pull request y confirma que un cambio de workflow con lockfile desactualizado sea rechazado.
Después prueba los casos negativos. Cambia una referencia de action sin regenerar el lockfile. Confirma que el verificador falle. Prueba un workflow que todavía no fue incorporado y confirma que la política se comporte como esperas. Si usas reusable workflows compartidos, revisa si sus propios repositorios tienen lockfiles y reglas equivalentes.
Después del piloto, aplica la política Require lockfile donde encaje con tu plan de GitHub y modelo de repositorio. Mantén la verificación porque da feedback al autor dentro del pull request, mientras que la política protege la ejecución.
Usa el primer rollout también como descubrimiento de dependencias. Las entradas transitivas pueden revelar actions que nunca fueron obvias desde el YAML principal. Forman parte de tu sistema de build y necesitan un responsable, una ruta de actualización y una razón para existir.
Qué no cambia
Un lockfile no convierte una action en confiable. GitHub lo dice explícitamente en el anuncio del lanzamiento: el locking protege contra cambios inesperados de dependencias, pero no determina si la dependencia es segura.
Tampoco sustituye el diseño de permisos del workflow. Una action de terceros bloqueada con acceso amplio de escritura al repositorio todavía puede causar daño amplio. Un workflow bloqueado que se dispara desde un evento inseguro todavía puede ejecutarse en un contexto inseguro. Sigue revisando triggers, permissions, environments, secrets, confianza OIDC y aislamiento de runners.
Por último, la función está en public preview, por lo que la mecánica y la superficie de políticas pueden cambiar. Esa es otra razón para mantener el proceso simple: lockfile generado, diff revisado, verificación obligatoria y permisos estrechos.
El resultado útil es más limitado y concreto. Después de la revisión, el código ejecutado por un workflow incorporado deja de seguir silenciosamente un tag mutable. Un cambio de dependencia se convierte en un diff del repositorio que alguien puede inspeccionar, aprobar y auditar. Eso cierra una ruta oculta de la supply chain de CI sin fingir que el resto de la supply chain desapareció.
Escrito por Dandelion Labs