security: make central dependency-review unavailability fail closed

Fresh downstream canary — 2026-10-01

PolicyWeave protected root PR #1 remains unchanged at base 52f4fd6bb68f870d0519cf11dd471573a2f197c0, head 60fd7fb5c3177984a993102742bb16e36a909e2d. Required Security run 36241747990 was rerun on 2026-10-01. New dependency-review job 110221939186 again logged DEPENDENCY_REVIEW_SUPPORT ... visibility=public ... http_status=403 curl_exit=0, skipped the pinned action, and failed closed. Scorecard, Trivy, and OSV passed on the same rerun; they remain non-substitutes.

This repeat rules out a one-off runner failure for that exact tuple but does not prove which owner-plane entitlement or repository setting causes the 403. The available mutation surface still exposes no authorized dependency-graph/security-setting write. Keep the availability acceptance criterion open and preserve fail-closed behavior until an owner-plane read/write plus post-write exact-head canary produces HTTP 200 and executes the pinned Dependency Review action.

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:

bind repository, PR number, current head repository/ref/SHA, open state, and direct base repository/ref/SHA to an authenticated live PR record;
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;
when it is not a native stack member, use the authenticated direct PR base;
emit typed provenance identifying which mode selected the baseline and the exact base/head actually scanned;
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;
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

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.

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.

fix(security): validate dependency-review identity before compare

fix(security): record visibility on dependency-review fail-closed

fix(security): fail closed on unavailable dependency review

fix(security): validate dependency-review identity before compare

fix(security): record visibility on dependency-review fail-closed

fix(security): reject dot path components before dependency-review co…

fix(security): record visibility on dependency-review fail-closed

fix(security): reject dot path components before dependency-review co…

Fresh public non-fork canary evidence from 2026-09-26: ContextualWisdomLab/learning-interoperability-contracts PR #1 at unchanged exact head 765928f275cdaca199196e112c987c36b7d178a9 and base ba2948de245448eab739329f1131a36b4e59a54d reached terminal Security Scan 35463352243. Exact dependency-review job 105989484914 checked out the current head, then logged DEPENDENCY_REVIEW_SUPPORT ... http_status=403 curl_exit=0 and failed closed before the pinned action. Scorecard, OSV and Trivy succeeded. This is another ordinary public-repository 403 canary; no leaf shim, scanner substitution, no-op retry or gate weakening was applied.

Fresh read-only comparison narrows the remaining 403 incident; it does not establish a root cause or authorize a fallback scanner.

Same authenticated gh api session and X-GitHub-Api-Version: 2026-03-10: ContextualWisdomLab/CalendarWeave ordinary commit compare d972ccae6225716bdff7210a1fed808c01d32689...cbffaf7c7110be6f6bba0ece5dbea9f12fc21048 succeeds, while the dependency-graph compare for that exact pair returns HTTP 403. The dependency-graph compare also returns 403 for two CalendarWeave feature-branch pairs whose branches contain Cargo manifests.
With the same authentication/version, ContextualWisdomLab/naruon ordinary compare and dependency-graph compare for ca035343ef01fb8b6fc48dec7fe4077532cdaa9b...2045f76d5518dd9e62a5c1b8f1f564f0ef86eda5 both succeed. Both repositories are public and non-fork, and this account has admin permission on both.
CalendarWeave's SBOM endpoint returns 404 and its GraphQL dependencyGraphManifests.totalCount is 0; Naruon's SBOM returns SPDX 2.3 and its manifest count is 20. GET /vulnerability-alerts succeeds for both. These observations are consistent with a repository-specific dependency-graph availability/configuration difference, but do not prove which setting or GitHub behavior causes it.

The required workflow should continue to fail closed. An authorized owner should inspect CalendarWeave's Dependency Graph state in repository security settings and compare it with a working public repository, then obtain a fresh exact-head HTTP 200 canary before treating Dependency Review as available. No response body or credential is included here.

PolicyWeave canary update — 2026-09-30

Root PR PolicyWeave#1 remains Draft at 60fd7fb5c3177984a993102742bb16e36a909e2d; its Security workflow evidence still records the Dependency Review HTTP 403 root cause already tracked here. Stacked Draft PolicyWeave#25 advanced by fast-forward to 5f4e0cd203f6fd28a885c02cca4b22073aecab4f (tree 5f7840734a6b790fd6aaf283eed7c38b5ac7b4a8) without dependency changes. It remains blocked pending owner-side exact-head security evidence; no leaf bypass or synthetic success is claimed.

Fresh downstream canary evidence (2026-09-30): ContextualWisdomLab/learning-management-platform#1 exact head 562d620426b791b3dbf054a18179401346e6e630, base 1b89a16bbbd6c4b7c6ee4e8b81e2c8c651d1ce2c, Security Scan run 33531424637, job 99935258650.

