GitHub Actions Lockfiles: Review Runner Inputs

The dependency list for a deployment pipeline deserves the same attention as the application it deploys. A small workflow can fetch several actions, call a shared workflow and receive credentials that the application itself never sees.

GitHub introduced workflow dependency lockfiles in public preview on 14 October 2026. The useful change is that an action reference can resolve to a recorded commit instead of following a moving tag at execution time. Treat adoption as a dependency review exercise with a pilot, an owner and a way back.

Map the workflows before generating anything

Start with one repository that has a small, understood build. Write down which workflows publish packages, deploy infrastructure or receive production secrets. Those are different risk categories even if all the YAML lives in the same directory.

The lockfile design has an important boundary: it covers dependencies in its own repository. A called reusable workflow relies on the lockfile in the repository where that workflow is defined. Locking the caller does not complete the work for the shared workflow's dependencies.

Give shared workflow repositories their own owner and review. Otherwise the application team can complete its checklist while a central deployment dependency remains outside it.

Also distinguish an action dependency from a command inside an action. A shell step that downloads a script, an unpinned container image or a package installation can introduce additional moving inputs. The lockfile is useful evidence about the dependencies it records; it is not a complete explanation of everything the job may execute.

Run a small pilot on a branch

Use a clean working tree and a branch intended for review. The following commands install the official extension and onboard one workflow. They write local files; they do not approve those changes or merge them.

gh extension install github/gh-actions-lock
gh actions-lock .github/workflows/ci.yml
git status --short
git diff

Replace ci.yml with an existing pilot workflow. Follow GitHub's onboarding instructions for the current preview version, and record the extension version in the change record. Preview flags and file formats can change.

Review the entire generated change. The extension can rewrite workflow references and local action definitions as well as create .github/workflows/actions.lock. Ordinary git diff does not display an untracked new file, so use the status output to identify it and open the generated lockfile separately. Inspect changed action.yml files wherever they sit in the repository before approving the update.

Avoid approving a broad wildcard simply to make an allowlist error disappear. Resolve the intended repository and commit policy first. GitHub documents that allowlist matching changes to the locked commit after onboarding, so a previously accepted tag entry can require attention.

Make changes to pins a normal review event

The official extension repository documents a read-only verification mode:

gh actions-lock --verify

Run this from the repository root after onboarding. It checks more than whether a local entry exists. The offline --verify-local option checks local coverage and should not be presented as equivalent upstream verification.

When a verification failure arrives, separate three questions: did the workflow change, did the upstream reference change, or did the source repository change? Those lead to different investigations. Automatically accepting a moved reference defeats the review you introduced the lockfile to provide.

For a legitimate update, keep the upstream release notes, relevant diff and reason for adopting it beside the pull request. A maintainer's familiar name is helpful context, but it does not replace reading a change that will run with deployment access.

Enforce it after the pilot is understood

Choose a period long enough to include an ordinary dependency update and a shared workflow change. Record whether the build result, artefacts and deployment permissions remain as expected. These are checks to perform in your environment, not claims that the preview has been tested against your repositories.

Before adding an organisation-wide requirement, agree who repairs failed verification and how urgent security updates reach the lockfile. If the pilot fails, revert the complete onboarding change on the branch, including reference rewrites. Review any newly introduced enforcement policy at the same time; a reverted file should not leave the repository unable to run.

Keep the approved state and test evidence with the change record. The same discipline described in our audit evidence guide applies here: record scope, timing and the decision, so the next maintainer can understand why those commits were accepted.

References

• GitHub Changelog: Workflow lockfiles in public preview — 14 October 2026; checked 17 October 2026.
• GitHub Docs: Workflow dependency lockfiles — checked 17 October 2026.
• GitHub Docs: Locking action dependencies in a repository's workflows — checked 17 October 2026.
• GitHub: Official gh-actions-lock extension — checked 17 October 2026.