security: make central dependency-review unavailability fail closed

[seonghobae]

Current state — 2026-09-13

The original fail-open source defect is repaired. Merged PR #897 changed the central required .github/workflows/security-scan.yml so Dependency Review support is accepted only when the comparison completes with transport success and HTTP 200; every non-200/malformed/empty/transport-failed result now fails the required workflow visibly and skips the pinned action only because authoritative dependency-diff evidence could not be established. Do not reopen the old 403/404 => supported=false => success behavior and do not substitute OSV/Trivy/Scorecard for Dependency Review.

One hard incident remains and one provenance question is now explicitly separated from it.

First, public non-fork ContextualWisdomLab consumers still receive HTTP 403 with curl_exit=0 from GET /repos/{repo}/dependency-graph/compare/{base}...{head}. The fail-closed workflow correctly blocks those PRs before actions/dependency-review-action can execute. GitHub's current public documentation says dependency graph/dependency review are available for public repositories; the observed 403 is therefore missing authoritative evidence, not a clean result and not a downstream application-source defect.

Second, TEPP #497 exposed a baseline-provenance ambiguity that must not be misclassified as a confirmed wrong-base defect. The live PR record reports direct base fix/central-hourly-admission-contract@794ba9e6dda9f043aa499920fdf609b81b075d7e, while required Security Scan run 34754213609 receives github.event.pull_request.base.sha=a243f18da4a4ca8a8d068c39922537f1f8ed6ad0 (TEPP protected main) and uses that SHA for OSV and Dependency Review. Current GitHub stacked-pull-request documentation, however, states that native stack members are evaluated for rules/checks as if they target the stack base/trunk and exposes pull_request.stack.base.ref/sha for that authority. Therefore main -> head can be intentional for a GitHub-native stack; the direct-base mismatch alone is not evidence of a defect.

The remaining owner obligation is to make this semantic choice explicit and verifiable. The current central workflow consumes ${{ github.event.pull_request.base.sha }} directly and does not record whether that value is a direct PR base, a native stack trunk, or a required-workflow event projection. The same workflow classifies dependency scope from /pulls/{number}/files, so the owner must prove that changed-scope classification and diff-scoped OSV/Dependency Review are using one coherent baseline model for both ordinary and stacked PRs.

Primary references:

• GitHub. (n.d.). Supply chain security. GitHub Docs. https://docs.github.com/en/code-security/concepts/supply-chain-security/supply-chain-security
• GitHub. (n.d.). Dependency graph. GitHub Docs. https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-graph
• GitHub. (n.d.). REST API endpoints for dependency review. GitHub Docs. https://docs.github.com/en/rest/dependency-graph/dependency-review
• GitHub. (2026). Stacked pull requests. GitHub Docs. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-stacked-pull-requests/about-stacked-pull-requests
• GitHub. (2026). REST API endpoints for stacked pull requests. GitHub Docs. https://docs.github.com/en/rest/pulls/stacks

Current incident boundary

• Central source remains fail closed unless Dependency Review evidence is transport-success + HTTP 200.
• The public-repository 403 availability/configuration incident remains unresolved; pinned Dependency Review does not run when evidence is unavailable.
• TEPP fix(opencode): bound publish fallback timeout #497 proves that direct PR base metadata and required-workflow pull_request.base.sha can differ. It does not, by itself, prove the required-workflow baseline is wrong because native stack semantics may intentionally use the stack trunk.
• Until native-stack membership and stack-base provenance are logged/verified, the fix(opencode): bound publish fallback timeout #497 OSV result cannot be used as evidence that the direct layer alone was scanned; nor should it be discarded merely because its base equals protected main.
• No leaf workflow shim, synthetic receipt, scanner substitution, no-op retrigger, or branch rewrite may compensate for the unresolved 403 or the provenance ambiguity.
• The currently exposed mutation surface does not provide a repository dependency-graph/security-setting write operation. Do not claim such a setting was changed without an authorized owner-plane read/write and post-write verification.

Required repair

Make the comparison-baseline authority explicit before any diff-scoped security scan:

