[Security] Fail closed when Strix produces no authoritative scan evidence

[seonghobae]

Problem

A Strix provider/backend outage can currently leave the required workflow in a skipped or neutral-success shape without authoritative scan evidence. GitHub may treat successful, skipped, or neutral required-check conclusions as satisfying the check name, so transport/provider availability can be confused with security success.

Required contract

A mandatory security gate passes only when authoritative Strix evidence is present for the exact source head and relevant live-base context. Provider/tool unavailability is a typed deferred or failing state, never scan success.

Acceptance criteria

• Add a terminal always-running gate that evaluates every prerequisite and exact-head Strix receipt.
• Missing, skipped, neutral, cancelled, action-required, predecessor-head, synthetic, or untrusted-producer evidence is non-passing when Strix is required.
• Retry only classified transient provider failures within attempt and wall-clock budgets.
• Preserve useful bounded diagnostics while applying publication-boundary credential redaction.
• Tests cover provider outage, empty output, skipped job, neutral conclusion, timeout, stale head, fallback exhaustion, and valid current-head finding/no-finding evidence.
• Ruleset documentation names the expected check source/producer.
• Protected-main consumer evidence demonstrates both fail-closed outage and recovery.

Related work

Coordinate log redaction with #842 and retry policy with ADR-0003.

[seonghobae]

Fresh ScopeWeave exact-head evidence reproduces this fail-open class on a required Strix lane and should be treated as central-owner repair input, not leaf success.

Target: ContextualWisdomLab/scopeweave#523

• protected live base: develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185
• exact contributor head: 58b542103a3c6009d693d32410340c1262ee87a3
• central Strix run/job: run 31978036107, job/check 95240357165
• GitHub check state: status=completed, conclusion=success
• annotation: Strix backend unavailable — "Strix could not complete because its LLM backend was unavailable (rate limit / token cap / connection or warm-up failure) before producing a vulnerability report. Treating as a neutral skip so an infrastructure outage does not block merges; genuine findings still fail the check."

That result conflicts with this issue's acceptance contract that provider/backend unavailability, missing report evidence, neutral/skipped evidence, and other unavailable-review states are non-passing when Strix is required. ScopeWeave therefore treats the current strix result as non-authorizing despite the green check conclusion and will not weaken or patch its product branch to compensate.

Required central acceptance/revalidation for this reproduction: make the exact same backend-unavailable/no-report condition non-passing (or a typed deferred state that cannot satisfy the required workflow), retain bounded classified retry/fallback, preserve genuine finding failure semantics, then rerun Strix against this unchanged ScopeWeave head and require authoritative exact-head report evidence before merge classification.

[seonghobae]

Fresh Context Fabric reproduction on the protected Enterprise Architecture Core synchronization root confirms the same fail-open Strix contract and blocks treating the lane as merge-authorizing.

Target: ContextualWisdomLab/enterprise-architecture-core#14

• protected live base: develop@1c0fa8b15ceb9e72186274aeb255d6777eb84ef4
• exact contributor/head branch: main@ca6889497728e1a3f09d68790a9096576e13a3ff
• GitHub merge candidate: 30ef39d345bb00fac57a511732a6dd4ddbdf2361
• central Strix run/job/check: run 32036458615, job/check 95407832860
• GitHub check state: status=completed, conclusion=success
• exact annotation: Strix backend unavailable; the backend hit a rate-limit/token-cap/connection/warm-up failure before any vulnerability report and the workflow explicitly says it is treating that condition as a neutral skip so it does not block merges.
• live org ruleset 18156473 requires .github/workflows/strix.yml on protected develop.

This is non-passing under the issue acceptance contract and Context Fabric gate policy: rate-limited/backend-unavailable/neutral/no-report evidence cannot authorize integration merely because GitHub received a green conclusion. No leaf branch change or gate weakening is appropriate.

Required central RED/GREEN acceptance for this exact reproduction: first preserve a regression proving the backend-unavailable/no-authoritative-report condition cannot satisfy the required Strix gate; then make that state terminal non-passing (or typed deferred in a way the required gate cannot accept), retain bounded classified retry/fallback and credential-safe diagnostics, and revalidate the unchanged exact #14 candidate with authoritative Strix report evidence. Context Fabric will re-evaluate #14 only from fresh exact-head/base evidence after the central repair.

[seonghobae]

DiskSage has a concrete leaf-repository reproduction that should be included in this central acceptance matrix rather than patched locally: ContextualWisdomLab/disksage#212 exact head be1696159b97c9714b39c0133e0b64e42860e48b, required Strix run 31689301907, attempt 4, job 94632920593, central workflow source ContextualWisdomLab/.github@6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba. The PR changed Rust production paths under src-tauri, but the Strix target materialized through the central __PR_SCOPE__ path contained workflow/support material rather than the changed product source. Strix explicitly reported that no source code was available for assessment, then the required workflow still concluded success/zero findings. DiskSage tracks the leaf evidence in #221 and must not work around this by synthesizing source or weakening the required check.

