[Security evidence] Eliminate GHAS configuration-not-found neutral warnings for Trivy/Scorecard PR comparisons

[seonghobae]

Current exact evidence

Last verified GHAS configuration-gap reproduction remains canonical Resource Admission predecessor #866 exact 0cb51e4d042a8f4cd5742086156a307bfe1ffac6 against protected develop@314ddeae7b775a4957594b599358c8255617eb2e:

• GHAS Trivy check 103480597226 completed neutral with 2 configurations not found: .github/workflows/security-audit.yml:security-backstop and historical .github/workflows/trivy.yml:trivy-fs-scan.
• GHAS Scorecard check 103480593407 completed neutral with 1 configuration not found: .github/workflows/ossf-scorecard.yml:supply-chain/branch-protection.

The protected required Actions contexts named trivy-fs and scorecard were independently GREEN on that same exact predecessor, so this is not evidence that those required jobs failed. It is an evidence-continuity defect: GitHub could not determine PR-introduced alerts for every configuration registered on the protected branch.

Canonical #866 has since advanced normally to exact 7156aebd4a745cab4842d15aba319a72c80e1d98, Open / Draft / mergeable. This latest move only repairs stale Tauri source-contract assertions after repository rust-check exposed them; it does not intentionally change code-scanning configuration. Do not transfer the old neutral receipts to this head or claim the control-plane gap disappeared. At the latest fresh read, current-head Security Scan/Trivy and CodeQL are still queued/pending, so the complete current GHAS Trivy/Scorecard comparison has not settled. The predecessor 0cb51e4d... remains the latest verified configuration-gap detection receipt until an unchanged newer head produces equivalent terminal GHAS evidence.

Protected develop and #866 have no intentional Resource Admission-owned workflow/source change that would make a missing SARIF configuration a product-source fix. security-audit.yml intentionally runs on protected-branch push/manual paths and uploads Trivy SARIF. ossf-scorecard.yml likewise produces default/protected-branch evidence. A PR head therefore does not naturally emit every branch-only SARIF configuration. Historical trivy.yml:trivy-fs-scan has no current protected workflow source, so continued appearance must be treated as control-plane/configuration-lifecycle evidence rather than solved by restoring a deleted workflow.

Required RCA

Before changing source or policy, determine for each missing configuration:

1. the exact Code Scanning tool/category/analysis-key identity currently registered on protected develop;
2. which current repository or central .github producer owns that identity and whether it is intentionally branch-only, superseded, or orphaned;
3. whether the central PR required workflow can publish an equivalent authenticated SARIF configuration without duplicating scanning or weakening trust boundaries;
4. whether a historical configuration such as trivy.yml:trivy-fs-scan needs supported GitHub control-plane retirement/cleanup rather than repository source restoration;
5. why the required Actions contexts can be GREEN while the GHAS PR-comparison surface remains neutral, and what evidence auditors/buyers currently lose.

Acceptance

• No configuration(s) not found neutral warning remains for active Trivy/Scorecard configurations on a fresh unchanged PR head, or GitHub-supported configuration retirement proves the stale identity no longer participates in PR comparison.
• Required trivy-fs and scorecard protection contexts remain fail-closed; no context deletion, synthetic success, threshold relaxation, duplicate local scanner, or source-only workaround.
• Repository backstop vs central .github PR ownership is explicit and versioned; if central reusable workflows own PR SARIF, BandScope consumes a released/exact-SHA contract rather than copying source.
• Historical configuration cleanup uses supported control-plane lifecycle operations with before/after evidence; do not resurrect deleted trivy.yml merely to satisfy a stale configuration identity.
• Fresh protected-base and PR-head code-scanning evidence demonstrates continuity, and security/operability doctoring records the final owner boundary.

Single-writer boundary

While #866 owns the active BandScope source lane, this issue is read-only RCA/control-plane evidence only. Do not create a BandScope source branch/PR or edit workflows concurrently. A later implementation may start only after the canonical source lane is explicitly free, and only in the canonical owner (BandScope repository or released central .github contract) established by the RCA.

[seonghobae]

Fresh read-only RCA on #866 current exact head 0cb51e4d042a8f4cd5742086156a307bfe1ffac6 confirms the warning is configuration-identity continuity, not a scanner execution failure.

• GHAS Trivy remains neutral with 2 configurations not found while the PR's independent scanner/gate evidence is otherwise present. This reproduces after preserve projectId whitespace-admission evidence for #866 #1197 succession, so the warning is not tied to the old fix(audio): establish canonical local-audio resource policy #866 head.
• Protected develop@314ddeae7b775a4957594b599358c8255617eb2e security-audit.yml is branch-only (push develop/main + manual) and uploads Trivy SARIF from job security-backstop; a PR head cannot naturally publish the same workflow/category identity from that file.
• Protected ossf-scorecard.yml is also branch-only for SARIF publication: ossf/scorecard-action and scorecard-sarif-upload are conditioned on the repository default-branch ref. A PR head therefore does not reproduce that protected-branch SARIF configuration identity either.
• .github/workflows/trivy.yml is absent at the protected base (contents API 404), so trivy.yml:trivy-fs-scan is an orphaned historical code-scanning configuration. Restoring the deleted workflow would be a source-level workaround, not lifecycle repair.

Implication: there are two distinct classes to repair. Active branch-only Trivy/Scorecard identities need an authenticated PR-comparison producer with stable configuration identity, preferably a released/exact-SHA central owner rather than copied BandScope workflow source. The deleted trivy.yml identity needs GitHub-supported code-scanning configuration retirement/control-plane cleanup. Required trivy-fs/scorecard Actions contexts stay fail-closed and unchanged.

No BandScope source/workflow change was made while #866 owns the source lane.

[seonghobae]

Fresh unchanged-head GHAS continuity receipt on canonical Resource Admission #866 exact 7156aebd4a745cab4842d15aba319a72c80e1d98 supersedes the older 0cb51e4d... reproduction as the latest verified detection.

GitHub Advanced Security PR-comparison checks on this exact head are terminal neutral:

• Trivy check 106802165437: neutral, 2 configurations not found — .github/workflows/security-audit.yml:security-backstop and historical .github/workflows/trivy.yml:trivy-fs-scan;
• Scorecard check 106802000230: neutral, 1 configuration not found — .github/workflows/ossf-scorecard.yml:supply-chain/branch-protection.

At the same time, the protected required Actions contexts on the identical exact head are healthy:

• trivy-fs 106734022826: SUCCESS;
• scorecard 106734022753: SUCCESS;
• GitHub-managed dynamic CodeQL Analyze (javascript-typescript) 106684070762: SUCCESS;
• Analyze (python) 106684070975: SUCCESS.

So the current evidence again separates required-context health from GHAS PR-comparison continuity. This is not a Resource Admission source failure and does not justify resurrecting deleted trivy.yml, adding duplicate scanners, weakening required checks, or changing #866 source. Keep #1209 as the control-plane/configuration-lifecycle owner until active configuration identity/retirement is proven with supported GitHub lifecycle evidence.