ci: own the CodeQL configuration instead of GitHub's default setup

[Jaro-c]

Summary

Step one of two. This replaces GitHub's CodeQL default setup with a workflow this repository owns. It deliberately does not fix the seven rust/cleartext-logging alerts; that is step two, and separating them is what makes either one measurable.

Why own it

Default setup only analyses the default branch. Every pull request lands on develop unscanned, and its alerts surface later attributed to whichever commit promoted develop to main. A finding is never attached to the change that introduced it, and a promotion presents a batch at once. It is also why measuring whether a fix worked has needed a promotion rather than a pull request — which is exactly what happened with #1599 earlier today.

And it cannot load a model pack, which is what step two needs.

What the seven alerts actually are

Worth writing down, because the first attempt at them was aimed at the wrong thing. rust/cleartext-logging takes its sources from SensitiveDataCall:

HeuristicNames::nameIndicatesSensitiveData(name, classification)

The source is the name of the called function. create_project_secrets matches on "secret", so its return value is treated as sensitive regardless of the fact that the return type is Result<()> and cannot carry a payload. Taint then follows the ? into Engine::run's error and reaches seven assertions that format it.

Two measurements that pin this down:

• resources_health.rs calls engine.up(&file).await.unwrap() eighteen times on the same tainted value and not one is flagged. Only assert! interpolating {result:?} is a sink.
• resources_health.rs:209 already asserts on the same tainted result with a plain message and no interpolation, and is not flagged.

So the fix belongs at the source, not at the seven sinks, and the query supplies ModelsAsDataBarrier for correcting a model. Rust has the extensible predicate:

extensible predicate barrierModel(path, output, kind, provenance, madId)

That is step two.

What this pull request changes, and what it must not

Where the analysis runs, not what it covers. The matrix is the same three languages default setup ran — rust, python, actions — at the same build-mode: none, on ubuntu-latest, with the same job names.

The control is that the alert count does not move. Seven open, one closed as fixed, measured on main at 88f6c36. If it moves after the switch, the migration is wrong, not the reasoning about the alerts.

Test plan

• actionlint clean on the new file, and the YAML parses
• 42 code lines, under the 300 soft limit
• Baseline captured before writing anything: run 33285480496 on 88f6c36 ran Analyze (python), Analyze (rust) and Analyze (actions), all success, event dynamic
• The action is pinned to a full SHA with a version comment, matching every other third-party action here, and github-actions is already a daily Dependabot ecosystem targeting develop
• The workflow cannot run yet. While default setup is enabled, GitHub does not run a repository's own CodeQL workflow. It starts working when the repository is switched over in Settings, which is why workflow_dispatch is here.

Order of operations

1. Merge this to develop.
2. Promote to main, so the workflow exists on the default branch.
3. Switch Settings → Advanced Security → CodeQL analysis from default to advanced. That disables default setup.
4. workflow_dispatch on main, and check three languages analysed and the alert count unchanged.
5. Only then, step two: the barrier model, verified by removing it and watching the seven come back. A barrierModel whose canonical path does not match fails silently and looks exactly like one that works, so "the alerts went away" is not evidence on its own.

Known gap, not fixed here

If somebody re-enables default setup in Settings, this workflow silently stops running and nothing in the repository would say so. A test cannot read repository settings without the API, so this is recorded rather than gated.

Checklist

• Targets develop
• Commits are signed off (DCO, git commit -s) and signed
• Labels applied
• No secrets, keys or credentials in code, logs or fixtures
• Cargo.toml and debian/changelog untouched
• Docs updated if behaviour changed. No product behaviour changed

Refs #3, #4, #5, #6, #7, #8, #9.

Signed-off-by: Jaro-c 75870284+Jaro-c@users.noreply.github.com

[Jaro-c]

Blocked, and not by anything in this pull request.

Switching this repository to advanced setup is refused at the repository level. Settings → Advanced Security → CodeQL analysis offers both "Switch to advanced" and "Disable CodeQL" greyed out, each labelled "Blocked by organization".

The source is the org security configuration "Glyndor baseline", applied to 15 repositories and set as the default for new ones. Its own description names what it pins:

dependency graph, Dependabot alerts + security updates + malware alerts, secret scanning + push protection + validity checks, CodeQL default setup, private vulnerability reporting

So the workflow here is correct and inert: the CodeQL checks on this pull request fail because GitHub will not accept an uploaded analysis from a repository whose CodeQL is owned by an enforced configuration. That is the same block seen from the other side, which is the only useful thing this pull request has measured so far.

I checked feasibility after recommending the approach rather than before, which is the mistake worth recording here: I priced the trade-off between fixing the model and fixing the seven assertions carefully, and never asked whether the repository was permitted to make the change at all.

Leaving this open rather than closing it. The code is what would be merged if the organization configuration changes, and closing it would throw away the measurement. Marking status:blocked on the decision below.

What unblocking costs. Three shapes, and only the third is scoped to this repository:

1. Detach podup from "Glyndor baseline". It would then lose the whole baseline — Dependabot, secret scanning, push protection — not just the CodeQL pin. Wrong trade.
2. Relax the configuration's enforcement so repositories can override it. That applies to all 15, weakening the baseline everywhere to solve one repository's problem.
3. A second configuration, identical to the baseline except code scanning is left unset, applied to podup alone. The other fourteen keep the baseline exactly as it is.

Third is the right shape, and it is still an organization-level change rather than a repository one, so it is the owner's call and not mine.

Signed-off-by: Jaro-c 75870284+Jaro-c@users.noreply.github.com

[Jaro-c]

The run finished and the error is explicit, so recording it here rather than leaving the cause as my reading of the settings page:

##[error]Code Scanning could not process the submitted SARIF file:
CodeQL analyses from advanced configurations cannot be processed when the default setup is enabled

All three jobs build their database fine; only the upload is rejected, on all three languages. So the workflow itself is correct and would start working the moment the organization configuration stops pinning CodeQL to default setup. Nothing to change in this branch.

Signed-off-by: Jaro-c 75870284+Jaro-c@users.noreply.github.com

[Jaro-c]

Closing. podup stays on CodeQL default setup, so this workflow has no use: while the organization configuration pins code scanning, GitHub refuses the analysis it uploads, which is what the three red checks here are.

What this decides, stated plainly rather than left implicit:

The barrier model is out of reach. rust/cleartext-logging takes its sources from SensitiveDataCall, which matches on the name of the called function — create_project_secrets is a source because it contains "secret", not because of anything its Result<()> can carry. The query provides ModelsAsDataBarrier for correcting exactly that, and Rust has the extensible predicate for it, but a model pack needs a configuration this repository owns. Default setup cannot load one. So the fix that would have addressed the cause rather than the seven sinks is not available here.

CodeQL still will not see a pull request. It runs on the default branch only, so everything lands on develop unscanned and its alerts surface later attributed to whichever commit promoted develop to main. That is why measuring the effect of #1599 needed a promotion rather than a pull request, and it stays that way.

What remains for the seven alerts is the narrower fix. Remove the tainted value from the seven assertion messages, which is certain to work — resources_health.rs:209 already asserts on the same tainted result with a plain message and is not flagged — at the cost of those seven losing the error they print, and without preventing the eighth. That is the option to take up if the alerts are to be closed by code rather than by a dismissal.

Not deleting the branch. The workflow here is what would be merged if the organization configuration ever changes, and its three red checks are the measurement that the block is upstream rather than in this file:

Code Scanning could not process the submitted SARIF file:
CodeQL analyses from advanced configurations cannot be processed when the default setup is enabled

Signed-off-by: Jaro-c 75870284+Jaro-c@users.noreply.github.com