Actions: ActorIfCheck ControlCheck model fix for events that don't populate the checked field

[computersarebad]

Fixes #22367

Currently ActorIfCheck treats a condition as an actor check if it mentions a field like github.event.pull_request.user.login anywhere in the if: expression, and the check then counts as protection for all the events ActorCheck covers. It never looks at whether that field is even populated for the event triggering the workflow. On an issues event github.event.pull_request is null, so something like if: github.event.pull_request.user.login != 'some-bot[bot]' is always true and gates nothing, but it still suppressed actions/code-injection/critical (repro in the linked issue).

This change overrides protectsCategoryAndEvent in ActorIfCheck so payload field checks only protect events whose payload actually contains that context, reusing the existing contextTriggerDataModel extension for the mapping. Checks on github.actor, github.triggering_actor and github.event.sender.login still protect every event since those are always populated. The characteristic predicate is unchanged, including the %[bot]% exclusion.

This is the same kind of fix as #22154 did for EnvironmentCheck, which suggested reviewing if other check types have this issue. Added two testcases: actor_check_wrong_event.yml with the vacuous check (now detected as critical) next to a valid github.actor check (still medium), and actor_check_valid_event.yml with a github.event.pull_request.user.login check on a pull_request_target event, which is populated there and still suppresses the critical alert. No existing test results change.

Edit: per review feedback, the payload-field checks were split out of ActorIfCheck into a new EventActorIfCheck class, so ActorIfCheck now only covers github.actor and github.triggering_actor.

[Copilot]

Pull request overview

Updates ActorIfCheck to consider whether event payload actor fields exist for the triggering event.

Changes:

• Maps payload actor checks to compatible events.
• Adds valid and vacuous actor-check fixtures.
• Updates expected query results and release notes.

Show a summary per file

File	Description
ControlChecks.qll	Adds event-aware actor-check protection logic.
actor_check_wrong_event.yml	Tests a vacuous payload check and valid global actor check.
actor_check_valid_event.yml	Tests a valid pull-request payload check.
CodeInjectionMedium.expected	Updates generated medium-query results.
CodeInjectionCritical.expected	Updates generated critical-query results.
2026-08-17-actor-if-check-event-validity.md	Documents the analysis change.

Review details

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 6/6 changed files
• Comments generated: 1
• Review effort level: Balanced

[jketema]

I'm not too familiar with actions and the actions queries, so I question below.

Design-wise, I wonder whether the ActorIfCheck should be split into two classes:

• The current class, just covering github.triggering_actor and github.actor
• A new class EventIfCheck that covers the four github.event. cases.

That would significantly simplify the logic, and also seems to better match the github. naming.

[jketema]

• A new class EventIfCheck that covers the four github.event. cases.

Looking at the code again, that might need a better name.

[computersarebad]

Added a few more testcases in dc6ee11 to pin down the behavior @jketema raised. There's now a job for each case in the issues-triggered workflow, so the sender.login check suppressing the critical alert and the head_commit/commits checks not protecting are both captured in the expected output. I looked at pinning the push side too but push flows only ever show up in the medium query, which doesn't consult control checks, so there's nothing observable to test there.

[kevinbackhouse]

LGTM