The exact-head checkout and SHA verification succeeded. The central Check dependency review support step then recorded:

DEPENDENCY_REVIEW_SUPPORT repository=ContextualWisdomLab/learning-management-platform visibility=public base_sha=1b89a16bbbd6c4b7c6ee4e8b81e2c8c651d1ce2c head_sha=562d620426b791b3dbf054a18179401346e6e630 http_status=403 curl_exit=0

Scorecard, Trivy, OSV, SAST, and repository Quality all succeeded on the same head; the workflow correctly failed closed only because authoritative dependency-review evidence was unavailable. This is another public non-fork consumer confirming the unresolved owner-plane 403 described here. No leaf workflow bypass, scanner substitution, rerun, or merge relaxation was applied. PR #1 remains Draft/open with its valid delta preserved.

Fresh downstream specimens (2026-09-30 UTC audit) preserve the canonical fail-closed boundary:

ContextualWisdomLab/Orgmetra#448 exact 8f3cc0d7fd217cbc7f3b70431286110bbce71f47, base eb9757f8649aaad026a9865508d9aad50c1a7a4f: Security run 36275869704, dependency-review job 108574975788 logged http_status=403 curl_exit=0; the pinned Dependency Review action was skipped and the job failed.
ContextualWisdomLab/Orgmetra#100 exact d883a1d58587df933a973665d96c109fb4f3b749, same base: Security run 36289618036, dependency-review job 108765077421 reproduced the same authenticated exact-base/head HTTP 403 and failed closed.

Foundation/SAST or other scanners are not substitutes for this missing comparison evidence. Both PR bodies now identify this owner incident; no leaf shim, synthetic success, rerun, or gate weakening was applied.

Fresh exact-head canary from ContextualWisdomLab/learning-interoperability-contracts: Security run 36779376436, dependency-review job 110105353058, checked out exact head 30189d681298339a018eb14414b4e4e81d0a996f and base ba2948de245448eab739329f1131a36b4e59a54d, then GET /repos/ContextualWisdomLab/learning-interoperability-contracts/dependency-graph/compare/{base}...{head} returned HTTP 403 with curl exit 0. Scorecard, OSV, and Trivy succeeded. This reproduces the central support/authorization defect; the leaf remains fail-closed and was not rerun or bypassed.

2026-10-01 unchanged-source canary evidence

Two current Orgmetra exact heads independently reproduce the same owner-side availability incident while their product-owned validation remains GREEN:

Orgmetra Fix central scheduler review job reruns #100 exact 301f843c01f301088234c27f758c2a074cfa9aed: Security run 36796830339, dependency-review job 110162113278. Exact comparison eb9757f8649aaad026a9865508d9aad50c1a7a4f...301f843c01f301088234c27f758c2a074cfa9aed returned HTTP 403, curl_exit=0, then failed closed. Foundation CI 36796830293 and SAST 36796830323 succeeded.
Orgmetra fix(opencode): keep oversized reviews packet-first #448 exact 6a06062e9d4f6e07bf4780a60384f264f7983353: Security run 36796513896, dependency-review job 110161138626. Checkout telemetry proves expected SHA equals actual SHA. Exact comparison eb9757f8649aaad026a9865508d9aad50c1a7a4f...6a06062e9d4f6e07bf4780a60384f264f7983353 returned HTTP 403, curl_exit=0, then failed closed. Foundation CI 36796513822 and SAST 36796513856 succeeded.

Both PRs remain Draft with zero qualifying approvals and zero unresolved review threads; their CodeQL workflows were skipped and are not acceptance evidence. No leaf shim or fail-open change was introduced. This evidence strengthens the existing conclusion that the unresolved 403 is not caused by either product delta and still requires the authorized owner/configuration surface described in this issue.

Fresh public non-fork consumer canary on 2026-10-01 confirms the unresolved availability/configuration boundary without weakening the fail-closed source repair.

Consumer: ContextualWisdomLab/ELUNVERA PR Add Palette journal for profile repo #1
Exact base: 1975f50ebe3da751097e015bdfa909ce80fc6ba2
Exact head: b8de51c37bf044d350b3f84bfb78069792a05ac7
Security Scan run: https://github.com/ContextualWisdomLab/ELUNVERA/actions/runs/36796931676
dependency-review job: 110162426119
exact checkout identity: expected/actual both b8de51c37bf044d350b3f84bfb78069792a05ac7
support result: visibility=public http_status=403 curl_exit=0
outcome: support step failed closed; immutable-pinned Dependency Review action skipped
independent surfaces: Scorecard, OSV, and Trivy all succeeded

