A readable tag is no longer the code that runs
GitHub Actions workflows are easy to read when they say uses: actions/checkout@v6. The security problem is that a tag is a name, not an immutable object. If the tag moves after review, a later workflow run can execute different code without any change in your repository.
GitHub's 14 October 2026 lockfile release changes that trust path. An onboarded workflow can keep the readable reference in YAML while GitHub executes the exact commit recorded in .github/workflows/actions.lock. The lockfile also records transitive action dependencies and reusable workflow references, so the review boundary is wider than the top-level uses lines you can see in one workflow file.
This is useful because CI dependencies often run with repository tokens, build credentials, release authority or access to artifacts. A tag that changes upstream can therefore change privileged code without producing a local diff. A lockfile turns that hidden resolution step into repository state you can review.
The important shift is not "GitHub now pins actions for you." It is that dependency resolution becomes an explicit change that can be protected by branch rules, code ownership and CI verification.
The lockfile records code and identity
GitHub's workflow dependency lockfile documentation describes two sections: workflows and dependencies. Each dependency entry records the reference you wrote, the exact commit that resolved from it, and the numeric owner and repository identity.
Those identity fields matter. A repository name can be transferred or recreated. GitHub uses the stored owner_id and repo_id to confirm at runtime that the repository behind the dependency name is still the repository you locked. The control is therefore not only "run this SHA." It is "run this SHA from this repository identity."
The lockfile also covers actions used by other actions. That is a practical improvement over hand-pinning only the top-level workflow. A reviewed action can invoke another action internally, and that transitive dependency is part of the code your runner will execute.
There is an important boundary. Dependencies inside a reusable workflow are covered by the lockfile of the repository where that reusable workflow is defined, not by the caller's lockfile. If your organisation owns shared workflow repositories, secure those repositories too. A locked call into an unlocked reusable workflow can still leave part of the execution graph outside the caller's review process.
Move review attention to the lockfile diff
A lockfile only helps if a changed lockfile receives the same scrutiny as a changed dependency manifest.
GitHub's locking guide says the generated file should not be edited manually. The gh actions-lock extension resolves dependencies, writes the file and can verify whether it is stale. When a dependency changes legitimately, regenerate the lockfile and review the resulting diff.
The useful review question is simple: why did this commit change?
A version bump should explain the new upstream commit. A changed owner or repository identity should be rare and deserves investigation. A branch or partial version such as main or v3 does not automatically re-resolve on every run once it is locked, which is the point. Accepting a moved upstream reference requires an explicit relock step after review.
Put .github/workflows/actions.lock under CODEOWNERS. Require approval from the people responsible for build security. Add a verification check so a workflow edit cannot merge with a stale lockfile. GitHub's enforcement guide recommends piloting the policy before turning it on broadly, then keeping verification in place even after enforcement.
This makes the operational model similar to application dependencies: humans review an intended version change, automation records the exact resolved object, and policy prevents execution when the recorded state is missing or stale.
Keep updates deliberate without freezing dependencies
Pinning creates a second problem if nobody owns updates. An immutable dependency that never moves will also miss security fixes.
GitHub integrates lockfiles with Dependabot. When Dependabot updates an action version in a workflow that is already onboarded, it can regenerate the matching lockfile entry in the same pull request. That keeps the human-readable workflow reference and the exact execution commit together in one review.
The review should still separate two questions.
First, is this the upstream version you intended to adopt? Read the action release notes and inspect meaningful source changes for privileged actions.
Second, does the lockfile resolve to the expected repository and commit? The lockfile answers execution identity. It does not answer whether the new code is good.
For high-authority workflows, keep the dependency surface small. Deployment, signing and package publishing jobs should use fewer third-party actions than ordinary test jobs. Give each job the minimum GITHUB_TOKEN permissions it needs. Locking reduces dependency drift, but least privilege limits the damage if the code you deliberately locked is malicious or later discovered to be vulnerable.
Roll it out as a control, not a formatting change
Start with workflows that have the most authority, not necessarily the most dependencies.
Inventory deployment, release, signing, infrastructure and secret-bearing workflows. Onboard one of those workflows, generate the lockfile, inspect the dependency graph and add a required verification check. Run the normal pull-request path and confirm that a workflow change with a stale lockfile is rejected.
Then test the negative cases. Change an action reference without regenerating the lockfile. Confirm the verifier fails. Try a workflow that was not onboarded and confirm your policy behaves as expected. If you use shared reusable workflows, inspect whether their own repositories have lockfiles and equivalent review rules.
After the pilot, enforce the Require lockfile policy where it fits your GitHub plan and repository model. Keep the verification check because it gives the contributor feedback in the pull request, while policy enforcement protects execution.
Treat the first rollout as dependency discovery too. Transitive entries can reveal actions that were never obvious from the top-level YAML. Those are part of your build system and deserve an owner, an update path and a reason to exist.
What this does not change
A lockfile does not make an action trustworthy. GitHub says this explicitly in the release announcement: locking protects against unexpected dependency changes, but it does not determine whether the dependency itself is safe.
It also does not replace workflow permission design. A locked third-party action with broad repository write access can still do broad damage. A locked workflow triggered from an unsafe event can still execute in an unsafe context. Continue to review triggers, permissions, environments, secrets, OIDC trust and runner isolation.
Finally, this feature is in public preview, so teams should expect the mechanics and policy surface to evolve. That is another reason to keep the process simple: generated lockfile, reviewed diff, required verification, narrow permissions.
The useful outcome is narrower and concrete. After review, the code executed by an onboarded workflow no longer silently follows a mutable tag. A dependency change becomes a repository diff that somebody can inspect, approve and audit. That closes one hidden path through the CI supply chain without pretending the rest of the supply chain has disappeared.
Written by Dandelion Labs