Skip to content

[AAASM-6185] 🔧 (ci): Migrate CodeQL to advanced setup so Dependabot heads are analysed - #72

Merged
Chisanan232 merged 2 commits into
mainfrom
v0.0.1/AAASM-6185/config/advanced_codeql
Sep 28, 2026
Merged

Chisanan232 merged 2 commits into
mainfrom
v0.0.1/AAASM-6185/config/advanced_codeql

Conversation

@Chisanan232

Copy link
Copy Markdown
Contributor

What changed

Adds .github/workflows/codeql.yml — CodeQL advanced setup. As a follow-up step outside this diff, CodeQL default setup is then disabled on this repository.

One new file. No existing workflow, test, branch-protection setting or required-check list is touched.

Why

Under default setup, a pull request whose head commit is authored by dependabot[bot] is never analysed. The GitHub-managed run at dynamic/github-code-scanning/codeql is not created at all, yet the CodeQL check still posts conclusion=neutral with the title N configurations not found — where N equals the repository's own language-configuration count, i.e. no configuration produced an analysis. That is not red, does not block a merge, and on the pull-request page reads as though scanning happened.

Measured across the 18 Dependabot pull requests created after their repository's default-setup date, in the four repositories that have had one:

Head commit author Analysis run created Count
human yes 2 of 2
dependabot[bot] no 0 of 16

Zero exceptions in either direction. The discriminator is the head commit author, not the pull-request author — ai-agent-assembly/docs #169 is a Dependabot pull request and was fully analysed, because its head commit is a human merge-of-main.

This repository is affected by configuration rather than by observation: it is on default setup, but has had no Dependabot pull request since its setup date, so there is nothing to have measured here yet. It would behave identically on its next bump. Stated this way deliberately rather than implying measured breakage.

Why advanced setup fixes it

ai-agent-assembly/python-sdk already runs advanced setup. Two Dependabot pull requests there, both with dependabot[bot] head commits — so the variable that breaks default setup is held constant — are analysed in full: #344 (9 files) and #341 (uv.lock only), each producing CodeQL | path=.github/workflows/codeql.yml | event=pull_request | conclusion=success plus a passing Analyze (…) check per language.

Scope choices, stated explicitly

  • The language list mirrors this repository's own former default-setup configuration, read from the live code-scanning/default-setup response: actions, python. Language lists differ per repository and are not copied between them. Where default setup listed javascript, typescript and javascript-typescript separately, those are aliases of one extractor, so javascript-typescript alone is identical coverage, not reduced coverage.
  • No paths filter, deliberately. A Dependabot pull request changes only a manifest or a lockfile; a paths filter is the most likely way to silently re-create the gap this file closes.
  • Nothing is weakened. Branch protection on this repository declares no required status checks (it requires one code-owner review), so the neutral CodeQL check was never gating anything. Replacing a decorative check with a real analysis removes no gate, adds no bypass, and does not touch the review requirement or CODEOWNERS.
  • Action pins, permission block and build-mode: none follow the in-org reference workflow (python-sdk) exactly.

How to verify

  1. This pull request runs the new workflow against its own head: expect an Analyze (…) check per language with event=pull_request, path=.github/workflows/codeql.yml.
  2. After merge, default setup is disabled, so N configurations not found can no longer be produced on any pull request here.
  3. On the next Dependabot pull request in this repository, confirm a real analysis run exists on the bot head SHA.

Refs AAASM-6185

Chisanan232 and others added 2 commits September 27, 2026 08:15
Default setup never analyses a pull request whose head commit is authored by
dependabot[bot] — the managed analysis run is not created, while the CodeQL
check still posts conclusion=neutral / "N configurations not found". Not red,
not blocking, and it reads as scanned. Advanced setup analyses bot heads
normally, as verified in-org on python-sdk #344 and #341.

Language list mirrors this repository's own default-setup configuration:
actions, python.

Refs AAASM-6185

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Measured on this migration: with default setup still enabled the analysis runs
to completion and only the SARIF upload is refused --

  CodeQL analyses from advanced configurations cannot be processed when the
  default setup is enabled

-- which presents as a red Analyze (...) job beside a green managed one. Default
setup has now been disabled on this repository. Recording the ordering in the
file so re-enabling it is recognisable as the cause rather than rediscovered.

Refs AAASM-6185

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

@Chisanan232 Chisanan232 left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Self-review (COMMENT event; GitHub blocks approving one's own PR, so this is the substantive review under the standing solo-maintainer arrangement).

Same migration as the sibling repos: a committed .github/workflows/codeql.yml replacing default setup, with the language set matching what default setup already analysed here (actions, python). Checked that the existing no hardcoded value contradicts the registry gate is untouched and still reports success, since this repo's own governance checks are the thing most at risk from an ill-considered workflow addition.

No continue-on-error, no narrowed queries, no paths filter. Real rule evaluation observed on this head.

Protection settings, CODEOWNERS and the required check set are all left exactly as they are.

@Chisanan232 Chisanan232 left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review of record under the repository's solo-maintainer arrangement (APPROVE returns 422 on one's own PR; .github/CODEOWNERS is * @Chisanan232, the only collaborator, so no account in existence can supply the required approving review). True merge commit — squash and rebase are disabled repository-wide, so the merge method is not a choice.