The consumer remains Draft. Product CI, document-contracts, and SAST are GREEN; CodeQL is Draft-skipped; Security remains non-passing. No leaf workflow shim, gate weakening, scanner substitution, or no-op retrigger was introduced. This is additional canary evidence for the still-open owner-plane acceptance items in this issue, not a new root-cause claim from the 403 alone.

CalendarWeave unchanged-head canary — 2026-10-01

ContextualWisdomLab/CalendarWeave#1@5c85765adb3e3d9514e387921103d2fda7944c18 remains a fresh public non-fork availability specimen:

Security Scan run 36686206813: terminal failure after Dependency Review support/comparison returned HTTP 403.
Tests 36686207005 and SAST 36686206972: success at the same exact head.
CodeQL PR 36686206923: skipped.

This confirms the central fail-closed behavior is still active, but it does not satisfy the outstanding availability acceptance criterion and does not prove a dependency CVE. The consumer PR remains Draft/open; no leaf shim, no-op commit, scanner substitution, bypass, or predecessor evidence was used.

Fresh downstream canary — saju-caldav (2026-10-01)

ContextualWisdomLab/saju-caldav#56 exact head 8866ecca2816e078dfdfe85dba9437427b59c5c1, protected base main@fa72a2c8b988abeb7efacc886cbb3fd8849314af, Security Scan run 36818775605:

support probe: visibility=public, http_status=403, curl_exit=0;
pinned Dependency Review action was skipped and the required job failed closed;
exact-head Trivy, OSV and Scorecard all completed successfully;
the same successor upgraded PyJWT 2.13.0 → 2.15.1 and urllib3 2.7.0 → 2.8.0 after the preceding Trivy RED, and the fresh Trivy/OSV scans are clean.

This independently reproduces the unresolved owner-plane availability/configuration incident after leaf source vulnerabilities were repaired. No scanner substitution, workflow weakening, synthetic success, or consumer workaround was applied. Keep the acceptance requirement for an authorized owner-plane repair plus an unchanged-head HTTP 200 canary open.

Fresh Orgmetra Workforce Validation canary — 2026-10-01

ContextualWisdomLab/Orgmetra#235 exact head 630e2c0a771f6dff0748307ea22b72c0ef9d0f51, protected base develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f, Security Scan 36824994973, dependency-review job 110248616752:

exact comparison eb9757f8649aaad026a9865508d9aad50c1a7a4f...630e2c0a771f6dff0748307ea22b72c0ef9d0f51 returned http_status=403 curl_exit=0;
the workflow failed closed and did not promote Scorecard, OSV, or Trivy as substitutes;
those three independent surfaces succeeded, as did exact-head Foundation CI 36824994817 and SAST 36824994869 after the product-owned checkout-mutation and setuptools-license defects were repaired.

This is an additional public non-fork unchanged-source availability specimen, not proof of a leaf dependency vulnerability or permission to weaken the gate. The PR is Ready only for review admission and remains merge HOLD; no leaf shim, scanner substitution, Draft/Ready toggle, no-op commit, manual rerun, bypass, or predecessor-status transfer was used.

ELUNVERA exact-head canary update (2026-10-02 KST)

Repository/PR: First slice: relationship-activation queue home ELUNVERA#1 (Draft)
Exact base: 1975f50ebe3da751097e015bdfa909ce80fc6ba2
Exact head: a16229f5398af476a32f742f2cf29b9045f7438f
Security run: https://github.com/ContextualWisdomLab/ELUNVERA/actions/runs/36889125853
dependency-review job: 110460017237
Exact RCA: DEPENDENCY_REVIEW_SUPPORT ... http_status=403 curl_exit=0; the action was skipped and the workflow failed closed.
Unaffected scanners on the same head: Trivy, Scorecard, and OSV succeeded.
Product CI, document contracts, and Semgrep succeeded on this exact head. CodeQL remained Draft-skipped.

The earlier failed Security run was explicitly rerun and reproduced the same 403; subsequent exact heads, including this final repair head, reproduced it again. This is not stale-run evidence. No leaf-repository shim, substitute-scanner promotion, or gate weakening was added.

Fresh repository-specific availability canary routed from #2537 comment 5937968326 to the canonical Dependency Review owner.

Consumer: ContextualWisdomLab/LineageWeave#1142
Exact head: 921f2df9629b8fbdef707b04469b45b2a1ed6299
Security Scan: 36906546094
dependency-review job: 110518483146
Exact checkout identity: passed
support/comparison result: HTTP 403; fail-closed
same exact head: OSV and Trivy succeeded
control: a Naruon consumer at the same central workflow generation reached the comparison endpoint with HTTP 200