Please include this as a distinct RED acceptance fixture for #891: when exact diff discovery contains at least one scannable product/config/workflow blob, PR-scope materialization must preserve every admitted blob at exact head bytes (execute bits stripped), emit a bounded path + head blob SHA + materialized digest/source-class manifest, require at least one scannable materialized file, and reject a Strix result that says no source/no code/no assessable target or otherwise lacks structured coverage of that manifest. The terminal receipt must bind repository, exact head, live-base context, manifest digest, and completed scan result. Missing/mismatched/stale/empty/no-source evidence stays non-passing. A repaired central canary should be replayed against an unchanged DiskSage head containing a real src-tauri change before this leaf blocker is considered resolved.

[seonghobae]

Fresh Inkspan exact-head reproduction for the existing Strix owner contract:

• Consumer: ContextualWisdomLab/inkspan PR feat(cloudflare): DNS-as-code + reusable Pages deploy for 6 org zones #362
• Exact head: 11d5cfecdcc0949ec98e6ca110d482124bff00c4
• Required Strix run/job: 32344526380 / 96350330274
• The primary and fallback NVIDIA NIM attempts returned HTTP 429 rate-limit failures.
• The fallback then emitted a HIGH CVE-2022-25314 for golang.org/x/oauth2, attributed to SECURITY.md and a Strix workspace path. Inkspan and the PR changed-file set contain zero Go files, go.mod, or go.sum files and no golang.org/x/oauth2 reference.
• The run therefore has no source-backed Inkspan dependency finding; it remains correctly non-authorizing because the provider/model and attribution evidence are not trustworthy.

Please include this as a central RED fixture for #891: provider rate-limit/fallback exhaustion must remain terminal non-passing, and any fallback finding must be bound to an exact materialized changed-file manifest before it can fail or authorize a leaf PR. Inkspan will not add a local dependency rewrite, suppress the finding, rerun unchanged evidence, or weaken the required gate. The leaf can be revalidated only after the central repair and a fresh exact-head scan.

[seonghobae]

Inkspan follow-up: PR #373 (head 724b45b8d824be9581f0f29cc6eb07e6aeceb70f) raises the workspace override floors for fast-uri, nanoid, and postcss and refreshes pnpm-lock.yaml. Local pnpm audit, typecheck, package-config tests, build, and full package verification pass. The PR is open and not merged; protected-main review and required checks remain authoritative. No Strix suppression or protection bypass is being used.

[seonghobae]

Current central owner lane for this issue: PR #1153 (fix(strix): fail closed on incomplete provider scans), exact head 2e8e78271481a5ac0d7c6502973aa9ee8cfbc206 against .github/main@aa8503f4383e8328d89104796bc3e9f7da810376. It contains the typed non-passing provider evidence and exact scan-boundary repairs relevant to Inkspan #362. Current state: 38 checks completed, Strix in progress, 7 queued, no failures, and no formal approval. Inkspan will not rerun unchanged Strix or bypass the central gate; revalidation remains downstream of this protected central repair.

[seonghobae]

Fresh owner repair: #1255 exact head a1fc43a13085b4dbe9367a871e33461c4eea9ae0 addresses the new authoritative false-negative boundary observed in #897 run 32633538138 job 97191695465 and #941 run 32631414731 job 97191719493. Both complete NVIDIA NIM scans reported Vulnerabilities 0 but were rejected because Strix's exact MODEL QUALITY WARNING advisory was classified as provider failure; #941 also reproduced the report-log form. Two deterministic RED fixtures precede the narrow shared classifier fix. Exact-head hosted quality run 32640211595 passed 1,393 tests, 16 subtests, and the full quick-gate. Keep #891 open through reviewed protected-main integration and unchanged #897/#941 operational reruns; genuine provider exhaustion remains non-passing.

[seonghobae]

Fresh OriginWeave owner-route evidence (2026-08-28 KST), preserving fail-closed semantics and without any leaf workaround:

Two independent exact OriginWeave heads are currently blocked by the central required Strix workflow at the provider/fallback boundary rather than by a demonstrated leaf finding.

• OriginWeave#37 exact head 2aafc9893f7d18a4b62d90d55f77687be39c5bb4: required strix check 98537456818 is completed failure in central run 33046673523.
• OriginWeave#40 exact head 3c6bcd47773132fbd6584390a2e57988b2539454: required strix check 98454281982 is completed failure in central run 33048578455 attempt 2. The job reaches Run Strix (quick) and then fails after the trusted central workflow/materialization/setup steps succeed.

The #40 exact-head strix-reports artifact (9639384592, digest sha256:7519499d5ba59e482274415ce5e3e8a4d3478345a5ae8865fcf3c5a09547fa05) shows a provider cascade rather than a target-code vulnerability verdict: NIM primary repeatedly receives HTTP 429, the NIM fallback returns 404 Function Not Found, the OpenRouter fallback returns API 502 / Invalid URL from provider Stealth, and the OpenAI-direct fallback ends in insufficient_quota / credit_balance_exhausted. An intermediate scan path reports 0 vulnerabilities, but the required workflow correctly refuses to promote incomplete/provider-failed evidence to success.

Please treat this as a fresh consumer reproduction for #891's authoritative-evidence/retry contract. The needed repair belongs in the central Strix provider/fallback/retry path: preserve bounded retries and fail-closed publication, but ensure currently configured fallback providers are actually usable/authority-equivalent and classify the repeated provider failures without requiring leaf source churn. After central repair, rerun/revalidate the unchanged exact OriginWeave heads rather than manufacturing a manual success status.