Un workflow parece sencillo: descargar el repositorio, instalar dependencias, ejecutar pruebas y publicar. Sin embargo, cada línea uses puede invocar una acción mantenida fuera de la empresa, que a su vez depende de otras. Si una etiqueta o rama cambia, el pipeline puede ejecutar código distinto del revisado, con acceso a tokens, secretos, artefactos y entornos de despliegue.
El 28 de octubre de 2026, los lockfiles de dependencias de GitHub Actions llegaron a disponibilidad general. El mecanismo mantiene referencias legibles en el workflow y registra en otro fichero el commit exacto y la identidad del repositorio que deben ejecutarse. Así se vuelve práctica una recomendación esencial: saber con precisión qué código participa en la construcción del producto.
El pipeline también forma parte del producto
Muchas empresas revisan a fondo el código de la aplicación y consideran CI/CD una configuración secundaria. El riesgo real no respeta esa división. El pipeline lee el código, inyecta credenciales, genera paquetes, firma artefactos y publica en producción. Una dependencia comprometida puede alterar el resultado sin modificar el repositorio principal.
Las etiquetas como v3 facilitan las actualizaciones, pero pueden señalar otro commit en el futuro. Una rama como main es todavía más móvil. Incluso si el mantenedor es fiable, una cuenta comprometida o una transferencia de repositorio puede cambiar lo que se ejecuta.
¿Qué registra un lockfile de workflow?
El fichero .github/workflows/actions.lock relaciona los workflows con sus dependencias. Para cada acción guarda la referencia reconocible, el commit resuelto y los identificadores numéricos del propietario y repositorio. Durante la ejecución, la plataforma comprueba que el código coincide con ese registro.
- commit exacto: evita que una etiqueta móvil cambie silenciosamente el código;
- dependencias transitivas: incluye acciones llamadas por otras acciones;
- identidad del repositorio: ayuda a detectar sustituciones por otro proyecto con el mismo nombre;
- inventario auditable: muestra qué componentes participan en cada workflow;
- cambios revisables: una actualización aparece como diff en la pull request.
El lockfile se genera mediante la extensión gh actions-lock y no se edita a mano. Cuando Dependabot actualiza una acción en un workflow incorporado, puede regenerar la entrada correspondiente.
¿Es mejor que fijar el SHA en YAML?
Fijar cada acción a un SHA completo sigue siendo útil, pero reduce legibilidad y no ofrece una vista central de relaciones transitivas. El lockfile deja que el workflow muestre una versión comprensible mientras la ejecución usa el commit aprobado. También registra la identidad del repositorio y facilita actualizaciones automatizadas con revisión.
No elimina todas las referencias fijas. Los workflows reutilizables llamados a nivel de job tienen reglas propias y pueden requerir un SHA completo o un lockfile en el repositorio donde se definen. La arquitectura debe contemplar las fronteras reales de la herramienta.
Ejemplo: despliegue de una aplicación comercial
Un equipo mantiene backend, panel web y app móvil. Su workflow utiliza acciones para checkout, configuración del runtime, caché, análisis de seguridad, carga de artefactos y despliegue en la nube. Antes, seis referencias por etiqueta ocultaban dependencias transitivas adicionales.
Durante el piloto, la empresa genera el inventario, confirma los repositorios de origen y revisa los commits actuales. El lockfile entra en la misma pull request que habilita el primer workflow. Una regla exige aprobación del equipo de plataforma para cualquier cambio en el fichero. Dependabot abre actualizaciones separadas con versión legible y nuevo commit.
Una semana después, el mantenedor mueve la etiqueta de una acción. El pipeline sigue ejecutando el commit aprobado. El equipo recibe la actualización como un cambio explícito, revisa el diff y decide cuándo avanzar. La entrega se mantiene estable sin congelar el ecosistema.
Lo que un lockfile no resuelve
Fijar una dependencia no demuestra que sea segura. Si el commit ya contiene código malicioso, el lockfile solo garantiza una ejecución consistente. Tampoco controla parámetros, scripts de shell, imágenes de runner, paquetes instalados durante el job, secretos expuestos o permisos excesivos.
- revisa la acción antes de fijarla;
- trata un cambio de commit como un cambio de código;
- comprueba workflows reutilizables y acciones locales;
- mantén el fichero al día y bloquea versiones obsoletas;
- no aceptes automáticamente una referencia movida;
- prueba la adopción antes de activar una política que bloquee ejecuciones.
Controles que completan la protección
Permisos mínimos y credenciales temporales
Define permisos del token por job y usa OIDC para obtener credenciales temporales del proveedor cloud. Un pipeline fijado, pero con una clave administrativa permanente, sigue siendo peligroso. Nuestro artículo sobre secretos y claves API profundiza en este riesgo.
CODEOWNERS y reglas de aprobación
Incluye workflows y lockfiles en el alcance de propietarios de código. Los cambios en la cadena de construcción deben ser revisados por personas que comprendan seguridad de entrega, no solo por quienes desarrollan la funcionalidad.
Procedencia y atestaciones
Los lockfiles controlan parte de las entradas; las atestaciones vinculan el artefacto con su origen y proceso de construcción. Marcos como SLSA ayudan a organizar controles para evitar manipulaciones y verificar lo producido.
Entornos y despliegues protegidos
Separa construcción de despliegue, limita entornos, exige aprobación para producción y valida el artefacto que se promociona. Recompilar en cada entorno rompe la cadena de evidencias.
Cómo adoptarlo en varios repositorios
- Inventaría: workflows, acciones externas, reutilizables, permisos y secretos.
- Prioriza: pipelines que publican artefactos o acceden a producción.
- Genera y revisa: crea lockfiles, confirma el origen y evalúa cada commit.
- Automatiza actualizaciones: configura Dependabot y verificación de obsolescencia.
- Protege el diff: aplica CODEOWNERS y reglas de rama.
- Evalúa la política: observa antes de convertir el lockfile en obligatorio.
- Mide y amplía: controla cobertura, fallos y tiempo de actualización.
Un programa corporativo necesita excepciones con fecha de caducidad. Repositorios heredados o acciones internas pueden requerir una migración gradual. Documentar motivo, responsable y revisión es mejor que imponer una política imposible.
Métricas para seguridad sin fricción
Mide el porcentaje de workflows cubiertos, las dependencias transitivas inventariadas, referencias móviles pendientes, lockfiles obsoletos y tiempo medio para aplicar actualizaciones de seguridad. Vigila también falsos bloqueos, duración del pipeline y número de excepciones.
El objetivo no es maximizar ficheros. Es reducir cambios invisibles y permitir que los equipos actualicen componentes con evidencias. Una política que paraliza entregas termina rodeada; una integrada en la pull request se convierte en ingeniería cotidiana.
De automatización cómoda a entrega verificable
Los lockfiles de CI/CD convierten dependencias implícitas en un contrato revisable. No sustituyen análisis, gestión de secretos, procedencia ni pruebas, pero cierran la distancia entre “lo que hemos leído” y “lo que realmente se ejecuta”.
ProativaIA desarrolla software a medida, aplicaciones y automatizaciones con pipelines seguros y observables. Podemos mapear tu cadena de entrega, modernizar CI/CD y aplicar controles graduales sin convertir cada publicación en un proceso manual.