This narrows the incident to repository-specific dependency-graph/API authorization or configuration rather than fleet scanner availability or a LineageWeave source vulnerability. It does not identify which owner-plane setting is wrong. Preserve fail-closed behavior; require an authorized owner-plane read/write and unchanged-head HTTP 200 canary before acceptance. No leaf shim, no-op wake, manual rerun, or substitute-scanner promotion was used.

LineageWeave repository-specific Dependency Review canary

ContextualWisdomLab/LineageWeave#1129 exact base 83eba56149eb802cd63642c507c324c9976ec78e, exact head 950a6b78c9b9d78e1aa7d520e9999f9dfa544a03, Security run 36947092235, dependency-review job 110651644056:

exact checkout identity passed;
support/comparison returned visibility=public http_status=403 curl_exit=0;
immutable Dependency Review action was skipped and the required job failed closed;
exact-head OSV, Trivy, and Scorecard succeeded.

Together with the prior LineageWeave#1142 canary and a Naruon HTTP-200 control at the same workflow generation, this remains a repository-specific dependency-graph/API authorization or configuration defect, not a leaf dependency vulnerability. The consumer stays Ready only for review admission and merge HOLD. No leaf workflow shim, scanner substitution, no-op event, manual rerun, or gate weakening was introduced.

Canonical successor linkage — 2026-10-03

The complete current Dependency Review source/test/ADR/doctoring/CHANGELOG/Gap delta from #1725 is now preserved in concurrent owner successor #2565. Published ordinary two-parent merge 650bc6e35409d52d24fec890c2ab74063794e9b8 joins prior #2565 cd2c3f9748e6bc50efd8bdfee9a385a74ec6e3ba with #1725 229027280e8bce6cc4f13e722b2b0c280a1ac17d; current successor head f0f7ed988fba5d94eda6513f35d171f23c4bd9a5 adds an executable ancestry receipt and corrects the canonical evidence.

This is Proposed-only owner evidence. #2565 remains Draft and unmerged: CodeQL is Draft-skipped; Security, SAST, Metadata, Trusted uv, and Cloudflare fail before executable steps because the CWL CI isolated group/capacity and canary prerequisite is absent; qualifying approvals are zero. Therefore there is still no protected-main immutable consumer SHA, and #1725 must not be retired.

This succession repairs neither the remaining repository-specific HTTP 403 availability/configuration defect nor the ordinary/native-stack baseline-provenance acceptance items in this issue. Orgmetra #95 e78e79fb846ec5af7f6fe0c09cedd71357373312 and #448 6a06062e9d4f6e07bf4780a60384f264f7983353 remain fail-closed at Dependency Review HTTP 403. Required order remains #2565 ordinary protected integration → immutable protected SHA → consumer pin/adoption where required → unchanged-head HTTP 200 plus terminal Dependency Review result. No leaf shim, mutable PR-head pin, blind rerun, scanner substitution, predecessor closure, or evidence transfer is authorized.

Navigation Menu

Repository navigation

security: make central dependency-review unavailability fail closed #810

Fresh downstream canary — 2026-10-01

Current state — 2026-09-13

Current incident boundary

Required repair

Acceptance criteria

234 remaining items

2026-10-01 unchanged-source canary evidence

CalendarWeave unchanged-head canary — 2026-10-01

Fresh downstream canary — saju-caldav (2026-10-01)

Fresh Orgmetra Workforce Validation canary — 2026-10-01

LineageWeave repository-specific Dependency Review canary

Canonical successor linkage — 2026-10-03

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

security: make central dependency-review unavailability fail closed #810

Description

Fresh downstream canary — 2026-10-01

Current state — 2026-09-13

Current incident boundary

Required repair

Acceptance criteria

Activity

seonghobae commented on Aug 7, 2026

234 remaining items

seonghobae commented on Sep 26, 2026

seonghobae commented on Sep 26, 2026

seonghobae commented on Sep 30, 2026

seonghobae commented on Sep 30, 2026

seonghobae commented on Sep 30, 2026

seonghobae commented on Sep 30, 2026

seonghobae commented on Oct 1, 2026

2026-10-01 unchanged-source canary evidence

seonghobae commented on Oct 1, 2026

seonghobae commented on Oct 1, 2026

CalendarWeave unchanged-head canary — 2026-10-01

seonghobae commented on Oct 1, 2026

Fresh downstream canary — saju-caldav (2026-10-01)

seonghobae commented on Oct 1, 2026

Fresh Orgmetra Workforce Validation canary — 2026-10-01

seonghobae commented on Oct 1, 2026

seonghobae commented on Oct 1, 2026

seonghobae commented on Oct 2, 2026

LineageWeave repository-specific Dependency Review canary

seonghobae commented on Oct 3, 2026

Canonical successor linkage — 2026-10-03

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions