ci: scan pull requests from forks with CodeQL advanced setup

[napetrov]

Description

Problem: CodeQL never sees pull requests from forks

This repository uses CodeQL default setup (languages actions and python, weekly schedule). GitHub documents that default setup scans pull requests "excluding pull requests from forks" (About setup types). Almost all of our pull requests come from forks, so findings only appear after merge, when main is scanned:

• 56 of the 60 open pull requests come from forks.
• None of the last 100 runs of the dynamic CodeQL workflow (dynamic/github-code-scanning/codeql) was for a fork pull request. All of them were for main, for branches in this repository, or for pull requests opened from such branches.
• Open alerts #15, #16 (actions/cache-poisoning/poisonable-step, high) and #17 (actions/missing-workflow-permissions, medium) were first raised on main within a minute of merging fork pull requests ci: deny cache-service access to code the Bazel tests check out #3776 (alerts 15/16) and Feature/win arm64 support #3718 (alert 17). Neither pull request got a CodeQL result before it was merged.

Change: CodeQL advanced setup

.github/workflows/codeql.yml runs the same analysis as a regular workflow, so it also runs on pull_request events from forks:

• Triggers: pull_request to main, push to main, and weekly on Thursdays at 08:10 UTC (10 8 * * 4), the slot default setup's scheduled scans used. No path filters: both languages build with build-mode: none and finish in about 2 minutes (measured below), so filtering would save little and could miss workflow changes.
• Same scope as default setup: languages actions and python, the default query suite, and the categories /language:actions and /language:python. Because the categories match, the existing alerts keep their numbers and history when advanced setup takes over.
• Least privilege: contents: read at workflow level. Only the analyze job adds security-events: write. persist-credentials: false on checkout. Actions are pinned by SHA, like the rest of .github/workflows. For fork pull requests GitHub downgrades the token to read-only. Code scanning still accepts their results: in oneTBB, which already uses advanced setup, the python job on a pull request from Arthur031221/oneTBB logs Successfully uploaded results / Analysis upload status is complete.
• Merge blocking: for each pull request, code scanning creates a CodeQL check run that fails only on alerts the pull request introduces. Existing alerts on main do not fail it.

Required step after merge: switch default setup to advanced (repository admin)

Default setup and advanced setup cannot both be active: while default setup is on, GitHub blocks CodeQL uploads from workflows. An admin has to switch it off right after this pull request is merged:

1. Settings → Code security (Advanced Security) → Code scanning → CodeQL analysis.
2. In the CodeQL analysis row, open the ⋯ menu → Switch to advanced.
3. In the pop-up, click Disable CodeQL. This turns off default setup only; this workflow stays enabled.
4. Re-run the CodeQL workflow on main (or wait for the next push) and check that both /language:actions and /language:python analyses are uploaded under Security → Code scanning → Tool status.

The same is possible from the CLI:

gh api -X PATCH repos/uxlfoundation/oneDAL/code-scanning/default-setup -f state=not-configured

Observed on this pull request: default setup is still on, so both Analyze (...) jobs run to the upload step and then fail with Code Scanning could not process the submitted SARIF file: CodeQL analyses from advanced configurations cannot be processed when the default setup is enabled (run 37218373184). That failure says nothing about the workflow itself, and it goes away once step 3 is done. It does confirm the cross-repository part: on a pull request from a fork, the workflow runs and reaches the upload step.

Optional, to make it blocking: main currently has no required status checks, so a failing CodeQL check shows on the pull request but does not prevent merging. To enforce it, add a branch ruleset for main with Require code scanning results → tool CodeQL, security alerts High or higher, alerts Errors.

Validation

1. Local reproduction of the live alerts. CodeQL CLI 2.27.1 (the version that produced the alerts), codeql/actions-queries code-scanning suite, on main at 43a87bf. It reports exactly the three open alerts: nightly-test.yml:227, nightly-test.yml:235, ci-win.yml:68. With this branch applied it reports the same three and nothing from codeql.yml.
2. Linters. actionlint 1.7.7: clean. zizmor 1.30.1 (default persona): no findings.
3. End-to-end in a fork. In napetrov/oneDAL, which has default setup off, I pushed this workflow to a base branch, then opened a pull request that adds a deliberately vulnerable workflow (pull_request_target + checkout of github.event.pull_request.head.sha + run, with contents: write):
   • Base branch push: Analyze (actions) succeeded in 38 s and uploaded 3 results (the alerts above). Analyze (python) succeeded in 113 s and uploaded 0 results.
   • Pull request: the CodeQL check run failed with "1 new alert including 1 critical severity security vulnerability". Its annotation was on the planted checkout line: actions/untrusted-checkout/critical, "Checkout of untrusted code in a privileged context". The three existing alerts did not count against the pull request.
   • That test pull request (napetrov/oneDAL#82) was opened within the fork, so it does not exercise the cross-repository path. That path is covered by the oneTBB run above.

Not in this pull request

• Fixing alerts getWeightsAndBiasesDerivatives(0) returns several BIG NUMBERS #15/another failed test case with BIG numbers in weights and biases #16 (nightly-test.yml, flagged only for its workflow_dispatch trigger) belongs in a separate change. The likely fix is to declare cache-mode: none for that workflow and then dismiss the two alerts, because the query does not model cache-mode.
• Alert Any plan to support Random Forests or Decision Trees classification/regression algorithm? #17 is addressed by fix(ci): compare the ABI against the commit under test, and give Windows CI a permissions block #3838.

---

Checklist:

Completeness and readability

• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation to reflect the changes or created a separate PR with updates and provided its number in the description, if necessary. (The admin step is documented in this description.)
• Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details).
• I have resolved any merge conflicts that might occur with the base branch.

Testing

• I have run it locally and tested the changes extensively.
• All CI jobs are green or I have provided justification why they aren't. (The CodeQL upload on this pull request fails until default setup is switched off; see above.)
• I have extended testing suite if new functionality was introduced in this PR. (Not applicable: CI configuration only, validated end-to-end as described.)

Performance

• I have provided justification why performance and/or quality metrics have changed or why changes are not expected. (CI-only change; no library code touched.)

🤖 Generated with Claude Code

[Copilot]

Copilot review overview

🟢 Approval recommended

The workflow is narrowly scoped, correctly configured, and its expected transitional failure is documented and validated.

Review effort: Balanced
Findings: None

What changed in this PR

Adds advanced CodeQL scanning so fork pull requests are analyzed before merge.

Changes:

• Scans Actions and Python on pull requests, main pushes, and weekly.
• Applies least-privilege permissions, pinned actions, and concurrency controls.
• Preserves existing CodeQL alert categories.

File	Description
.github/​workflows/​codeql.yml	Defines the advanced CodeQL workflow.

---

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

[david-cortes-intel]

I see errors:

Waiting for processing to finish
  Analysis upload status is failed.
Error: Code Scanning could not process the submitted SARIF file:

[ethanglaser]

Remove this before merge, but do the recommended action after merging.

[napetrov]

Removed in ae9c9a9. The switch-to-advanced steps stay in the pull request description, and I will do them right after this merges.

[ethanglaser]

Is this aligned with what happens currently? Seems like a random schedule

[napetrov]

Good catch, it was arbitrary. Default setup does not expose its cron, so I looked at its scheduled runs on main (runs that re-scanned a SHA that had already been scanned). They land on Thursdays at 08:10 UTC: 2025-12-18, 2026-02-19, 2026-03-26 and 2026-05-14 all at exactly 08:10, and 2026-06-18 at 08:19. ae9c9a9 switches the schedule to 10 8 * * 4, the same slot (next runs: Oct 8, 15, 22).

[ethanglaser]

I see errors:

Waiting for processing to finish
  Analysis upload status is failed.
Error: Code Scanning could not process the submitted SARIF file:

This is expected until settings are changed to advanced. When this happens the CodeQL scans will not run on upstream PRs so it only makes sense to do this after this is merged (or could do it immediately before, but probably not necessary to check this PR)

[napetrov]

setup changes - step runs now -
https://github.com/uxlfoundation/oneDAL/actions/runs/37338077291/job/111860494721