Skip to content

security: fail closed when dependency review is unavailable #76

Open
Open
security: fail closed when dependency review is unavailable#76
Labels
bugSomething isn't workingpriority: high

Description

@seonghobae
seonghobae
opened on Aug 6, 2026

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.

Activity

  1. seonghobae commented on Aug 6, 2026

    @seonghobae
    seonghobae
    on Aug 6, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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:

  2. seonghobae commented on Aug 7, 2026

    @seonghobae
    seonghobae
    on Aug 7, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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.

  3. seonghobae commented on Aug 7, 2026

    @seonghobae
    seonghobae
    on Aug 7, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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.

  4. seonghobae commented on Aug 7, 2026

    @seonghobae
    seonghobae
    on Aug 7, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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.

  5. seonghobae commented on Aug 11, 2026

    @seonghobae
    seonghobae
    on Aug 11, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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.

  6. seonghobae commented on Aug 11, 2026

    @seonghobae
    seonghobae
    on Aug 11, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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.

  7. seonghobae commented on Aug 11, 2026

    @seonghobae
    seonghobae
    on Aug 11, 2026
    ContributorAuthor

    Fresh exact-state refresh (2026-08-11): central ContextualWisdomLab/.github#897 remains open at head 8fc17de86d1d22c9c11946dd7f70ff934c0b553a over protected base 6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba, with no formal approval and no protected integration. EgressWeave PR #180 run 31494794995 and current candidate runs for #146/#156/#158/#172/#173 all show the aggregate dependency-review job green while the actual pinned Dependency review action step is skipped. These are not accepted as dependency-review evidence; no affected PR is being merged through that gap. The exact current #897 candidate remains the separately governed repair path.

  8. seonghobae commented on Aug 11, 2026

    @seonghobae
    seonghobae
    on Aug 11, 2026
    ContributorAuthor

    Live recheck 2026-08-12: ContextualWisdomLab/.github PR #897 (head 8fc17de, base 6eb06cd) and #933 (head b4e60dc, same base) are OPEN, mergeable, but BLOCKED/REVIEW_REQUIRED with zero approvals. Central protected main currently requires dependency-review, opencode-review, required-workflow-bootstrap, security/review checks, one approving review, and last-push approval; only OrganizationAdmin bypass is available. EgressWeave PR #186 is the current-main docs reconstruction (head 45a4c50 over 52a5c6); #168 current head is c96bc71. Do not promote green wrapper status or skipped pinned dependency steps to acceptance, and do not merge through this unresolved central prerequisite.

  9. seonghobae commented on Aug 12, 2026

    @seonghobae
    seonghobae
    on Aug 12, 2026
    ContributorAuthor

    Current exact live prerequisite refresh: EgressWeave #168 head 3cdfc839a34f5dd0080974e2bf820a6dc6d19023 is terminal GREEN, with SARIF empty and no unresolved review threads. Central .github PRs #897 (8fc17de86d1d22c9c11946dd7f70ff934c0b553a) and #933 (b4e60dcec7abea2466b5f1d35b7f42e23313ebc8) also have terminal GREEN Checks, but both remain REVIEW_REQUIRED/BLOCKED; the live collaborator inventory contains only seonghobae. The loop therefore continues without Admin/self/bypass merge or a local fail-open dependency-review workaround.

  10. seonghobae commented on Aug 12, 2026

    @seonghobae
    seonghobae
    on Aug 12, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    Current-head update after the EgressWeave main advance to 1d2e19049354115776804c66b9366fad2ea5b6c5:

  11. seonghobae commented on Aug 15, 2026

    @seonghobae
    seonghobae
    on Aug 15, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    Central Dependency Review remediation update — 2026-08-15

    ContextualWisdomLab/.github#897 remains the canonical fail-closed Dependency Review repair at exact head 59d702f30fa419a016e24c18e87e05c76fbee4a3 over protected central main@6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba. Exact-head CodeQL, OSV, Strix changed-path quality, Scorecard, Secret Scan, Security Scan, SAST Semgrep, SBOM and Python Security workflows are terminal-success. The source repair preserves successful-transport plus exact-HTTP-200 admission, the HTTP-200/nonzero-curl negative control, explicit PR head repository/SHA checkout, read-only permissions and immutable action pins.

    Its current formal OpenCode change request is tied to an exact-head Strix failure under the still-unintegrated old central evidence path. Minimal central successor .github#1009 now has clean exact-head Strix and peer checks, auto-merge enabled, and is waiting on independent approval plus scan-pr-queue. #897 auto-merge is also enabled but must receive a fresh authoritative Strix/current-review result after #1009 reaches protected central main.

    EgressWeave candidates remain non-passing while their actual pinned Dependency Review step is skipped. No local substitute or wrapper-green inference is accepted.

  12. seonghobae commented on Aug 29, 2026

    @seonghobae
    seonghobae
    on Aug 29, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    Post-central integration consumer verification (2026-08-29): .github#897 is now merged into protected central main. I regenerated the required workflow generation for unchanged EgressWeave PR #209 without source-branch churn; exact head remains 77f5e287d6032a2eecc86a09b3888a4e14de974e against main@7faf7a3b8a47980113982914000e724ab6a6cda5, and the head branch has had no commit movement since 2026-08-12.

    Fresh required Security Scan run 33256611597 correctly failed closed. In dependency-review job 99111348918, exact-head checkout verification passed, then the exact dependency comparison returned HTTP 403 with curl_exit=0 for public ContextualWisdomLab/EgressWeave. The workflow therefore failed the Check dependency review support step and skipped the immutable-pinned actions/dependency-review-action, rather than producing the former false-green wrapper. OSV, Trivy and Scorecard jobs succeeded independently.

    This satisfies the end-to-end negative-control objective of the central repair: unavailable dependency-review evidence is now non-passing. It does not make #209 merge-ready. The remaining operational blocker is to diagnose why the public repository's exact dependency-graph compare endpoint returns 403 (repository dependency-graph/security configuration or GitHub service/permission behavior) and obtain a fresh exact-head run where the comparison is HTTP 200 and the pinned Dependency Review action actually executes and succeeds. Do not substitute the independent scanners, stale runs, or wrapper status, and do not churn the clean source head merely to retrigger the same 403.

  13. seonghobae
    added
    bugSomething isn't working
    priority: high
    on Sep 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingpriority: high

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions