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

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 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.

What changed in GitHub Actions in late October and early November

Workflow lockfiles went GA on October 28

Workflow lockfiles are available on GitHub Enterprise Cloud (including data residency), Team and Free, per the GA changelog. 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 says GitHub Enterprise Server isn't supported.

pull_request_target is blocked by default in public repos from December 2

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. Enforcement was first scheduled for November 2, then moved in an October 21 editor's note on the workflow execution protections changelog.

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

How a lockfile diff looks when you turn it on

Hugo van Kemenade's walkthrough from November 11 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 puts the stakes in one line: "A lockfile is only a security control if someone reads the diff."

GitHub Actions security in review: 7 workflow changes to catch

1. A pull_request_target trigger that could be pull_request
2. A checkout of the PR head inside a privileged workflow
3. Tag-pinned uses lines and allowlist entries after onboarding
4. A changed commit in actions.lock
5. A changed owner_id or repo_id
6. Dependencies the lockfile doesn't cover
7. A relock, an accepted move, or a missing verify job

1. A pull_request_target trigger that could be pull_request

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. 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?

2. A checkout of the PR head inside a privileged workflow

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. 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

3. Tag-pinned uses lines and allowlist entries after onboarding

Onboarding rewrites references to the exact version it resolved, so @v3 can become @v3.1.0. GitHub's locking how-to 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.

4. A changed commit in actions.lock

A changed commit is the code your workflows will run, so treat it like any other dependency bump, as GitHub's enforcement guide 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 puts it. Dependabot and Renovate already update the lockfile, and Hugo's post adds a reminder to use cooldowns.

5. A changed owner_id or repo_id

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. GitHub says to investigate before merging, and I wouldn't let a bot PR with that diff merge on a green check alone.

6. Dependencies the lockfile doesn't cover

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. 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.

7. A relock, an accepted move, or a missing verify job

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.

What to do before the November 16 brownout and December 2

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:

• Switch to pull_request if the job doesn't need secrets or a write token.
• Keep the trigger and allow it for that specific workflow file in an Actions event policy, using workflow file targeting.

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.

What review can't settle for you

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.

Choose Qodo when workflow files should get the same review as app code

Qodo, 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.

FAQ

What is actions.lock in GitHub Actions?

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.

Do I still need to pin GitHub Actions to a commit SHA if I use a lockfile?

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.

Does a lockfile mean an action is safe?

A lockfile doesn't make an action safe. Lockfiles "don't determine whether a dependency is safe," per GitHub's changelog. A lockfile stops locked code from changing underneath you. Reviewing what you locked is still your job.

What happens to pull_request_target on December 2, 2026?

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.

Are private repositories affected by the pull_request_target block?

Private and internal repositories aren't affected by the block, and neither is GitHub Enterprise Server.

Can I auto-merge Dependabot lockfile PRs?

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.

Do lockfiles work on GitHub Enterprise Server?

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.