1. bind repository, PR number, current head repository/ref/SHA, open state, and direct base repository/ref/SHA to an authenticated live PR record;
2. when the PR is a GitHub-native stack member, also bind stack identity plus stack.base.ref/sha and use the documented stack trunk as the cumulative rules/check baseline;
3. when it is not a native stack member, use the authenticated direct PR base;
4. emit typed provenance identifying which mode selected the baseline and the exact base/head actually scanned;
5. make changed-scope, OSV, Dependency Review, and any future diff-scoped scanner use the same semantic baseline, or prove by contract why a layer-scoped classifier and cumulative stack scan compose without a false skip;
6. fail closed on stale/wrong head, repository mismatch, malformed/unverifiable stack identity, or a baseline that cannot be reconciled to the authenticated PR/stack record.

Add deterministic RED fixtures for both an ordinary PR and a native stacked PR. The stacked fixture must cover a direct parent SHA different from the stack-trunk SHA and prove that the workflow selects the documented stack base deliberately rather than accidentally inheriting default main. Do not weaken the existing 403 fail-closed semantics while repairing provenance.

Acceptance criteria

• Immutable RED/GREEN contract forbids the former 403/404 success-skip behavior.
• Exact PR-head repository/SHA checkout is preserved.
• Ordinary PRs bind diff-scoped scanners to the authenticated direct PR base/head tuple.
• Native stacked PRs bind rules/check scans to authenticated stack identity and stack.base.ref/sha, with explicit provenance telemetry.
• changed-scope, OSV and Dependency Review share one documented baseline model or have an executable proof that their different scopes compose safely without a false negative.
• Only transport-success + HTTP 200 reaches the immutable pinned Dependency Review action.
• 403/404/malformed/empty status, transport failure, timeout, truncated response and unexpected status fail closed without leaking response bodies.
• Least privilege and independent OSV/Trivy/Scorecard/CodeQL/SAST/secret surfaces are preserved.
• Determine and repair the remaining GitHub/dependency-review availability or account/repository configuration cause through an authorized owner surface; do not guess the 403 root cause from status alone.
• After the availability repair, perform fresh unchanged-head ordinary and stacked public non-fork canaries where the logged baseline authority is explicit, the exact Dependency Review comparison returns HTTP 200, and the pinned actions/dependency-review-action executes to a terminal authoritative result.
• Re-read the then-current central workflow and downstream exact-head runs to prove no fail-open regression, accidental baseline selection, or substitute-scanner promotion occurred.

Keep this issue open for the owner repair. Existing historical PRs #799/#821/#897/#1050 remain evidence/history, not permission to weaken the current hard gate.

[seonghobae]

Exact-head implementation update, not closure: existing PR #799 has progressed test-first to exact head dfa28786a6d57628b26ddbf1f466cbf9084e725d. Immutable RED 2d1603f1c307be83a12d8b2f847d6a91b1ce97b3 exposed the forbidden 403/404 supported=false skip. GREEN 7c0b6f9ffb7bc1c6364df3101879191648302210 removes that path, accepts only HTTP 200, discards the untrusted API body, and fails closed otherwise; subsequent docs/changelog/contract-correction commits end at the current SHA.

Current-head evidence is materially stronger than the original downstream failure: Security Scan run 31144419104 dependency-review job 92760819070 executed both the support probe and the pinned dependency-review action successfully, and the current SHA also has successful Python Security, CodeQL, Semgrep, Secret Scan, OSV, Scorecard, SBOM, and dedicated exact-head quality runs. No current-head unresolved review thread is present.

Keep #810 open. PR #799 is Draft again because current-head CodeRabbit review is rate-limited/pending, the prior OpenCode review was anchored to predecessor head 323c07b794d11f82c04db91544bc3a3f5cf5ad5c and dismissed, and no qualifying independent non-author approval exists. After exact-current-head automated review and independent approval, integrate without bypass; then require a downstream EgressWeave exact-head canary before closing #810/#76. Do not treat the pre-repair EgressWeave Security Scan greens as evidence under the repaired contract.