Sync Main (autogenerated)

actions/ql/examples/snippets/uses_pinned_sha.ql

@@ -8,5 +8,5 @@
 import actions
 
 from UsesStep uses
-where uses.getVersion().regexpMatch("^[A-Fa-f0-9]{40}$")
+where uses.getVersion().regexpMatch("^[A-Fa-f0-9]{40}([A-Fa-f0-9]{24})?$")
 select uses, "This 'uses' step has a pinned SHA version."

actions/ql/lib/CHANGELOG.md

@@ -1,3 +1,9 @@
+## 0.4.37
+
+### Minor Analysis Improvements
+
+* The GitHub Actions analysis now recognizes more Bash regex checks that restrict a value to alphanumeric characters, include regexes like `^[0-9a-zA-Z]{40}([0-9a-zA-Z]{24})?$` which check for a sha1 or sha256 hash. This may reduce false positive results where command output is validated with grouped or optional alphanumeric patterns before being used.
+
 ## 0.4.36
 
 ### Minor Analysis Improvements

actions/ql/lib/change-notes/released/0.4.37.md

@@ -0,0 +1,5 @@
+## 0.4.37
+
+### Minor Analysis Improvements
+
+* The GitHub Actions analysis now recognizes more Bash regex checks that restrict a value to alphanumeric characters, include regexes like `^[0-9a-zA-Z]{40}([0-9a-zA-Z]{24})?$` which check for a sha1 or sha256 hash. This may reduce false positive results where command output is validated with grouped or optional alphanumeric patterns before being used.

actions/ql/lib/codeql-pack.release.yml

@@ -1,2 +1,2 @@
 ---
-lastReleaseVersion: 0.4.36
+lastReleaseVersion: 0.4.37

actions/ql/lib/codeql/actions/Bash.qll

@@ -785,7 +785,22 @@ module Bash {
 
   /**
    * Holds if the given regex is used to match an alphanumeric string
-   * eg: `^[0-9a-zA-Z]{40}$`, `^[0-9]+$` or `^[a-zA-Z0-9_]+$`
+   * eg: `^[0-9a-zA-Z]{40}([0-9a-zA-Z]{24})?$`, `^[0-9]+$` or `^[a-zA-Z0-9_]+$`
    */
-  string alphaNumericRegex() { result = "^\\^\\[([09azAZ_-]+)\\](\\+|\\{\\d+\\})\\$$" }
+  string alphaNumericRegex() {
+    exists(string r1, string r2, string r3, string r4 |
+      // An alphanumeric character class
+      r1 = "\\[([09azAZ_-]+)\\]" and
+      // The same as above, followed by a quantifier like `+` or `{20}`
+      r2 = r1 + "(\\+|\\{\\d+\\})" and
+      // The same as above, possibly with parentheses around it
+      r3 = "\\(?" + r2 + "\\)?" and
+      // The same as above, possibly with a `?` after it
+      r4 = r3 + "\\??"
+    |
+      // The same as above, repeated one or more times, and with `^` at the
+      // beginning and `$` at the end
+      result = "^\\^(" + r4 + ")+\\$$"
+    )
+  }
 }

actions/ql/lib/qlpack.yml

@@ -1,5 +1,5 @@
 name: codeql/actions-all
-version: 0.4.36
+version: 0.4.37
 library: true
 warnOnImplicitThis: true
 dependencies:

actions/ql/src/CHANGELOG.md

@@ -1,3 +1,22 @@
+## 0.6.29
+
+### Query Metadata Changes
+
+* Reversed adjustment of the name of `actions/untrusted-checkout/high`, but kept the portion of the previous change for the word "trusted" to "privileged". Added a missing "a" to phrasing in `actions/untrusted-checkout/high` and `actions/untrusted-checkout/medium`.
+
+### Major Analysis Improvements
+
+* Adjusted `actions/untrusted-checkout/critical` to align more with other untrusted resource queries, where the alert location is the location where the artifact is obtained from (the checkout point). This aligns with the other 2 related queries. This will cause the same alerts to re-open for closed alerts of this query.
+
+### Minor Analysis Improvements
+
+* Altered the alert message for clarity for queries: `actions/untrusted-checkout/critical`, `actions/untrusted-checkout/high`.
+* The `actions/unpinned-tag` query now recognizes 64-character SHA-256 commit hashes as properly pinned references, in addition to 40-character SHA-1 hashes.
+
+### Bug Fixes
+
+* 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.
+
 ## 0.6.28
 
 ### Query Metadata Changes

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

@@ -15,7 +15,9 @@ import actions
 import codeql.actions.security.UseOfUnversionedImmutableAction
 
 bindingset[version]
-private predicate isPinnedCommit(string version) { version.regexpMatch("^[A-Fa-f0-9]{40}$") }
+private predicate isPinnedCommit(string version) {
+  version.regexpMatch("^[A-Fa-f0-9]{40}([A-Fa-f0-9]{24})?$")
+}
 
 bindingset[nwo]
 private predicate isTrustedOwner(string nwo) {

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 privilege are used both at the workflow level (through event triggers and workflow permissions) and job level (through job permissions).
+
 ## 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 privilege: [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

@@ -51,5 +51,6 @@ where
   event.getName() = checkoutTriggers() and
   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()
+select checkout, checkout, poisonable,
+  "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 privilege are used both at the workflow level (through event triggers and workflow permissions) and job level (through job permissions).
+
 ## 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 privilege: [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 a privileged 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 privilege are used both at the workflow level (through event triggers and workflow permissions) and job level (through job permissions).
+
 ## 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 privilege: [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/UntrustedCheckoutMedium.ql

@@ -1,5 +1,5 @@
 /**
- * @name Checkout of untrusted code in trusted context
+ * @name Checkout of untrusted code in a 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.

actions/ql/src/change-notes/released/0.6.29.md

@@ -0,0 +1,18 @@
+## 0.6.29
+
+### Query Metadata Changes
+
+* Reversed adjustment of the name of `actions/untrusted-checkout/high`, but kept the portion of the previous change for the word "trusted" to "privileged". Added a missing "a" to phrasing in `actions/untrusted-checkout/high` and `actions/untrusted-checkout/medium`.
+
+### Major Analysis Improvements
+
+* Adjusted `actions/untrusted-checkout/critical` to align more with other untrusted resource queries, where the alert location is the location where the artifact is obtained from (the checkout point). This aligns with the other 2 related queries. This will cause the same alerts to re-open for closed alerts of this query.
+
+### Minor Analysis Improvements
+
+* Altered the alert message for clarity for queries: `actions/untrusted-checkout/critical`, `actions/untrusted-checkout/high`.
+* The `actions/unpinned-tag` query now recognizes 64-character SHA-256 commit hashes as properly pinned references, in addition to 40-character SHA-1 hashes.
+
+### Bug Fixes
+
+* 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/codeql-pack.release.yml

@@ -1,2 +1,2 @@
 ---
-lastReleaseVersion: 0.6.28
+lastReleaseVersion: 0.6.29

actions/ql/src/qlpack.yml

@@ -1,5 +1,5 @@
 name: codeql/actions-queries
-version: 0.6.28
+version: 0.6.29
 library: false
 warnOnImplicitThis: true
 groups: [actions, queries]

actions/ql/test/query-tests/Security/CWE-829/.github/workflows/unpinned_tags.yml

@@ -11,3 +11,9 @@ jobs:
     - uses: foo/bar@25b062c917b0c75f8b47d8469aff6c94ffd89abb
     - uses: docker://foo/bar@latest
     - uses: docker://foo/bar@sha256:887a259a5a534f3c4f36cb02dca341673c6089431057242cdc931e9f133147e9
+    # SHA-256 pinned (64 hex chars) - should NOT be flagged
+    - uses: foo/bar@25b062c917b0c75f8b47d8469aff6c94ffd89abb25b062c917b0c75f8b47d84d
+    # SHA-1 pinned (40 hex chars) regression - should NOT be flagged
+    - uses: foo/bar@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2
+    # Invalid 50-char hex string - should be flagged
+    - uses: foo/bar@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2a1b2c3d4e5

actions/ql/test/query-tests/Security/CWE-829/UnpinnedActionsTag.expected

@@ -34,3 +34,4 @@
 | .github/workflows/test18.yml:37:21:37:63 | sonarsource/sonarcloud-github-action@master | Unpinned 3rd party Action 'Sonar' step $@ uses 'sonarsource/sonarcloud-github-action' with ref 'master', not a pinned commit hash | .github/workflows/test18.yml:36:15:40:58 | Uses Step | Uses Step |
 | .github/workflows/unpinned_tags.yml:10:13:10:22 | foo/bar@v1 | Unpinned 3rd party Action 'unpinned_tags.yml' step $@ uses 'foo/bar' with ref 'v1', not a pinned commit hash | .github/workflows/unpinned_tags.yml:10:7:11:4 | Uses Step | Uses Step |
 | .github/workflows/unpinned_tags.yml:12:13:12:35 | docker://foo/bar@latest | Unpinned 3rd party Action 'unpinned_tags.yml' step $@ uses 'docker://foo/bar' with ref 'latest', not a pinned commit hash | .github/workflows/unpinned_tags.yml:12:7:13:4 | Uses Step | Uses Step |
+| .github/workflows/unpinned_tags.yml:19:13:19:70 | foo/bar@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2a1b2c3d4e5 | Unpinned 3rd party Action 'unpinned_tags.yml' step $@ uses 'foo/bar' with ref 'a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2a1b2c3d4e5', not a pinned commit hash | .github/workflows/unpinned_tags.yml:19:7:19:71 | Uses Step | Uses Step |