Repository navigation
security: make central dependency-review unavailability fail closed #810
Description
Activity
Exact-head implementation update, not closure: existing PR #799 has progressed test-first to exact head
dfa28786a6d57628b26ddbf1f466cbf9084e725d. Immutable RED2d1603f1c307be83a12d8b2f847d6a91b1ce97b3exposed the forbidden 403/404supported=falseskip. GREEN7c0b6f9ffb7bc1c6364df3101879191648302210removes 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
31144419104dependency-review job92760819070executed 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
323c07b794d11f82c04db91544bc3a3f5cf5ad5cand 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.- added a commit that references this issue
on Aug 17, 2026 - added 8 commits that reference this issue
on Aug 19, 2026 234 remaining items
Fresh public non-fork canary evidence from 2026-09-26:
ContextualWisdomLab/learning-interoperability-contractsPR #1 at unchanged exact head765928f275cdaca199196e112c987c36b7d178a9and baseba2948de245448eab739329f1131a36b4e59a54dreached terminal Security Scan 35463352243. Exact dependency-review job 105989484914 checked out the current head, then loggedDEPENDENCY_REVIEW_SUPPORT ... http_status=403 curl_exit=0and 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 apisession andX-GitHub-Api-Version: 2026-03-10:ContextualWisdomLab/CalendarWeaveordinary commit compared972ccae6225716bdff7210a1fed808c01d32689...cbffaf7c7110be6f6bba0ece5dbea9f12fc21048succeeds, 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/naruonordinary compare and dependency-graph compare forca035343ef01fb8b6fc48dec7fe4077532cdaa9b...2045f76d5518dd9e62a5c1b8f1f564f0ef86eda5both 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.totalCountis 0; Naruon's SBOM returns SPDX 2.3 and its manifest count is 20.GET /vulnerability-alertssucceeds 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.
- Same authenticated
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 to5f4e0cd203f6fd28a885c02cca4b22073aecab4f(tree5f7840734a6b790fd6aaf283eed7c38b5ac7b4a8) 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#1exact head562d620426b791b3dbf054a18179401346e6e630, base1b89a16bbbd6c4b7c6ee4e8b81e2c8c651d1ce2c, Security Scan run 33531424637, job99935258650.The exact-head checkout and SHA verification succeeded. The central
Check dependency review supportstep then recorded:DEPENDENCY_REVIEW_SUPPORT repository=ContextualWisdomLab/learning-management-platform visibility=public base_sha=1b89a16bbbd6c4b7c6ee4e8b81e2c8c651d1ce2c head_sha=562d620426b791b3dbf054a18179401346e6e630 http_status=403 curl_exit=0Scorecard, 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#448exact8f3cc0d7fd217cbc7f3b70431286110bbce71f47, baseeb9757f8649aaad026a9865508d9aad50c1a7a4f: Security run36275869704, dependency-review job108574975788loggedhttp_status=403 curl_exit=0; the pinned Dependency Review action was skipped and the job failed.ContextualWisdomLab/Orgmetra#100exactd883a1d58587df933a973665d96c109fb4f3b749, same base: Security run36289618036, dependency-review job108765077421reproduced 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 job110105353058, checked out exact head30189d681298339a018eb14414b4e4e81d0a996fand baseba2948de245448eab739329f1131a36b4e59a54d, thenGET /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 comparisoneb9757f8649aaad026a9865508d9aad50c1a7a4f...301f843c01f301088234c27f758c2a074cfa9aedreturnedHTTP 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 comparisoneb9757f8649aaad026a9865508d9aad50c1a7a4f...6a06062e9d4f6e07bf4780a60384f264f7983353returnedHTTP 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.
- Orgmetra Fix central scheduler review job reruns #100 exact
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/ELUNVERAPR 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.
- Consumer:
CalendarWeave unchanged-head canary — 2026-10-01
ContextualWisdomLab/CalendarWeave#1@5c85765adb3e3d9514e387921103d2fda7944c18remains a fresh public non-fork availability specimen:- Security Scan run
36686206813: terminal failure after Dependency Review support/comparison returned HTTP 403. - Tests
36686207005and SAST36686206972: 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.
- Security Scan run
Fresh downstream canary — saju-caldav (2026-10-01)
ContextualWisdomLab/saju-caldav#56exact head8866ecca2816e078dfdfe85dba9437427b59c5c1, protected basemain@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.
- support probe:
Fresh Orgmetra Workforce Validation canary — 2026-10-01
ContextualWisdomLab/Orgmetra#235exact head630e2c0a771f6dff0748307ea22b72c0ef9d0f51, protected basedevelop@eb9757f8649aaad026a9865508d9aad50c1a7a4f, Security Scan 36824994973, dependency-review job110248616752:- exact comparison
eb9757f8649aaad026a9865508d9aad50c1a7a4f...630e2c0a771f6dff0748307ea22b72c0ef9d0f51returnedhttp_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
36824994817and SAST36824994869after 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.
- exact comparison
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.
- Consumer:
LineageWeave repository-specific Dependency Review canary
ContextualWisdomLab/LineageWeave#1129exact base83eba56149eb802cd63642c507c324c9976ec78e, exact head950a6b78c9b9d78e1aa7d520e9999f9dfa544a03, Security run36947092235, dependency-review job110651644056:- 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
650bc6e35409d52d24fec890c2ab74063794e9b8joins prior #2565cd2c3f9748e6bc50efd8bdfee9a385a74ec6e3bawith #1725229027280e8bce6cc4f13e722b2b0c280a1ac17d; current successor headf0f7ed988fba5d94eda6513f35d171f23c4bd9a5adds 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 isolatedgroup/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
e78e79fb846ec5af7f6fe0c09cedd71357373312and #4486a06062e9d4f6e07bf4780a60384f264f7983353remain 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.
Fresh downstream canary — 2026-10-01
PolicyWeave protected root PR #1 remains unchanged at base
52f4fd6bb68f870d0519cf11dd471573a2f197c0, head60fd7fb5c3177984a993102742bb16e36a909e2d. Required Security run 36241747990 was rerun on 2026-10-01. New dependency-review job110221939186again loggedDEPENDENCY_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.ymlso Dependency Review support is accepted only when the comparison completes with transport success and HTTP200; 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 old403/404 => supported=false => successbehavior 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
403withcurl_exit=0fromGET /repos/{repo}/dependency-graph/compare/{base}...{head}. The fail-closed workflow correctly blocks those PRs beforeactions/dependency-review-actioncan 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 run34754213609receivesgithub.event.pull_request.base.sha=a243f18da4a4ca8a8d068c39922537f1f8ed6ad0(TEPP protectedmain) 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 exposespull_request.stack.base.ref/shafor that authority. Thereforemain -> headcan 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:
Current incident boundary
200.pull_request.base.shacan differ. It does not, by itself, prove the required-workflow baseline is wrong because native stack semantics may intentionally use the stack trunk.main.Required repair
Make the comparison-baseline authority explicit before any diff-scoped security scan:
stack.base.ref/shaand use the documented stack trunk as the cumulative rules/check baseline;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;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
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.200reaches the immutable pinned Dependency Review action.200, and the pinnedactions/dependency-review-actionexecutes to a terminal authoritative result.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.