security: make central dependency-review unavailability fail closed

[seonghobae]

Current state — 2026-09-01

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 exact BASE_SHA...HEAD_SHA 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.

The issue remains open for a separate current availability/operations incident: public, non-fork ContextualWisdomLab consumers (including repeated Orgmetra canaries) still receive HTTP 403 with curl_exit=0 from GET /repos/{repo}/dependency-graph/compare/{base}...{head}. The fail-closed workflow therefore correctly blocks those PRs before actions/dependency-review-action can execute.

GitHub's current public documentation states that dependency graph and dependency review are enabled by default for public repositories and cannot be disabled, and the dependency-review REST comparison can be used without authentication for public resources; documented 403 semantics do not describe a normal public non-fork result. Treat the current 403 as missing authoritative evidence, not as a clean dependency review and not as a downstream application-source defect.

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

Current incident boundary

• Central source behavior on protected main: fail closed unless the exact dependency comparison returns HTTP 200 with curl exit 0.
• Repeated public Orgmetra canaries: exact checkout succeeds; comparison returns HTTP 403; pinned Dependency Review step does not execute; Security Scan is correctly FAILURE; sibling OSV/Trivy/Scorecard results may be GREEN but are not semantic substitutes.
• No Orgmetra-local workflow shim or branch change can convert a GitHub 403 into authoritative dependency-review evidence.
• The currently exposed GitHub mutation surface does not provide a repository dependency-graph/security-setting write operation. Do not claim such a setting was changed, and do not weaken the central gate to compensate.

Acceptance criteria

• Immutable RED/GREEN contract forbids the former 403/404 success-skip behavior.
• Exact PR-head repository/SHA checkout and exact base/head comparison binding are preserved.
• 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 that repair, perform a fresh unchanged-head public non-fork canary (Orgmetra is acceptable) where the exact comparison returns HTTP 200 and the pinned actions/dependency-review-action actually executes to a terminal authoritative result.
• Re-read the then-current central workflow and downstream exact-head run to prove no fail-open regression or substitute-scanner promotion occurred.

Keep this issue open for the remaining availability incident; do not create another central fail-closed writer unless protected main regresses. 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.