GitHub Actions has lockfiles now, and pull_request_target gets blocked on Dec 2: 7 workflow changes to catch in review in 2026

GitHub made Actions workflow lockfiles generally available on October 28 and announced that pull_request_target events will be blocked by default in public repositories starting December 2, with brownouts on November 9 and 16. The lockfile feature, run via the gh actions-lock CLI extension, writes .github/workflows/actions.lock recording commit SHAs for actions and their transitive dependencies while workflows keep readable tags, and admins can enforce a Require lockfile policy at enterprise, organization or repository level. GitHub notes lockfiles "don't determine whether a dependency is safe" and that private and internal repositories and GitHub Enterprise Server are out of scope for the pull_request_target block.

GitHub Actions security got two real changes in about a week, and both of them end up in review work. Workflow lockfiles went generally available on October 28. On November 2, GitHub said pull request target will be blocked by default in public repositories from December 2. Neither change does the reviewing for you. GitHub says so directly in the lockfile announcement: lockfiles "don't determine whether a dependency is safe. Review dependencies before locking them." So I treat .github/workflows/ and actions.lock as code, the same as anything else that runs with secrets. Workflow files belong on the same secure code review checklist https://dev.to/dev barron/secure-code-review-how-it-differs-from-everyday-code-review-with-a-checklist-43k4 as the app. The goal is the usual one: agent-generated code merged sooner with fewer rollbacks, including the YAML your coding agent happily edits alongside the app. Workflow lockfiles are available on GitHub Enterprise Cloud including data residency , Team and Free, per the GA changelog https://github.blog/changelog/2026-10-28-github-actions-workflow-lockfiles-are-generally-available/ . You run the gh actions-lock CLI extension, and it writes .github/workflows/actions.lock for your actions and their transitive dependencies. Your workflow files keep readable tags like @v7.0.1 . The runner executes the commit recorded in the lockfile, even if somebody moves the tag later. You can onboard one workflow at a time, and Dependabot regenerates the matching lockfile entry in the same PR when it bumps an action. Admins also get a Require lockfile policy at enterprise, organization or repository level. One scope note: the gh-actions-lock README https://github.com/github/gh-actions-lock says GitHub Enterprise Server isn't supported. From December 2, pull request target events are blocked by default in public repositories unless an Actions event policy explicitly allows them, per the November 2 changelog https://github.blog/changelog/2026-11-02-pull request target-blocked-by-default-december-2/ . Enforcement was first scheduled for November 2, then moved in an October 21 editor's note on the workflow execution protections changelog https://github.blog/changelog/2026-09-17-workflow-execution-protections-in-github-actions-generally-available/ . The scope matters, so here it is plainly. The block applies to public repositories on Free, Team and Enterprise Cloud. Private and internal repositories aren't affected, and GitHub Enterprise Server is out of scope. An applicable event policy you already configured isn't replaced by the default. GitHub ran a brownout on November 9 and runs another on November 16, from 16:00 to 18:00 UTC 4 to 6 PM in London . During a window, blocked runs fail with an error annotation and don't execute. After each window, the rule goes back to evaluate mode. | Change | Date | Who is affected | What to look at in the PR | |---|---|---|---| | Workflow lockfiles GA | Oct 28, 2026 | GHEC, Team, Free not GHES | actions.lock diffs and rewritten uses: lines | | pull request target default block | Dec 2, 2026 brownouts Nov 9 and 16 | Public repos only | The trigger, checkouts and policy exceptions | Hugo van Kemenade's walkthrough from November 11 https://hugovk.dev/blog/2026/lock-github-actions/ made the Hacker News front page, and his diff is a good one to read. Before locking, his workflow pinned full SHAs with a version comment. After running gh actions-lock , the uses: lines read like tags again: - - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 v7.0.1 + - uses: actions/checkout@v7.0.1 The SHA didn't disappear. The new lockfile records it, with the ref and the numeric identity of the source repository: dependencies: 'actions/checkout@v7.0.1': ref: 'v7.0.1' commit: 'sha1-3d3c42e5aac5ba805825da76410c181273ba90b1' owner id: 44036562 repo id: 197814629 When I review a PR like Hugo's, the first check is simple: the SHA that left the workflow file should be the commit that landed in the lockfile. GitHub's lockfile enforcement guide https://docs.github.com/en/actions/how-tos/administer/enforce-workflow-lockfiles puts the stakes in one line: "A lockfile is only a security control if someone reads the diff." The pull request target trigger runs with the base repository's GITHUB TOKEN and access to its secrets, per GitHub's guide to using pull request target securely https://docs.github.com/en/actions/reference/security/securely-using-pull request target . Labeling, triage and authenticated status checks on fork PRs are the legitimate reasons to use it. If a job needs neither secrets nor a write token, pull request fires on the same events and the December 2 rule doesn't touch it. My review question for any PR that adds or keeps the trigger: what does this job actually need secrets for? The classic pwn request has two steps. A pull request target workflow points actions/checkout at the fork's code, then runs something from it, like make test or npm install . GitHub's docs note that the checkout alone doesn't execute anything; the step after it does. Since June 2026, actions/checkout v7 refuses the common fork patterns by default, per the checkout changelog https://github.blog/changelog/2026-06-18-safer-pull request target-defaults-for-github-actions-checkout/ . The opt-out is an input called allow-unsafe-pr-checkout , which GitHub says is "intentionally named to be easy to spot in code review." I'd treat seeing it in a diff as a mandatory conversation. The same changelog lists what v7 doesn't cover: a run: step that fetches the PR with git or gh , other events such as issue comment , and checkouts of unrelated repositories. A human still has to read the workflow for those cases. on: pull request target jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7.0.1 with: ref: ${{ github.event.pull request.head.sha }} allow-unsafe-pr-checkout: true flag this in review - run: make test runs fork code with secrets Onboarding rewrites references to the exact version it resolved, so @v3 can become @v3.1.0 . GitHub's locking how-to https://docs.github.com/en/actions/how-tos/secure-your-work/lock-workflow-dependencies says the extension "changes more than the lockfile, so review the full diff before you commit." The same page has a warning I'd have missed. Once a workflow is onboarded, an allowed-actions list is checked against locked SHAs, not tags. An allowlist entry like actions/checkout@v6 stops matching. If a lockfile PR lands, I'd ask whether the allowlist changed with it, and who approved that. A changed commit is the code your workflows will run, so treat it like any other dependency bump, as GitHub's enforcement guide https://docs.github.com/en/actions/how-tos/administer/enforce-workflow-lockfiles puts it. The same guide recommends adding .github/workflows/actions.lock to CODEOWNERS and requiring code-owner approval for changes. The Dependabot PR becomes the review point, and teams that auto-merge those updates "will carry any malicious change straight into the lockfile," as InfoQ's GA coverage https://www.infoq.com/news/2026/11/github-actions-lockfiles-ga/ puts it. Dependabot and Renovate already update the lockfile, and Hugo's post adds a reminder to use cooldowns. Changes to these fields should be rare. A changed owner id or repo id means the repository behind that name is not the one you originally locked, per GitHub's locking how-to https://docs.github.com/en/actions/how-tos/secure-your-work/lock-workflow-dependencies . GitHub says to investigate before merging, and I wouldn't let a bot PR with that diff merge on a green check alone. Reusable workflows called at jobs.<job id .uses aren't pinned by the lockfile, so pin them by full commit SHA, per GitHub's lockfile concepts page https://docs.github.com/en/actions/concepts/security/workflow-dependency-lockfiles . The file doesn't control inputs, secrets or the runner image either. The README adds two more. Local ./ actions are never followed or locked, and container images aren't locked you get a warning when an image has no @sha256: digest . Composite actions are locked through their callers, not on their own, as zizmor's maintainer noted in the HN thread https://news.ycombinator.com/item?id=50459485 . The extension has a few flags worth knowing by sight. --relock advances refs that moved upstream. --accept-moved accepts pins whose locked commit is no longer upstream, and the README says to check why it moved first and "never use it in automation." One more limit from the README: a floating ref like v4 or main moved back to an older commit in its own history isn't detected. GitHub recommends a CI job running gh actions-lock --verify on pull requests, and Hugo's post shows one. A PR that removes the verify job deserves the same scrutiny as one that adds --accept-moved . For public repos, open Policy insights first, under Settings Actions Policies at repository, organization or enterprise level. GitHub says the page shows which runs the default rule would block. For each pull request target workflow on that list, pick one of two paths: pull request if the job doesn't need secrets or a write token. Private, internal and GitHub Enterprise Server repos don't need the event change. Lockfiles are a separate project: onboard workflows with gh actions-lock , commit the lockfile, add the verify job, and put .github/workflows/actions.lock in CODEOWNERS. Turn on the Require lockfile policy only once the lockfiles exist, or you'll block runs. Two honest limits. A lockfile proves the code didn't move after you locked it. Whether the action was safe when you locked it is still a judgment, and GitHub's own wording says the same. Actions event policies and the Require lockfile policy live in repository or organization settings, not in the PR diff. A reviewer reading the pull request can't see them. Policy insights is where GitHub says to check what would be blocked, and who may change workflow files or let agents edit them belongs in your AI code governance policy https://dev.to/uss/ai-code-governance-policy-for-copilot-cursor-and-claude-code-3nij . Qodo https://www.qodo.ai/ , the AI code review platform, reviews every pull request in your Git provider, workflow files included. In the Qodo portal or in .pr agent.toml , a team can add custom instructions that tell Qodo what to flag when .github/workflows/ or actions.lock changes, without changing how the rest of the review works. Custom instructions can flag pull request target combined with a PR-head checkout, allow-unsafe-pr-checkout , --accept-moved in a workflow step, and a changed owner id or repo id . The same checks can live in a pr compliance checklist.yaml file at the repository root, which Qodo uses during code review to surface violations as findings. For high-velocity teams, every PR gets checked against those instructions, with no new process. Enterprise engineering teams can set the same custom instructions once at organization level, which matters when coding agents edit workflow YAML in dozens of repositories. Findings stay advisory. GitHub's event policies and Require lockfile policy remain the enforcement layer, and judging whether an upstream action is safe stays with your reviewers. Qodo flags; your team decides. Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, workflow files are where a written instruction pays off fastest, because the risky patterns are short and easy to name. A machine-generated file at .github/workflows/actions.lock , created by gh actions-lock . For each action your onboarded workflows use, including transitive dependencies, it records the ref, the exact commit, and the source repository's numeric owner and repo IDs. GitHub says never to edit it by hand. Onboarded workflows don't need separate SHA pins, per GitHub's docs, and the lockfile satisfies the separate SHA-pinning policy for them. Reusable workflows called at the job level are the exception: pin those by full SHA. A lockfile doesn't make an action safe. Lockfiles "don't determine whether a dependency is safe," per GitHub's changelog https://github.blog/changelog/2026-10-28-github-actions-workflow-lockfiles-are-generally-available/ . A lockfile stops locked code from changing underneath you. Reviewing what you locked is still your job. In public repositories without an applicable Actions event policy, pull request target runs are blocked by default. Allowing the event in a policy, scoped to specific workflow files, keeps those workflows running. Private and internal repositories aren't affected by the block, and neither is GitHub Enterprise Server. Auto-merge is possible, but InfoQ's point stands: the Dependabot PR is where a bad commit would enter the lockfile. I'd keep .github/workflows/actions.lock under CODEOWNERS and read the commit , owner id and repo id changes first. Lockfiles don't support GitHub Enterprise Server. The gh-actions-lock README lists github.com and Enterprise Cloud with data residency as the supported platforms.