chore(ci): bump github/codeql-action from 3 to 4#62
Conversation
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3 to 4. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@v3...v4) --- updated-dependencies: - dependency-name: github/codeql-action dependency-version: '4' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
There was a problem hiding this comment.
dependabot[bot] has reached the 50-review limit for trial accounts. To continue receiving code reviews, upgrade your plan.
📝 WalkthroughWalkthroughThe security workflow is updated to use GitHub's CodeQL action version 4 for uploading Trivy SARIF results, replacing the previous v3 dependency. This single-line change modernizes the security scanning integration. ChangesSecurity Workflow Update
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/security.yml:
- Line 36: The workflow currently pins actions with mutable tags (e.g.,
github/codeql-action/upload-sarif@v4) which violates the hash-pinning policy;
update each uses: entry (including github/codeql-action/upload-sarif@v4 and the
other codeql/action and actions entries referenced in the comment) to use the
corresponding commit SHA instead of the tag. Find the exact commit SHA for the
v4 tag (or the appropriate release tag you intended) and replace the mutable tag
with the full SHA (e.g., github/codeql-action/upload-sarif@<commit-sha>),
ensuring all uses lines in the workflow are consistently pinned to their commit
SHAs.
- Line 36: The workflow step using uses: github/codeql-action/upload-sarif@v4 is
not pinned and the job lacks required action permissions for CodeQL v4; update
the job to pin the upload-sarif action to a specific commit SHA (replace
github/codeql-action/upload-sarif@v4 with
github/codeql-action/upload-sarif@<commit-sha>) and add permissions: actions:
read in addition to the existing permissions (contents: read and
security-events: write) so upload-sarif runs reliably across runners and GHES
versions; also consider pinning other actions referenced in the workflow for
consistency with the repo’s hash-pinning policy.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: faf08198-ed64-4ccd-b215-9832b4af9d2b
📒 Files selected for processing (1)
.github/workflows/security.yml
| - name: Upload Trivy scan results to GitHub Security tab | ||
| # Pin action versions to a vetted release tag for supply-chain security and reproducible runs. | ||
| uses: github/codeql-action/upload-sarif@v3 | ||
| uses: github/codeql-action/upload-sarif@v4 |
There was a problem hiding this comment.
Action reference violates hash-pinning policy.
The static analysis tool flags this line because a blanket policy requires actions to be pinned to commit SHAs, not mutable tags. Using @v4 (a mutable tag) reduces supply-chain security guarantees—if the upstream repository is compromised, the tag can be moved to point to malicious code.
This contradicts the comment on line 35 which states the action is pinned "for supply-chain security and reproducible runs."
🔒 Recommended fix: Pin to commit SHA
- uses: github/codeql-action/upload-sarif@v4
+ uses: github/codeql-action/upload-sarif@<commit-sha> # v4To find the commit SHA for the v4 release:
#!/bin/bash
# Find the commit SHA for github/codeql-action v4 release tag
gh api repos/github/codeql-action/git/ref/tags/v4 --jq '.object.sha'Note: This issue also affects the other actions in this workflow (lines 22, 26).
As per static analysis hints: "action is not pinned to a hash (required by blanket policy)".
🧰 Tools
🪛 zizmor (1.25.2)
[error] 36-36: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/security.yml at line 36, The workflow currently pins
actions with mutable tags (e.g., github/codeql-action/upload-sarif@v4) which
violates the hash-pinning policy; update each uses: entry (including
github/codeql-action/upload-sarif@v4 and the other codeql/action and actions
entries referenced in the comment) to use the corresponding commit SHA instead
of the tag. Find the exact commit SHA for the v4 tag (or the appropriate release
tag you intended) and replace the mutable tag with the full SHA (e.g.,
github/codeql-action/upload-sarif@<commit-sha>), ensuring all uses lines in the
workflow are consistently pinned to their commit SHAs.
🧩 Analysis chain
🌐 Web query:
github codeql-action v4 breaking changes upload-sarif
💡 Result:
No single, universally applicable “CodeQL Action v4 breaking change” exists specifically named for “upload-sarif”; instead, there are several v4-relevant changes/edge-cases that commonly make an upload-sarif step appear “broken” after upgrading. 1) v4 major version requires the Node.js 24 Actions runtime (and some GHES versions can’t run it) - GitHub states that CodeQL Action v4 (released Oct 7, 2025) runs on the Node.js 24 runtime [1]. - GitHub also states GHES 3.18 and older cannot run actions using the Node.js 24 runtime, so they are unable to run CodeQL Action v4 [1]. Impact: if you’re on an older GHES or a platform without Node.js 24 runtime support, github/codeql-action/upload-sarif@v4 won’t work. 2) Permissions: upload-sarif can fail with “Resource not accessible by integration” unless actions: read is granted - A CodeQL Action issue documents upload-sarif failing (before any real upload happens) and identifies the missing permission as actions: read [2]. - The issue author reports that adding permissions: actions: read at the job level made upload-sarif work [2]. Impact: workflows (especially reusable/composite workflows) that don’t explicitly grant permissions: actions: read may break. Suggested fix (YAML): permissions: actions: read 3) SARIF post-processing behavior changed for uploads initiated by analyze or upload-sarif (primarily impacts analyze) - The CodeQL Action changelog says that when SARIF files are uploaded by analyze or upload-sarif, the action automatically performs post-processing steps to prepare the data for upload. - It further says those post-processing steps previously ran only “before an upload took place”, but are now always performed even when SARIF files are not uploaded; it also says “This does not change anything for the upload-sarif action,” and notes possible impact on analyze users depending on the upload input [3]. Impact: if your workflow relies on specific timing/side-effects of post-processing for analyze, the behavior can change; upload-sarif itself is stated as unchanged for this particular item [3]. 4) Specific upload-sarif bug fix: non-.sarif files not being uploaded (fixed in the v3.30.4 line) - The changelog notes they fixed “a bug … with upload-sarif … [that] resulted in files without a .sarif extension not getting uploaded” [3]. Impact: if your pipeline uploads files whose names/extensions aren’t standard .sarif, you may see behavior differences depending on which CodeQL Action release your @v4 tag resolves to. 5) GHES 3.18 limitation: combining SARIF files from a single upload is removed - The changelog notes: “Remove support for combining SARIF files from a single upload for GHES 3.18” [3]. Impact: if your GHES 3.18-based setup tried to upload multiple SARIFs in a way that relied on that combining behavior, you may see changes. If you paste your workflow step (the exact uses: github/codeql-action/upload-sarif@v4... line), plus the error message you’re seeing, I can pinpoint which of the above is the match and tell you the minimal change needed.
Citations:
- 1: https://github.blog/changelog/2025-10-28-upcoming-deprecation-of-codeql-action-v3/
- 2: codeql/upload-sarif@v3 action failed: Resource not accessible by integration - missing
actions: readgithub/codeql-action#2117 - 3: https://github.com/github/codeql-action/blob/main/CHANGELOG.md
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/security.yml"
echo "== File: $FILE =="
wc -l "$FILE"
echo
echo "== Lines 1-120 (to capture job/permissions context and the flagged step) =="
nl -ba "$FILE" | sed -n '1,120p'
echo
echo "== Find any permissions blocks =="
rg -n "^\s*permissions\s*:" "$FILE" || true
rg -n "actions:\s*read" "$FILE" || true
echo
echo "== List all uses: lines in this workflow =="
rg -n "^\s*uses:\s*" "$FILE"Repository: AIX-Format/PiWorker-OS
Length of output: 282
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/security.yml"
echo "== File: $FILE =="
wc -l "$FILE"
echo
echo "== Lines 1-200 (include job/permissions context + flagged step) =="
cat -n "$FILE" | sed -n '1,200p'
echo
echo "== permissions blocks =="
rg -n "^\s*permissions\s*:" "$FILE" || true
echo
echo "== actions: read occurrences =="
rg -n "actions:\s*read" "$FILE" || true
echo
echo "== uses: lines =="
rg -n "^\s*uses:\s*" "$FILE"Repository: AIX-Format/PiWorker-OS
Length of output: 1847
Pin github/codeql-action/upload-sarif@v4 and address CodeQL v4 requirements
uses: github/codeql-action/upload-sarif@v4isn’t pinned to an immutable ref (contradicts the “Pin action versions…” comments and the hash-pinning policy), so an upstream tag change could alter the action behavior.- CodeQL v4 can break
upload-sarifdepending on the runner/platform and permissions: v4 requires the Node.js 24 runtime (GHES < 3.18 may fail), andupload-sarifcan error unlesspermissions: actions: readis granted. This workflow currently only setscontents: readandsecurity-events: write. - Update the workflow to (1) add
permissions: actions: readand (2) pin the CodeQLupload-sarifaction to a specific commit SHA (and pin other actions too if your policy is blanket).
🧰 Tools
🪛 zizmor (1.25.2)
[error] 36-36: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/security.yml at line 36, The workflow step using uses:
github/codeql-action/upload-sarif@v4 is not pinned and the job lacks required
action permissions for CodeQL v4; update the job to pin the upload-sarif action
to a specific commit SHA (replace github/codeql-action/upload-sarif@v4 with
github/codeql-action/upload-sarif@<commit-sha>) and add permissions: actions:
read in addition to the existing permissions (contents: read and
security-events: write) so upload-sarif runs reliably across runners and GHES
versions; also consider pinning other actions referenced in the workflow for
consistency with the repo’s hash-pinning policy.
Bumps github/codeql-action from 3 to 4.
Release notes
Sourced from github/codeql-action's releases.
... (truncated)
Changelog
Sourced from github/codeql-action's changelog.
... (truncated)
Commits
8442bc0Release process: Automatically rebuild PRs26a1e57Merge pull request #3913 from github/henrymercer/downgrade-ava9b6438eTweak workflowb5b50d6Merge branch 'main' into henrymercer/repo-size-diff-check9665bc2Downgrade ava to version 6.4.15a80681Address review commentsDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)Summary by CodeRabbit