ci: re-pin codeql-action to the true v4.38.0 commit

[hyperpolymath]

Re-pin codeql-action to the true v4.38.0 commit

This repo pinned github/codeql-action to a commit whose trailing comment said # v4.38.0.
It is not v4.38.0. Dereferencing both annotated tags:

tag	tag object	commit
v4.38.0	4bd7200e	b96794f015dfd88f77b49b1c93e0fa7110f94c63
v4.38.1	c23de5a8	1c5b675653bb5c22dbe9b12b556ec555138e09fd

So the pin was v4.38.1 — the version blocked estate-wide (nexia-list#100) — wearing a
v4.38.0 label. The comment lied; in several repos the actions.lock recorded
ref: 'v4.38.1' for the same SHA and had been telling the truth all along.

Where the ref was a bare tag @v4.38.1, it was additionally unpinned — a mutable ref
upstream can re-point at any time. Those are now pinned to a SHA and moved off the blocked
version.

Why one commit

GitHub compares actions.lock to the workflow by literal string. A lock edit and a workflow
edit that disagree — even for one commit — produce a startup_failure, not a stale lock. So the
workflow uses:, the lock's workflows: reference, the dependencies: record
(ref, commit, key) and any nested uses: sub-list all move together here.

Several of these workflows are dead on main right now

A base-state census of all 40 affected repos compared each workflow's literal uses: ref against
its own actions.lock entry before any change:

lock state for the affected workflow	repos	status on main
no actions.lock at all	14	runs — workflow-only rewrite
entry agrees with the workflow	19 instances	runs — lock and workflow move together here
entry already names b96794f0… while the workflow still pins the blocked SHA	16 instances	startup_failure — dead
no entry for that workflow path	2 instances	runs (enforcement is per-path opt-in)

That third row is the important one. In those repos the lock had already been moved to the
correct v4.38.0 commit and the workflow never followed, so the two disagree and GitHub rejects the
run at startup. Directly observed: hyperpolymath/scripts reports CodeQL Security Analysis startup_failure on its current main head.

So for those repos this PR is not hygiene — it resurrects a CodeQL workflow that has not run at
all. Expect previously-absent checks to appear; a red among them is a scanner speaking for the
first time, not a regression.

The last row was measured, not assumed: a missing lock entry leaves a workflow unvalidated and it
runs normally (metadatastician/metadatastician-governance, whose lock covers 3 of 8 workflows).
Only a disagreeing entry is fatal. No lock keys are added here — adding one would newly enable
enforcement for a workflow that is currently exempt, which is a policy change, not a repair.

How this was verified before it was written

The transformer was dry-run against fetched copies of every distinct shape in the estate and the
result checked semantically at the YAML level, not by reading a diff:

• the codeql-action record reads exactly ref: v4.38.0, commit: sha1-b96794f0…, with
  owner_id/repo_id untouched;
• every workflows: edge and every nested uses: edge resolves to a record — the lock stays
  transitively closed, which is what actually keeps jobs from vanishing;
• no file anywhere still names the blocked version;
• a line-conservation invariant holds: every output line is an input line, possibly retargeted.
  A line may only be dropped as a rename-collapse duplicate, and every drop is reported.

The dry run caught three destructive bugs before any repo was touched — an over-eager dedupe that
deleted pre-existing legitimate refs, a record-body pattern that silently dropped 12-space nested
uses: lists, and a line rebuild that ate the - of list-item uses:.

Mutation-tested, because a passing check proves nothing until it kills a mutant: blinding the
workflow rewriter and blinding the lock retarget were both caught by the cross-file lock guard;
the unmutated control reports LOCK-OK.

Expected effect

CodeQL moves from the blocked v4.38.1 to v4.38.0. Any red here that predates this commit is
pre-existing and is tracked separately under the stopping rule — a new scanner finding is an issue
with acceptance criteria, not a merge blocker.

Refs hyperpolymath/standards#1005.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 67766128-0c47-4a95-b044-a76d88fb1902

📥 Commits

Reviewing files that changed from the base of the PR and between c87e422 and adefc0e.

📒 Files selected for processing (2)

• .github/workflows/codeql.yml
• .github/workflows/hypatia-scan.yml

 __________________________________________________________________________
< This function returns three different shapes. It's basically modern art. >
 --------------------------------------------------------------------------
  \
   \   \
        \ /\
        ( )
      .( o ).

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🔍 Hypatia Security Scan

Findings: 70 issues detected

Severity	Count
🔴 Critical	6
🟠 High	27
🟡 Medium	37

⚠️ Action Required: Critical security issues found!

View findings

[
  {
    "reason": "Required workflow `scorecard.yml` is absent from .github/workflows/. The estate baseline expects it; without it this repository is unscanned for whatever that workflow covers, and its absence is silent — no job fails, because no job runs.",
    "type": "missing_workflow",
    "file": "scorecard.yml",
    "action": "create",
    "rule_module": "workflow_audit",
    "severity": "high"
  },
  {
    "reason": "Workflow executes remote script directly (curl/wget piped to shell). Download, verify checksum/signature, then execute.",
    "type": "download_then_run",
    "file": "ui-ci.yml",
    "action": "verify_download_integrity",
    "rule_module": "workflow_audit",
    "severity": "high"
  },
  {
    "reason": "Job `trigger-boj` in boj-build.yml has no `timeout-minutes:` declaration. Default is 6 hours — a stuck codeload fetch or runner hang can burn budget. Add `timeout-minutes: 10` (or proportional).",
    "type": "missing_timeout_minutes",
    "file": "boj-build.yml",
    "action": "flag",
    "rule_module": "workflow_audit",
    "severity": "medium",
    "recipe_id": "recipe-add-workflow-timeout-minutes",
    "job": "trigger-boj"
  },
  {
    "reason": "Job `build` in casket-pages.yml has no `timeout-minutes:` declaration. Default is 6 hours — a stuck codeload fetch or runner hang can burn budget. Add `timeout-minutes: 10` (or proportional).",
    "type": "missing_timeout_minutes",
    "file": "casket-pages.yml",
    "action": "flag",
    "rule_module": "workflow_audit",
    "severity": "medium",
    "recipe_id": "recipe-add-workflow-timeout-minutes",
    "job": "build"
  },
  {
    "reason": "Job `deploy` in casket-pages.yml has no `timeout-minutes:` declaration. Default is 6 hours — a stuck codeload fetch or runner hang can burn budget. Add `timeout-minutes: 10` (or proportional).",
    "type": "missing_timeout_minutes",
    "file": "casket-pages.yml",
    "action": "flag",
    "rule_module": "workflow_audit",
    "severity": "medium",
    "recipe_id": "recipe-add-workflow-timeout-minutes",
    "job": "deploy"
  },
  {
    "reason": "Job `analyze` in codeql.yml has no `timeout-minutes:` declaration. Default is 6 hours — a stuck codeload fetch or runner hang can burn budget. Add `timeout-minutes: 10` (or proportional).",
    "type": "missing_timeout_minutes",
    "file": "codeql.yml",
    "action": "flag",
    "rule_module": "workflow_audit",
    "severity": "medium",
    "recipe_id": "recipe-add-workflow-timeout-minutes",
    "job": "analyze"
  },
  {
    "reason": "Job `a2ml-validate` in dogfood-gate.yml has no `timeout-minutes:` declaration. Default is 6 hours — a stuck codeload fetch or runner hang can burn budget. Add `timeout-minutes: 10` (or proportional).",
    "type": "missing_timeout_minutes",
    "file": "dogfood-gate.yml",
    "action": "flag",
    "rule_module": "workflow_audit",
    "severity": "medium",
    "recipe_id": "recipe-add-workflow-timeout-minutes",
    "job": "a2ml-validate"
  },
  {
    "reason": "Job `dogfood-summary` in dogfood-gate.yml has no `timeout-minutes:` declaration. Default is 6 hours — a stuck codeload fetch or runner hang can burn budget. Add `timeout-minutes: 10` (or proportional).",
    "type": "missing_timeout_minutes",
    "file": "dogfood-gate.yml",
    "action": "flag",
    "rule_module": "workflow_audit",
    "severity": "medium",
    "recipe_id": "recipe-add-workflow-timeout-minutes",
    "job": "dogfood-summary"
  },
  {
    "reason": "Job `k9-validate` in dogfood-gate.yml has no `timeout-minutes:` declaration. Default is 6 hours — a stuck codeload fetch or runner hang can burn budget. Add `timeout-minutes: 10` (or proportional).",
    "type": "missing_timeout_minutes",
    "file": "dogfood-gate.yml",
    "action": "flag",
    "rule_module": "workflow_audit",
    "severity": "medium",
    "recipe_id": "recipe-add-workflow-timeout-minutes",
    "job": "k9-validate"
  },
  {
    "reason": "Job `scan` in hypatia-scan.yml has no `timeout-minutes:` declaration. Default is 6 hours — a stuck codeload fetch or runner hang can burn budget. Add `timeout-minutes: 10` (or proportional).",
    "type": "missing_timeout_minutes",
    "file": "hypatia-scan.yml",
    "action": "flag",
    "rule_module": "workflow_audit",
    "severity": "medium",
    "recipe_id": "recipe-add-workflow-timeout-minutes",
    "job": "scan"
  }
]

Powered by Hypatia Neurosymbolic CI/CD Intelligence