GitHub CodeQL Baseline Reference

Date: 2026-04-08

Purpose

This note records the repository decision for GitHub CodeQL rollout and the specific operational assumptions used in S82.

GitHub Docs: Configuring default setup for code scanning
- Default setup is recommended when first enabling code scanning because it chooses the simplest working analysis method automatically.
- Default setup can be edited for languages/query-suite choices, but it remains UI-managed.
GitHub Docs: Configuring advanced setup for code scanning
- Advanced setup is the path for repository-owned workflow configuration.
- Advanced setup uses a committed workflow file and standard GitHub Actions syntax.
- The generated workflow normally scans on push, pull_request, and schedule.
GitHub Docs: CodeQL code scanning for compiled languages
- build-mode: none is valid for interpreted languages and is acceptable for Python and JavaScript/TypeScript in this repository.

Keep CodeQL in the GitHub Actions security-validation layer, not as a new local mandatory SOP command.
Use an in-repo workflow (.github/workflows/codeql.yml) so security scanning policy is reviewable in git.
Start visibility-first:
- no immediate merge-blocking policy based solely on CodeQL
- use findings as triage input while the backlog is still being reduced
Cover the repository languages that matter for the current risk surface:
- python
- javascript-typescript
- actions

The repository now uses the committed .github/workflows/codeql.yml workflow as the authoritative advanced CodeQL baseline.
GitHub default setup was switched to not-configured during S91, so scanner policy now lives in version control instead of the repository UI.
The first successful advanced-baseline runs completed on main during the residual security closeout wave.
Local acceptance for CodeQL workflow changes must use repo-local seam tests against the workflow contract; do not require a full local CodeQL run unless a future task explicitly asks for it.