Code scanning: model dw/security.py's validators, fix the two real findings

[dkackman]

The 27 open code scanning alerts were 26 copies of one false positive and one real finding.

Why there were 26

Every flagged filesystem access already reaches the disk through validate_path, which resolves with os.path.realpath and then raises unless the result is the base directory or a descendant of it — exactly the normalize-then-check shape py/path-injection looks for. But that query recognizes the check only as a local barrier guard. A validator that lives in another module and returns the safe path rather than guarding a branch is invisible to it, so every route touching a file gets flagged. Dismissing the alerts one by one would not stop the next one.

What this does

Teaches the query about the validators, in a local query pack (.github/codeql/dw-security/) that models them as sanitizers, with the built-in query it replaces filtered out. Loading a pack needs advanced setup, so scanning moves off GitHub's default setup to .github/workflows/codeql.yml — same three languages (actions, javascript-typescript, python), same weekly schedule.

It is deliberately not a blanket suppression:

• validate_path(path, base) is a barrier only when base is not None; with None it is modeled as PathNormalization, so the path stays reportable until something checks it.
• Code that reaches the disk without a validator still flags at high severity. That signal is what the 26-alert wall was hiding, and CLAUDE.md now says so.

The trade is that dw/security.py becomes trusted by the query rather than checked by it — documented at the top of DwPathSanitizers.qll, where it points at tests/test_security.py as the place containment is actually established.

The two genuine findings, fixed rather than modeled

• resolve_workflow_reference called os.path.isfile on the submitted path before any containment check, so a workflow_path could probe for files anywhere on disk. Containment now comes first, and is re-applied to the path that is returned rather than trusted from source_for_path's answer about it.
• /api/validate returned str(e) of an unexpected validator exception to the client (py/stack-trace-exposure). It now logs the detail and reports the category, as the handler 15 lines above it already did. The test that pinned the old behaviour now pins the new contract: generic message out, "boom" only in the log.

Verification

Run locally with the CodeQL CLI 2.26.4 against a database built from this tree:

	built-in py/path-injection	modeled dw/path-injection
results	39	0

py/stack-trace-exposure: 1 before → 0 after. Full test suite: 3293 passed, 5 skipped. black --check clean.

Caveat worth knowing

Advanced setup means we own the workflow file — GitHub's automatic query-suite and CLI updates stop being invisible, and github/codeql-action needs Dependabot to stay current. That is the cost of custom queries; there is no way to load a pack under default setup.

Default setup is already disabled

It had to be: GitHub rejects SARIF from an advanced configuration while default setup is enabled (Code Scanning could not process the submitted SARIF file: CodeQL analyses from advanced configurations cannot be processed when the default setup is enabled), which is what the first red checks on this PR were. Turned off via PATCH /code-scanning/default-setup; re-enabling is one API call if this is ever reverted.

With it off, all three languages upload cleanly, and the python job's log shows the pack doing its job in CI, not just locally:

Recording pack reference dw/security-queries at .../.github/codeql/dw-security
Compiled .../DwPathInjection.ql
Evaluation done; writing results to dw/security-queries/DwPathInjection.bqrs
Interpreting code scanning results for python

After merge: the 27 existing alerts close as fixed once master is analyzed.

🤖 Generated with Claude Code