A workflow file can stay untouched while the code it runs changes underneath it. An action referenced as @v3 follows a tag; the tag can move. Reviewing the YAML once does not freeze that dependency.
On 14 October, GitHub announced workflow dependency lockfiles in public preview. They bring an idea familiar from application package managers into the build pipeline: record the exact versions you intend to execute, and make changes to that record reviewable.
For developers, the useful question is where that boundary ends. A lockfile can stop an upstream reference quietly changing your build. It cannot decide whether the code you locked deserves your trust.
What actually gets locked
GitHub's lockfile documentation describes .github/workflows/actions.lock, generated by the gh actions-lock CLI extension. It records commits and the numeric identities of their source repositories. Once a workflow is onboarded, Actions executes its locked commits and requires entries for its action dependencies.
Coverage includes transitive action dependencies, with an important boundary: a called reusable workflow's dependencies belong to the lockfile in the repository defining that workflow. A caller's lockfile does not replace that repository's responsibilities.
Think of a build that checks out code, installs dependencies and uploads an artefact. Each action is executable software with its own upstream history. A familiar name and a short version label are convenient, but neither explains every piece of code that will run.
The practical gain is a clearer review surface. A dependency update becomes a change to examine alongside the workflow, rather than an upstream tag movement you might never notice.
Start with a small, inspectable change
A sensible pilot is one ordinary test workflow. Leave the release pipeline alone until the team understands the generated diff and how updates will be maintained.
GitHub's setup guide supports onboarding a single workflow. It also warns that generation can change workflow references, not just add the lockfile. Review the whole diff, check action allowlists, and investigate unexpected repository-identity changes. Generate the file with the tool rather than editing it manually.
Useful questions for that first pull request are straightforward: which code is newly fixed in place? Who maintains it? Does the workflow still need every dependency? Can a reviewer explain an unexpected addition?
Then give updates an owner. GitHub says Dependabot can regenerate matching lockfile entries when updating actions in an already-onboarded workflow. Its Actions update configuration makes the update cadence explicit. Locking an old version indefinitely simply makes an old version more repeatable.
A lock is one control, not the whole review
GitHub's secure-use guidance still calls for minimum token permissions, careful handling of untrusted inputs and scrutiny of action source code. Those controls address different failure modes. An exactly pinned action can still be malicious, vulnerable or granted more access than its job needs.
There is another boundary worth keeping visible: a workflow lockfile covers action dependencies. It is not a promise that every external input to a build has become reproducible. As an engineering review exercise, inspect shell commands that fetch code, container references and package-install steps separately. Decide which of those inputs need their own versioning or verification.
This connects with last week's question about useful code review: what matters is whether a control helps people identify and resolve a concrete problem. Here, the problem is unexpected dependency drift; the review still needs to assess the dependency itself.
The feature is a public preview, so its tooling and behaviour may change. A measured trial can establish what it covers in your pipeline before broader enforcement. Success means being able to explain what the build will execute, how that changed, and who reviewed the decision.
Cover: original AI-generated editorial illustration.
