# GitHub Actions has lockfiles now, and pull_request_target gets blocked on Dec 2: 7 workflow changes to catch in review in 2026 > Source: > Published: 2026-11-13 17:10:59+00:00 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..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.