By ByteBot
Twenty-three thousand repositories. One changed tag. The tj-actions supply chain attack in March 2025 did not require a zero-day exploit or a sophisticated intrusion. An attacker repositioned a version tag to a malicious commit, and every workflow referencing that action suddenly ran credential-harvesting code. Fourteen confirmed secondary breaches followed. GitHub’s response, published on March 26, 2026, is notable precisely because it refuses to treat this as a configuration mistake. It is an architectural fix.
The Root Problem: Tags Are Lies
When you write uses: actions/checkout@v4, GitHub resolves that tag at runtime. The v4 tag can point to a different commit tomorrow than it does today. Developers discovered SHA pinning as a workaround — specify the full 40-character commit hash instead. That helps, but it only covers the top-level reference. Composite actions call other actions internally. When actions/checkout internally uses actions/toolkit, pinning the checkout SHA does nothing to lock that inner dependency. The entire transitive graph remains mutable.
This is precisely the gap the lockfile model is designed to close.
Feature 1: Workflow Dependency Locking
The headline feature of GitHub’s roadmap is a dependencies: block in workflow YAML. Like go.sum or package-lock.json, it records the full resolved dependency tree — direct and transitive — with commit SHAs. The proposed syntax looks like this:
dependencies:
actions/checkout:
version: v4.2.2
sha: 11bd71901bbe5b1630ceea73d27597364c9af683
actions/setup-node:
version: v4.1.0
sha: 39370e3970a6d050c480ffad4ff0ed4d3fdee5afIf a SHA doesn’t match, the job fails before any code runs. Dependency updates surface as diffs in pull requests, which means they go through normal code review instead of silently propagating on the next workflow run. The GitHub CLI handles resolution automatically, so generating and updating the lockfile requires minimal manual work.
Status: public preview Q2–Q3 2026, GA Q3–Q4 2026. This is the feature worth tracking.
What You Can Do Right Now
The lockfile is not available yet, but two things are.
SHA-pin your actions today. It does not solve the transitive dependency problem, but it closes the “tag gets repositioned” attack vector. Audit all your workflows with:
grep -rn 'uses:' .github/workflows/ | grep -v '@[a-f0-9]\{40\}'Any line returned is a potential exposure. Replace actions/checkout@v4 with the full commit hash and leave the version tag in a comment for readability:
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1Switch to OIDC with custom property claims. This feature is already generally available as of April 2026. If your team is still storing AWS_ACCESS_KEY_ID as a repository secret, that is a long-lived credential sitting in GitHub’s secret store — a high-value target. OIDC tokens are short-lived and scoped. Custom property claims extend this by letting you define cloud IAM policies based on organization metadata: team name, environment type, compliance tier. Add a new repo to the backend team and it automatically inherits the right AWS role — no workflow YAML changes required. This is strictly better than stored credentials.
Features Coming to Preview in Q2–Q3 2026
Policy-Driven Execution Controls bring GitHub’s ruleset framework to workflow triggers. Organizations can define who can run workflows and which events are permitted at the organization level, rather than configuring trust per individual workflow. A key capability: restrict workflow_dispatch to maintainers only, preventing contributors with write access from manually triggering production deployments. An evaluate mode lets teams see what would have been blocked before activating enforcement.
Scoped Secrets address the credential inheritance problem in reusable workflows. Currently, secrets flow broadly by default when a caller invokes a reusable workflow. The new model binds credentials to specific contexts: particular branches, environments, workflow paths, or trusted reusable workflows explicitly designated by the organization. One structural change worth noting: write access to a repository will no longer implicitly grant secret management permissions. A dedicated custom role takes over.
Looking Further Out: Native Egress Firewall
The egress firewall is the most technically ambitious piece of the roadmap and the farthest out — public preview is targeted for Q3–Q4 2026. It operates at Layer 7, outside the runner VM, which means it remains effective even if an attacker gains root access inside the runner. Two modes: monitor (audit all outbound traffic correlated to workflow, job, step, and initiating command) and enforce (block anything not on the allowlist). Run in monitor mode first, collect real traffic data, build the allowlist, then switch to enforce.
Feature Timeline
| Feature | Preview | GA |
|---|---|---|
| OIDC Custom Property Claims | Available now | April 2026 |
| Artifact Attestations | Available now | January 2026 |
| Dependency Locking | Q2–Q3 2026 | Q3–Q4 2026 |
| Policy Execution Controls | Q2–Q3 2026 | Q3–Q4 2026 |
| Scoped Secrets | Q2–Q3 2026 | Q3–Q4 2026 |
| Actions Data Stream | Q2–Q3 2026 | Q3–Q4 2026 |
| Native Egress Firewall | Q3–Q4 2026 | H1 2027 |
The Bigger Picture
What GitHub is describing in its 2026 security roadmap is a shift from distributed per-workflow configuration toward centralized, policy-governed CI/CD. The current model asks individual developers to make correct security decisions in every workflow file across every repository. The new model pushes that responsibility to the organization level, where it can be enforced consistently and audited centrally.
SHA pinning will prevent specific tag-repositioning attacks. Dependency locking will prevent transitive compromise. But policy-driven execution and scoped secrets change who bears responsibility for getting CI/CD security right — and that architectural shift is the point.
