GitHub Actions Gets a Lockfile: Workflow Dependency Locking in Preview

GitHub Actions has never had a lockfile. Every other serious package ecosystem does — npm has package-lock.json, Go has go.sum, Cargo has Cargo.lock — but your CI/CD pipeline has been pinning actions with mutable git tags since day one. That changes this week. GitHub moved workflow dependency locking into technical preview, and the feature is exactly what it sounds like: a dependencies: section that locks every action your workflow uses to a specific commit SHA with cryptographic hash verification.

Why Mutable Tags Are a Real Problem

When your workflow says uses: actions/checkout@v4, GitHub’s runner resolves that tag at execution time — every single run. If someone with push access force-pushes a different commit to the v4 tag, your pipeline silently runs their code. You get no alert, no diff, no indication anything changed. Your workflow log looks normal.

This is not a theoretical edge case. Three incidents in 15 months made the blast radius clear:

• tj-actions/changed-files (March 2025, CVE-2025-30066): A maintainer account was compromised. Malicious code dumped CI secrets to build logs across 23,000+ repositories before anyone noticed.
• trivy-action (March 2026): Attackers force-pushed 75 of 76 version tags in the official Aqua Security scanner action, injecting credential-stealing payloads into 10,000+ downstream workflows. Pipelines appeared to complete successfully.
• actions-cool (May 2026): Tags were redirected to an “imposter commit” not in any branch’s commit history. Credentials were exfiltrated from runner memory before the compromise was spotted.

The pattern is identical in every case: mutable tag, silent swap, no detection. And the mitigation is also identical: workflows pinned to commit SHAs were completely immune in every incident.

What Workflow Dependency Locking Does

The new feature adds a dependencies: section directly to your workflow YAML. It records the commit SHA and cryptographic hash for every action your workflow depends on — including transitive ones. A mismatch halts the run before any jobs execute — not after, not mid-run, before.

dependencies:
  actions/checkout:
    commit: b4ffde65f46336ab88eb53be808477a3936bae11
    ref: v4.3.1
    hash: sha256:a1b2c3...
  actions/setup-node:
    commit: 1d0ff469b1e4680f35b1f8cd5c4e6a8f5d1e3b2a
    ref: v4.1.0
    hash: sha256:b2c3d4...

Two things worth noting. The human-readable ref stays alongside the SHA, so reviewers can see both what the workflow asked for and what it actually resolved to. And because the lockfile lives inside the workflow YAML, every dependency change shows up as a pull request diff. There are no silent updates.

How to Try It Now

The gh actions pin CLI extension generates and maintains the dependencies: section. Install it, run it, and it walks your workflow file, resolves every action reference, and writes the locked state. You keep editing uses: refs the normal way — the tool handles SHA resolution:

gh extension install gjtorikian/gh-actions-pin
gh actions pin           # generates or updates the lockfile
gh actions pin --verify  # add this to CI to catch tampering

Dependabot integration is part of the plan. Once it lands, Dependabot will open PRs automatically when locked SHAs go stale — the same way it already handles npm and Cargo updates. You get the security without the manual upkeep.

This Is Not the Same as Manual SHA Pinning

Manually replacing every @v4 with a 40-character SHA works, and it is what security-conscious teams have been doing for years. But it does not scale. There is no tooling enforcement, no transitive dependency tracking, and no automated freshness checks. The new lockfile automates all of that and adds hash verification on top. Manual SHA pinning is a workaround. This is the actual fix.

If you are already using StepSecurity’s Harden-Runner or the third-party gh-actions-lockfile marketplace action, those still make sense — they address different parts of the problem (runtime monitoring and policy enforcement). The official lockfile feature complements them rather than replacing them.

The Companion: Native Egress Firewall

GitHub also expanded the native egress firewall preview alongside this release. It runs outside the runner VM at Layer 7, which means it stays active even if a workflow gains root access inside the runner. Swap your runner label to try it:

runs-on: ubuntu-24.04-firewall

Current caveat: roughly 15–20% runtime overhead in audit mode. Both features are targeting general availability between September and December 2026.

What to Do Now

Sign up for the technical preview via GitHub Community Discussion #194494. While you wait for access, use the gh-actions-lockfile Marketplace action or manually pin your highest-risk workflows to commit SHAs first — any workflow that handles deployment credentials, production secrets, or cloud access belongs at the top of that list.

According to GitHub’s 2026 security roadmap, the feature fills a gap that has been exploited repeatedly and predictably. The question is not whether to adopt it — it is how fast you can roll it out once it reaches general availability.