The report
GitHub released a public preview of workflow dependency lockfiles for GitHub Enterprise Cloud. The gh actions-lock extension generates a file of resolved commit hashes for direct actions, transitive dependencies and reusable workflows. Once a workflow is onboarded, Actions uses the recorded commits even if a referenced tag or branch moves; an administrator can additionally require lockfiles by policy.
This change addresses a real supply-chain boundary for coding agents and CI. A tool that modifies a workflow should not silently change what source code actually runs through a movable tag. The lockfile makes that target stable, but it does not assess whether a pinned dependency is malicious, compromised or fit for a task. Dependabot can update both workflow references and their lockfiles, preserving reviewable change history.
Availability is a public preview, not an across-the-board default for all GitHub repositories.
The relevance for AI coding workflows is demonstrated by the separate deployment-skill dependency case: agent-consumed instructions and build-time dependencies can introduce unexpected execution or network targets. Locked Actions commits mitigate mutable workflow dependencies; they do not validate generated application code.
What stays mutable
Pinning a resolved commit prevents a branch or tag from silently redirecting an already locked workflow to different action code. That guarantee does not extend to every input an action can download at runtime, the behavior of third-party services, container images without corresponding immutable references, or generated application artifacts. It also does not judge whether the locked commit is trustworthy. Those distinctions matter when a coding agent creates or edits a workflow: a review can compare lockfile changes, but the workflow's effective network and filesystem authority still require separate scrutiny.
This is a defense for CI dependency resolution, not a repair for every kind of skill supply-chain failure. In the Render skill incident, the unsafe value was copied into application configuration, where an Actions dependency lockfile would not have rejected it.