codeql: bind SARIF source paths to the exact target git tree

[seonghobae]

Finding

A fresh central CodeQL dispatch for ContextualWisdomLab/LineageWeave#899 produced a Python security finding whose reported source path does not exist in either the exact target PR head or its protected base.

Exact canary — 2026-09-22:

• target PR: ContextualWisdomLab/LineageWeave#899
• protected base: 83eba56149eb802cd63642c507c324c9976ec78e
• exact head: c943060c7c16f74faf48d1ee40eaa5301c830065
• canonical producer run: .github 35652904176
• Python job: 106584641313
• SARIF gate: one unsuppressed Medium+ py/clear-text-storage-sensitive-data, security severity 7.5
• reported location: docs/release/3.6.0/scripts/keyverse_oidc_operator_smoke.py:28
• retained artifact: codeql-dispatch-python-35652904176-1, artifact id 10678357938, SHA-256 afc159e5abbf72bcbac212fa059420aaebca52d55a47664a247ccb0214b61ef5

Fresh target-source reads contradict that location:

• Contents API at exact head c943060c...: 404 for docs/release/3.6.0/scripts/keyverse_oidc_operator_smoke.py;
• Contents API at protected base 83eba561...: 404 for the same path;
• recursive Git tree for exact head contains neither that file nor docs/release/3.6.0;
• organization code search for keyverse_oidc_operator_smoke.py returns zero results.

Therefore this SARIF result is not admissible as a LineageWeave product-source finding until the central producer can bind the analyzed path to the exact target Git tree. This issue does not claim the precise contamination mechanism yet.

Current trust gap

Protected codeql-scan-dispatch.yml materializes each target shard by running git init, adding the target remote, fetching the exact HEAD_SHA, detached checkout, and git cat-file -e "$HEAD_SHA^{commit}". That proves the requested commit object is present, but the present acceptance contract does not independently prove that every file analyzed by CodeQL / emitted in SARIF belongs to git ls-tree for the exact target commit, nor does it classify a non-tree SARIF path as provenance failure rather than a target vulnerability.

Do not solve this by suppressing the CodeQL rule, deleting the reported path from SARIF, weakening the Medium+ gate, or changing LineageWeave source to satisfy a finding against a nonexistent target path.

RED requirement

Add a deterministic central regression that exercises the real dispatch materialization/analyze boundary and proves a non-tree source can become visible to the scanner or SARIF path validation is otherwise absent. The fixture should use an untracked/stale Python file with a recognizable CodeQL result and must remain bound to an exact target commit identity.

If the apparent non-tree path is instead caused by SARIF path rewriting, extraction, or artifact interpretation rather than workspace contamination, the RED should reproduce that actual mechanism. Do not encode a guessed root cause into the test.

Minimum causal repair

1. Materialize CodeQL source in a clean, dedicated target workspace or equivalently establish a fail-closed clean-tree boundary before analysis.
2. Verify the checked-out commit/tree identity, and reject unexpected tracked/untracked source material that is not part of the declared execution contract.
3. Before promoting a SARIF result as target-source evidence, bind each relevant artifactLocation.uri to the exact target Git tree. Intentional generated files, if any, need a separately typed and documented provenance contract; unknown non-tree paths fail closed as source_provenance_unbound, not as a product vulnerability.
4. Preserve the existing exact repository/PR/base/head dispatch validation, immutable CodeQL action pins, Medium+ severity gate, SARIF artifact retention, and fail-closed semantics.
5. Re-read live PR/head identity before terminal receipt publication; stale-head evidence remains non-passing.

GREEN acceptance

• a hostile/non-tree fixture cannot become a target-source security finding;
• every accepted source-backed SARIF result is demonstrably present in the exact target Git tree or a separately authenticated generated-source provenance set;
• the LineageWeave fix(scheduler): fail after summarized action errors #899 canary no longer reports docs/release/3.6.0/scripts/keyverse_oidc_operator_smoke.py as LineageWeave source when that path is absent from its exact tree;
• genuine in-tree CodeQL findings remain visible and blocking;
• no scanner suppression, synthetic success, manual status, mutable consumer copy, or gate weakening is introduced.

Related but separate owners: #2276 owns target GHAS code-scanning/analyses read 403; #1929 owns cross-repository terminal status publication. This issue owns analyzed-source/SARIF-to-exact-tree provenance only.

[seonghobae]

Correction after fresh artifact inspection: the premise of this issue is invalid. The live artifact inventory for producer run 35652904176 shows Python artifact id 10677342334, name codeql-dispatch-python-35652904176-1, digest sha256:f9312c6a435fabb4cf3504319f77c435535e6acf7fc1c65c192f0c1dc476c3c6. I downloaded that exact artifact and parsed python.sarif; it contains exactly two source findings, both in the exact LineageWeave target tree: py/insecure-protocol at lineageweave/http_client.py:193 and py/polynomial-redos at lineageweave/post_chat.py:48. It contains no result for docs/release/3.6.0/scripts/keyverse_oidc_operator_smoke.py.

Those two findings are already owned by LineageWeave #974, whose current source replaces the regex normalization with linear rstrip("?.!") and constructs a certifi-backed SSL context with minimum_version = TLSv1_2 before use. The #899 producer artifact is therefore protected/current-parent evidence for that existing owner lane, not evidence of non-tree SARIF contamination.

The artifact id/digest and phantom path recorded in this issue do not match the live run inventory. There is no valid central provenance delta to implement from this issue as written. Closing as invalid/no valid delta rather than weakening or changing CodeQL.