Improve actions/ql/src/Security/CWE-829/UntrustedCheckoutX queries

[knewbury01]

several changes:

• python has a -m flag that allows for scripts to be executed without directly providing the py file. regex patterns for poisonable steps are improved for this
• go run has the ability to point to directories. regex patterns for poisonable steps are improved for this
• all 3 queries have significantly improved descriptions in their help files
• the changenote describes minor clarifying name and alert formatting changes that occur as well

[Copilot]

Pull request overview

This PR updates the GitHub Actions “Untrusted checkout” query family to improve sink detection (Python -m module execution and go run directory/package execution) and refines the associated query help text, naming, and alert location formatting to better align with related queries.

Changes:

• Expand poisonable-step regex patterns for Python module execution (python -m ...) and broader go run/generate targets.
• Update help file overview text and add an additional reference link.
• Adjust query naming and (per changenote) alert location behavior for the critical query.

Show a summary per file

File	Description
actions/ql/src/change-notes/2026-04-15-untrusted-checkout-improvements.md	Adds a changenote describing detection + messaging updates.
actions/ql/src/Security/CWE-829/UntrustedCheckoutMedium.md	Refines the query help overview text and adds a reference.
actions/ql/src/Security/CWE-829/UntrustedCheckoutHigh.ql	Updates the query display name.
actions/ql/src/Security/CWE-829/UntrustedCheckoutHigh.md	Refines the query help overview text and adds a reference.
actions/ql/src/Security/CWE-829/UntrustedCheckoutCritical.ql	Adjusts select tuple ordering (alert location formatting).
actions/ql/src/Security/CWE-829/UntrustedCheckoutCritical.md	Refines the query help overview text and adds a reference.
actions/ql/src/Security/CWE-094/CodeInjectionMedium.ql	Modifies query metadata and replaces query body with temporary/test content.
actions/ql/lib/ext/config/poisonable_steps.yml	Updates poisonable local-script regex patterns for Python -m and go run/generate.

Copilot's findings

Comments suppressed due to low confidence (1)

actions/ql/src/Security/CWE-094/CodeInjectionMedium.ql:25

• It looks like the actual query body has been commented out (lines 21-25). Leaving commented-out query logic in the source is likely accidental and will prevent this query from working as intended; please restore the real query and remove the temporary commented-out block.

// from CodeInjectionFlow::PathNode source, CodeInjectionFlow::PathNode sink
// where mediumSeverityCodeInjection(source, sink)
// select sink.getNode(), source, sink,
//   "Potential code injection in $@, which may be controlled by an external user.", sink,
//   sink.getNode().asExpr().(Expression).getRawExpression()

• Files reviewed: 8/8 changed files
• Comments generated: 9

[Copilot]

The query @name is hard to parse and reads self-contradictory ("privileged context without privileged context use"). Consider rephrasing to clearly describe the intended scenario (for example, privileged workflow + untrusted checkout, and what makes it "high").

Suggested change

	* @name Checkout of untrusted code in privileged context without privileged context use
	* @name Checkout of untrusted code in a privileged workflow

[Copilot]

The changenote bullet is a run-on sentence and has unclear grammar (for example "Additionally alter 2 patterns"). Please rewrite for clarity (e.g., split into shorter sentences and use consistent tense) so the change is easy to understand in release notes.

Suggested change

* Fixed help file descriptions for queries: `actions/untrusted-checkout/critical`, `actions/untrusted-checkout/high`, `actions/untrusted-checkout/medium`. Previously the messages were unclear as to why and how the vulnerabilities could occur. Additionally alter 2 patterns in the detection such that now extra sinks are detected in the following cases: scripts executed via python modules and `go run` in directories are detected as potential mechanisms of injection. This may lead to more results being detected by all 3 queries.

* Fixed the help file descriptions for `actions/untrusted-checkout/critical`, `actions/untrusted-checkout/high`, and `actions/untrusted-checkout/medium`. Previously, the messages did not clearly explain why and how the vulnerabilities could occur. Also updated two detection patterns so that additional sinks are detected. In particular, scripts executed via Python modules and `go run` in directories are now detected as potential injection mechanisms. This may lead to more results from all three queries.

[Copilot]

The Overview text says "least privileges" but the standard phrasing is "least privilege" (singular). Consider also changing "whether least privileges is used" to something grammatically correct like "whether the principle of least privilege is followed".

Suggested change

GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether least privileges is used and whether input is taken from untrusted sources.

GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether the principle of least privilege is followed and whether input is taken from untrusted sources.

[Copilot]

The Overview text says "least privileges" but the standard phrasing is "least privilege" (singular). Consider also changing "whether least privileges is used" to something grammatically correct like "whether the principle of least privilege is followed".

Suggested change

GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether least privileges is used and whether input is taken from untrusted sources.

GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether the principle of least privilege is followed and whether input is taken from untrusted sources.

[Copilot]

The Overview text says "least privileges" but the standard phrasing is "least privilege" (singular). Consider also changing "whether least privileges is used" to something grammatically correct like "whether the principle of least privilege is followed".

Suggested change

GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether least privileges is used and whether input is taken from untrusted sources.

GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A dangerous misuse of event triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted input from the PR may lead to repository compromise if untrusted code gets executed in a privileged job. Untrusted code may get executed due to a modified build script, workflow injection, or registry hijacking. **Carefully review** whether the principle of least privilege is followed and whether input is taken from untrusted sources.

[owen-mc]

The regex changes look okay. I think you've update the go regex to ignore flags between "go run" or "go generate" and the path. Please can you mention this in the change note? Also, I think the regex changes should be described in a change note in lib instead of src, since anyone updating the library pack will get them.

Changes to alert locations which cause closed alerts to be re-opened have to be carefully considered, to weigh up the pain caused by making users re-triage the query versus the future benefit of having better alert locations.

I will review this further soon.

[owen-mc]

I think the changes which will cause closed alerts to be reopened should be separated into a different PR, as they may take a while to get approval for. As I noted, I think this is just changing alert locations - the query name should be fine.

[owen-mc]

Please specify the queries. We want a user who sees extra results for query X and then looks at the change note to see why to immediately find the answer.

[owen-mc]

Is it definitely correct that this will cause alerts to reopen? I'd have thought that the query id is used for matching alerts up - I'm pretty sure I've changed the query name before and not had a problem. I've asked internally to be sure.

[owen-mc]

Also, this should have the category queryMetadata. Put it in a separate file if necessary.

[owen-mc]

I don't think we need a change note for qhelp files. It isn't harmful though, so if a customer particularly wants it then we can keep it. But it definitely shouldn't be in the majorAnalysis category. I'd use fix. (This will probably necessitate it being in a different file, which is fine.)