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

actions/ql/src/Security/CWE-829/UntrustedCheckoutCritical.md

@@ -27,7 +27,7 @@ Certain triggers automatically grant a workflow elevated privileges:
   * An attacker forks the repository and adds malicious code (e.g., in the build script)
   * The attacker opens a PR from the fork, and, if needed, comments on the PR
   * The workflow in the base repository checks out the forked code
-  * The workflow runs, (e.g. the build script etc.), which contains the malicious code
+  * The workflow runs the malicious code
 
 Please note that not only build scripts can be malicious code vectors. There is a large number of other possibilities. Some of them are listed in the [LOTP](https://boostsecurityio.github.io/lotp/) catalog.
 
@@ -41,6 +41,8 @@ The best practice is to handle the potentially untrusted pull request via the **
 
 The artifacts downloaded from the first workflow should be considered untrusted and must be verified.
 
+Additionally, ensure that least privileges are used for permissions given both at the workflow (through event triggers) and job (through job level permissions) level.
+
 ## Example
 
 ### Incorrect Usage
@@ -163,4 +165,5 @@ jobs:
 
 - GitHub Security Lab Research: [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 - Mitigating risks of untrusted checkout: [GitHub Docs](https://docs.github.com/en/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout).
+- Securing with least privileges: [Workflow secure use](https://docs.github.com/en/actions/reference/security/secure-use).
 - Living Off the Pipeline: [LOTP](https://boostsecurityio.github.io/lotp/).

actions/ql/src/Security/CWE-829/UntrustedCheckoutCritical.ql

@@ -52,4 +52,5 @@ where
   not exists(ControlCheck check | check.protects(checkout, event, "untrusted-checkout")) and
   not exists(ControlCheck check | check.protects(poisonable, event, "untrusted-checkout"))
 select poisonable, checkout, poisonable,
-  "Potential execution of untrusted code on a privileged workflow ($@)", event, event.getName()
+  "Checkout of untrusted code in a privileged workflow with later potential execution (event trigger: $@).",
+  event, event.getName()

actions/ql/src/Security/CWE-829/UntrustedCheckoutHigh.md

@@ -27,7 +27,7 @@ Certain triggers automatically grant a workflow elevated privileges:
   * An attacker forks the repository and adds malicious code (e.g., in the build script)
   * The attacker opens a PR from the fork, and, if needed, comments on the PR
   * The workflow in the base repository checks out the forked code
-  * The workflow runs, (e.g. the build script etc.), which contains the malicious code
+  * The workflow runs the malicious code
 
 Please note that not only build scripts can be malicious code vectors. There is a large number of other possibilities. Some of them are listed in the [LOTP](https://boostsecurityio.github.io/lotp/) catalog.
 
@@ -41,6 +41,8 @@ The best practice is to handle the potentially untrusted pull request via the **
 
 The artifacts downloaded from the first workflow should be considered untrusted and must be verified.
 
+Additionally, ensure that least privileges are used for permissions given both at the workflow (through event triggers) and job (through job level permissions) level.
+
 ## Example
 
 ### Incorrect Usage
@@ -163,4 +165,5 @@ jobs:
 
 - GitHub Security Lab Research: [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 - Mitigating risks of untrusted checkout: [GitHub Docs](https://docs.github.com/en/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout).
+- Securing with least privileges: [Workflow secure use](https://docs.github.com/en/actions/reference/security/secure-use).
 - Living Off the Pipeline: [LOTP](https://boostsecurityio.github.io/lotp/).

actions/ql/src/Security/CWE-829/UntrustedCheckoutHigh.ql

@@ -1,5 +1,5 @@
 /**
- * @name Checkout of untrusted code in privileged context without privileged context use
+ * @name Checkout of untrusted code in trusted context
  * @description Privileged workflows have read/write access to the base repository and access to secrets.
  *              By explicitly checking out and running the build script from a fork the untrusted code is running in an environment
  *              that is able to push to the base repository and to access secrets.
@@ -42,5 +42,6 @@ where
     not event.getName() = "issue_comment" and
     not exists(ControlCheck check | check.protects(checkout, event, "untrusted-checkout"))
   )
-select checkout, "Potential execution of untrusted code on a privileged workflow ($@)", event,
-  event.getName()
+select checkout,
+  "Checkout of untrusted code in a privileged workflow with later potential execution (event trigger: $@).",
+  event, event.getName()

actions/ql/src/Security/CWE-829/UntrustedCheckoutMedium.md

@@ -27,7 +27,7 @@ Certain triggers automatically grant a workflow elevated privileges:
   * An attacker forks the repository and adds malicious code (e.g., in the build script)
   * The attacker opens a PR from the fork, and, if needed, comments on the PR
   * The workflow in the base repository checks out the forked code
-  * The workflow runs, (e.g. the build script etc.), which contains the malicious code
+  * The workflow runs the malicious code
 
 Please note that not only build scripts can be malicious code vectors. There is a large number of other possibilities. Some of them are listed in the [LOTP](https://boostsecurityio.github.io/lotp/) catalog.
 
@@ -41,6 +41,8 @@ The best practice is to handle the potentially untrusted pull request via the **
 
 The artifacts downloaded from the first workflow should be considered untrusted and must be verified.
 
+Additionally, ensure that least privileges are used for permissions given both at the workflow (through event triggers) and job (through job level permissions) level.
+
 ## Example
 
 ### Incorrect Usage
@@ -163,4 +165,5 @@ jobs:
 
 - GitHub Security Lab Research: [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 - Mitigating risks of untrusted checkout: [GitHub Docs](https://docs.github.com/en/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout).
+- Securing with least privileges: [Workflow secure use](https://docs.github.com/en/actions/reference/security/secure-use).
 - Living Off the Pipeline: [LOTP](https://boostsecurityio.github.io/lotp/).

actions/ql/src/change-notes/2026-05-14-further-iteration-untrusted-checkout-improvements-alert.md

@@ -0,0 +1,4 @@
+---
+category: minorAnalysis
+---
+  * Altered the alert message for clarity for queries: `actions/untrusted-checkout/critical`, `actions/untrusted-checkout/high`.

actions/ql/src/change-notes/2026-05-14-further-iteration-untrusted-checkout-improvements-helpfile.md

@@ -0,0 +1,4 @@
+---
+category: fix
+---
+  * Adjusted (minor) help file descriptions for queries: `actions/untrusted-checkout/critical`, `actions/untrusted-checkout/high`, `actions/untrusted-checkout/medium`. Clarified wording on in minor point, added one more listed resource and added one more recommendation for things to check.

actions/ql/src/change-notes/2026-05-14-further-iteration-untrusted-checkout-improvements-metadata.md

@@ -0,0 +1,4 @@
+---
+category: queryMetadata
+---
+  * Reversed adjustment of the name of `actions/untrusted-checkout/high`.