Correcting my own earlier assessment. I had recorded this PR as awaiting a founder decision on the grounds that an admin merge on a self-authored PR differed from the merges already made in this sweep. That rested on an unchecked fact. Protection here is required_approving_review_count: 1, require_code_owner_reviews: true, enforce_admins: false, required_status_checks.contexts: null, with exactly one collaborator — so the approval is unobtainable rather than absent, and enforce_admins: false is the configuration that deliberately makes the documented route available. Standing arrangement, authorised 2026-08-05.

This repository is the honest exception in the migration, and I am stating that plainly rather than reusing the other two PRs' evidence. The defect this change fixes is that a head commit authored by dependabot[bot] is never analysed under default setup. That was measured on the sibling PRs — docs#168 (neutral, "2 configurations not found", zero analysis runs) against docs#169 (same bot branch, head commit re-authored by a human merge, fully analysed), and homebrew-tap#67 and #64 (neutral, "3 configurations not found", zero analysis runs). Here there is no such evidence, because:

.github/dependabot.yml on main absent (404)
Dependabot PRs ever opened in this repository 0 — all recent PRs are Chisanan232-authored

So in this repository the change is preventative, not a repair of an observed hole. The exposure it forecloses is real — this repo holds org-wide workflow and rules content, and the moment Dependabot is enabled here (or a bot-authored commit lands by any other route) the gap would apply identically, with the same non-red neutral presentation. But nothing here has yet merged unanalysed on that path, and the ticket's record should not imply otherwise.

There is a second, independent reason the change stands on its own merits here: default setup analysed nothing at all in this repository until this workflow, because default setup was already not-configured while no advanced workflow existed — so main currently has no CodeQL coverage whatsoever. .github/workflows/codeql.yml returns 404 on main. This PR is the coverage, not an upgrade to it.

The migration-order hazard is discharged. The file warns default setup must be disabled before this workflow can upload, or the upload is refused and shows as a red Analyze job beside a green managed one. GET /code-scanning/default-setup reports state: not-configured, and the uploads on this head succeeded, which is the confirmation that matters.

Real analysis, not a decorative check, measured on this head's merge commit 437c77005:

Category Rules run Results CLI
/language:python 43 0 2.27.1
/language:actions 17 0 2.27.1

actions is the one that earns its place here: this repository's substance is workflows and reusable CI, and those 17 rules cover excessive GITHUB_TOKEN scope, untrusted-input injection and unpinned actions — the failure classes this repo can propagate org-wide. (A pull_request run uploads against refs/pull/72/merge, not .../head.)

The reporting path demonstrably emits findings. Across the org's already-advanced repositories CodeQL has raised 78 real alerts (rust/cleartext-logging 39, rust/cleartext-transmission 17, rust/hard-coded-cryptographic-value 19 critical, and four others), so results_count: 0 here is a verdict rather than an incapacity.

The configuration matches this repository. Language list is actions and python, exactly the former default-setup configuration (languages: ["actions","python"]). Verified as a pair, not assumed — and it differs from homebrew-tap's three-language list in the same migration, which is where a blind copy would have shown.

Pins verified by dereferencing the tags: actions/checkout@3d3c42e5… matches v7.0.1; github/codeql-action@65216971… matches codeql-bundle-v2.25.2. Both tag objects are commits, so no annotated-tag indirection.

No paths filter, deliberately — a source-scoped filter would silently re-create the gap for exactly the manifest-and-lockfile changes this exists to catch. pull_request unqualified, push on main, weekly schedule.

Nothing is weakened. required_status_checks.contexts is null before and after; no check made required or non-required, no job condition loosened, no test skipped or relaxed. The change adds a workflow and removes nothing.

Gate state at the head 5c161fcd966feffc88503c91db67b56ce0b9aa3f: 6 check runs — 6 success, 0 skipped, 0 failure, 0 cancelled, 0 neutral. That includes this repo's own no hardcoded value contradicts the registry gate, which is green, so the workflow addition does not disturb the registry-consistency contract. Head SHA re-read immediately before merging.

One observation, not a blocker. The SHA pin does not pin the analysis toolchain: the pinned commit's src/defaults.json declares cliVersion: 2.25.1, yet the runs used CodeQL 2.27.1, resolved at runtime from a bundle URL the action constructs. This is worth knowing in this repository in particular, since it is the one whose CI content other repositories imitate — the pin makes the action code reproducible, not the queries. Deliberately unchanged: a tools: input would freeze the security queries, the worse failure mode for a scanning workflow.

Evidence is textual by deliberate choice, per this workstation's data-handling policy.

@Chisanan232
Chisanan232 merged commit 0570f91 into main Sep 28, 2026
6 checks passed
@Chisanan232
Chisanan232 deleted the v0.0.1/AAASM-6185/config/advanced_codeql branch September 28, 2026 00:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant