security: fail closed when dependency review is unavailable

[seonghobae]

Buyer-visible supply-chain gate gap

EgressWeave exact-head evidence proves a fail-open dependency-review path: the dependency comparison can be unavailable while the immutable-pinned actions/dependency-review-action step is skipped and the aggregate Security Scan still appears green. For this public-repository canary, unavailable or indeterminate dependency-diff evidence is non-passing, not an inferred clean/not-applicable result.

This is an assurance/control-plane defect, not evidence that a particular EgressWeave PR introduced a vulnerable dependency. OSV, Trivy, Scorecard, CodeQL/GHAS, Semgrep, Secret Scan, Dependabot and model reviewers remain separate controls and are not semantic substitutes for Dependency Review.

Current read-only central owner / exact identity

The organization-owned repair remains ContextualWisdomLab/.github#897 — fix(security): fail closed on unavailable dependency review.

Fresh read-only state:

• protected central main: 6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba;
• #897 exact current head: 714a19818ff35cce246b6b59b9d3969783037cb0;
• #897 is open / Ready / unmerged;
• current formal reviews on #897: none;
• exact-head checks are mixed rather than uniformly passing: deterministic checks including coverage-evidence and opencode-review completed successfully, while current GHAS/code-scanning evidence includes neutral/skipped results. Those states are not promoted to passing under EgressWeave evidence policy.

Historical #897 heads, including 71947d..., 8fc17de..., and 59505c1..., remain RCA/TDD/check history only. Their checks or review state do not transfer to 714a198....

Root cause and selected central remedy

The original security gate modeled a hard evidence boundary as an optional capability probe. An unavailable/non-success comparison could therefore set support false, skip the pinned action, and still leave a false-green wrapper.

The accepted repair semantics remain:

• require the support probe's transport operation itself to succeed and require exact HTTP 200 before the pinned Dependency Review action may run;
• fail closed on non-200, malformed/empty status, transport/TLS/timeout/partial-transfer failure, or any indeterminate result;
• discard the untrusted response body and use finite connection/total timeouts;
• bind source checkout and comparison to explicit immutable PR/base/head identities;
• keep read-only/least-privilege permissions and immutable third-party action pins; and
• preserve a negative control where a probe reports 200 but the transport command exits nonzero and therefore must still fail closed.

No EgressWeave-local workflow fork, substitute scanner, extra credential, OIDC/model authority, publisher, branch mutation, release authority, or weakened gate is an acceptable remedy.

EgressWeave acceptance impact

Current EgressWeave PRs whose Security Scan wrapper is green while the actual pinned Dependency review step is skipped remain non-passing for this gate. Do not merge them on wrapper-green evidence and do not churn clean heads merely to recreate the same skipped result.

After #897, or a freshly verified successor preserving the same semantics, reaches protected central main, every otherwise accepted unchanged EgressWeave candidate must receive a fresh Security Scan bound to its exact current head and live-base context. Acceptance requires the real immutable-pinned Dependency review action itself to execute and succeed; predecessor, wrapper-only, support-only, queued, skipped, cancelled, neutral, stale, or synthetic evidence does not transfer.

Acceptance criteria

• Preserve immutable RED evidence for the original fail-open unavailable/non-success behavior.
• Define fail-closed support semantics requiring successful transport plus exact HTTP 200.
• Preserve the nonzero-transport-with-200 negative control.
• Bound probe resources and avoid response-body or credential disclosure.
• Preserve exact source/base/head identity, read-only permissions, and immutable action pins in the central repair lineage.
• Complete deterministic/security/current-source review on exact central head 714a19818ff35cce246b6b59b9d3969783037cb0 without treating neutral/skipped/failed/stale evidence as passing.
• Satisfy every live central ruleset/review/approval requirement actually imposed and integrate the accepted repair into protected central main without bypass.
• After protected-central integration, rerun unchanged EgressWeave accepted candidates and require the real pinned Dependency Review action to execute and succeed on each exact accepted tree.
• Revalidate every other required EgressWeave workflow, finding, review/thread state, exact head/live base, and live rule immediately before each merge.
• Close only after protected-central repair plus at least one protected EgressWeave consumer path proves the repaired fail-closed behavior end to end.

Required semantics

403, 404, malformed/empty status, nonzero transport exit even with stdout 200, timeout, partial transfer, TLS failure, or unexpected probe state is unavailable security evidence and must fail closed. Do not infer not-applicable from an unavailable support probe. Keep Dependency Review evidence separate from all other scanners and reviewers, preserve complete pagination where APIs enumerate state, and retain stale-head refusal, fork/read-only safety, least privilege, and immutable source identity.

Trust boundary / non-goals

The repair belongs to the organization-owned read-only security gate. EgressWeave must not create a competing central workflow, publisher, model-modified publication path, extra write authority, release/tag/package path, or local fail-open workaround. No dependency/package-version change is implied by this issue.

Primary references (APA 7th)

GitHub. (n.d.). Dependency review. GitHub Docs. Retrieved August 7, 2026.

GitHub. (n.d.). REST API endpoints for dependency review. GitHub Docs. Retrieved August 7, 2026.

GitHub. (n.d.). Customizing your dependency review action configuration. GitHub Docs. Retrieved August 7, 2026.

[seonghobae]

Additional exact-state clarification: ContextualWisdomLab/EgressWeave is currently public and is not being treated as a private-repository entitlement case. GitHub's current documentation says dependency review and the dependency-review action are available for all public GitHub.com repositories, and the dependency-review REST endpoint can be used without authentication for public resources when only public data is requested. Therefore the observed HTTP 403 in run 31108241013 is unexpected for this repository and must be diagnosed rather than normalized as an ordinary successful skip. Candidate causes to verify include repository dependency-graph/security configuration, workflow-token/API behavior, or a GitHub-side restriction/error; do not guess among them. The acceptance contract remains: exact dependency-sensitive changes fail closed if the API is unavailable, and an exact no-dependency-change comparison may be recorded only as explicit not-applicable, never as dependency-review passed.

Primary sources:

• GitHub, Dependency review: https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-review
• GitHub, REST API endpoints for dependency review: https://docs.github.com/en/enterprise-cloud@latest/rest/dependency-graph/dependency-review

[seonghobae]

Central repair evidence advanced on ContextualWisdomLab/.github#799. Immutable executed RED head 2d1603f1c307be83a12d8b2f847d6a91b1ce97b3 failed exact-head quality run 31143997735 on the former 403/404 supported=false skip contract. The repair removes that path, accepts only HTTP 200, discards the API response body, and fails closed otherwise. Exact current central head dfa28786a6d57628b26ddbf1f466cbf9084e725d now passes the dedicated exact-head contract (31144295105), Python Security (31144295071), Security Scan (31144295076), CodeQL (31144295075), Semgrep (31144295080), Secret Scan (31144295094), OSV (31144295363), Scorecard (31144295077), and SBOM (31144295065). In Security Scan job 92760467413, checkout was exact head dfa28786..., the repaired support probe succeeded, and immutable-pinned actions/dependency-review-action@a1d282b... actually executed successfully rather than being skipped. The central PR is Ready but remains unmerged pending qualifying independent non-author approval. EgressWeave canary acceptance remains intentionally open until that exact central repair is integrated and an EgressWeave exact-head Security Scan demonstrates the hard action executes under the integrated workflow.

[seonghobae]

Central repair evidence update (exact-head bound, not closure): ContextualWisdomLab/.github#799 is now at exact head dfa28786a6d57628b26ddbf1f466cbf9084e725d. On that exact head, Security Scan run 31144419104 completed successfully and dependency-review job 92760819070 executed both Check dependency review support and the pinned Dependency review action successfully; the earlier supported=false green-skip path is removed from the candidate according to the PR's permanent contract and TDD history. The candidate's exact-head Python Security, Security Scan, CodeQL, Semgrep, Secret Scan, OSV, Scorecard, SBOM, and dedicated exact-head quality workflow are also associated with this SHA and concluded success.

This does not close #76 yet. I returned central #799 to Draft because current-head CodeRabbit review is rate-limited/pending, there is no qualifying independent non-author approval, and the repair has not been integrated into central protected main. After central integration, rerun an EgressWeave exact-head Security Scan canary and accept #76 only if the dependency-review support probe and hard action both execute cleanly on the immutable downstream head. Do not reuse the pre-repair green Security Scan runs on existing EgressWeave PRs as supply-chain acceptance evidence.

[seonghobae]

Live control-plane refresh (2026-08-07): central ContextualWisdomLab/.github protected main is now exact 1131b1bbafb24e455fc8619cdf316813e8721861. Prerequisite #813 remains open at exact head 1779da411ef2f4c2f20e05a3035f0ff1c43600e8, is not draft, and GitHub currently reports it non-mergeable against the advanced protected base. Scanner repair #799 remains open Draft at exact head a6cd746e86c07452d03e0f5cef8e8d13c22f28c6 and is also currently non-mergeable pending #813 integration/base refresh. No central branch was modified from this EgressWeave loop. Fresh inspection of current EgressWeave Security Scan jobs continues to confirm the assurance defect: on #62 (31148003750), #75 (31176286321), #78 (31177581429), #84 (31176051688), and #85 (31177449623), the aggregate dependency-review job is green while the actual Dependency review action step is skipped. These runs remain valid for scanners that actually executed, but none is accepted as complete dependency-review assurance. Keep this issue open until the central repair is protected-main integrated and an unchanged EgressWeave exact-head canary executes the dependency-review action successfully.

[seonghobae]

Protected-main incident evidence — 2026-08-11

Fresh revalidation found that the fail-open dependency-review condition is no longer only hypothetical/pre-merge evidence.

• PR chore(deps): reconstruct packaging 26.3 on protected Python 3.14 main #174 exact head 0fe8e3072cc7723015c76ba0be79b7b7547cc812 was merged into protected main as 483c92329a3e0d45e604601d547cadcfbfde4135.
• Its exact-head Security Scan run 31474297691 concluded success, including dependency-review job 93724341924 concluding success.
• Inside that exact dependency-review job, Check dependency review support succeeded but the actual pinned Dependency review action was skipped. OSV, Trivy and Scorecard succeeded independently; none substitutes for the skipped dependency-diff gate.
• The merged dependency change is bounded and protected-main verification confirms packaging==26.3 remains pinned to the single reviewed wheel SHA-256 d7193f7c8e4e93f444fde0262bf90af30e16fa0ad0ad44cb553c87339b23cd1c in both requirements-ci.txt and requirements-release.txt. This is not evidence of a vulnerable packaging artifact; it is empirical evidence that the assurance/control plane permitted a dependency-changing merge without the intended dependency-review action executing.
• The separately governed central repair remains .github#897 at exact head 8fc17de86d1d22c9c11946dd7f70ff934c0b553a, open and unintegrated. EgressWeave must not add a local fail-open workaround.

RCA implication: aggregate Security Scan=success cannot be treated as dependency-review acceptance until the actual pinned action is observed executing successfully under the repaired central workflow. Protected-main/release acceptance must keep this control-plane deficiency explicit; no stale/pre-merge wrapper result should be promoted to passing evidence.

[seonghobae]

Protected-main operational acceptance incident (fresh exact evidence, 2026-08-11): EgressWeave PR #165 exact head 1f598e7b84cb810e7dd465dcafdf24480da92b5b had CI 31478620345, SAST Semgrep 31478620358, and aggregate Security Scan 31478620327 conclude success. Direct inspection of Security Scan dependency-review job 93738145249 shows Check dependency review support succeeded but the actual immutable-pinned Dependency review action at step 4 was skipped. PR #165 was subsequently merged, advancing protected main to 15c6c9513cbb743372a5a2cd766bbe7d4df5a3aa.

This is new acceptance/governance evidence for #76, not a source-level finding against #165 and not a request to revert the beneficial hard connection-deadline change. The merged source retains its own exact-head CI/SAST evidence, but the pre-repair aggregate Security Scan must not be promoted to complete dependency-review assurance merely because the ref advanced. Central .github#897 remains unintegrated at exact head 8fc17de86d1d22c9c11946dd7f70ff934c0b553a; EgressWeave remains read-only toward that central owner.

Required recovery remains fail closed: after a corrected central workflow is protected-main integrated, run a fresh EgressWeave canary on an exact protected/current tree and accept dependency-review evidence only when the support probe and the real pinned action both execute successfully. Then revalidate affected open PRs and this protected-main merge against the repaired evidence path. Do not mutate an otherwise clean EgressWeave head merely to manufacture a rerun before the central prerequisite changes.