ci(scorecard): eliminate neutral missing-configuration PR warning without weakening Scorecard evidence

[seonghobae]

Refs #84 #87 #174 #361.

Valid current finding

Fresh exact-head review of Draft PR #361 at c6d3fd45eba1aceef074cc8b9934937f67b1d41a found one non-terminal-success security signal that must not be silently accepted: GitHub Advanced Security check Scorecard job 103545605700 completed neutral with 1 configuration not found. The check states that code scanning cannot determine alerts introduced by the pull request because the configuration present on refs/heads/main was not found for Actions workflow scorecard-analysis.yml, category supply-chain/branch-protection.

Protected main@f8260f1e03836039ff9463dd99fa982e4e270c4b owns .github/workflows/scorecard-analysis.yml. Its trigger set is branch_protection_rule, scheduled weekly, and push to main; there is no pull-request analysis. Therefore the default-branch Scorecard SARIF configuration exists in code scanning while a PR head normally has no matching Scorecard SARIF analysis for GitHub to compare. This is a causal observability/configuration mismatch, not a Wardnet product-source finding.

Current OpenSSF Scorecard upstream guidance is material to the repair choice: the supported triggers are push and default-branch schedule; pull_request is experimental and fork repositories are not supported. The canonical upstream Scorecard workflow also runs on default-branch push/schedule rather than normal PR analysis. Do not “fix” the warning by blindly enabling an unsupported/unbounded PR workflow, and do not remove Scorecard SARIF publication merely to make the neutral check disappear.

Ownership / single writer

PR #174 is the current sole writer for .github/workflows/scorecard-analysis.yml and already carries the immutable CodeQL SARIF uploader update. Keep this issue as the RED/acceptance record and repair through #174 or a verified complete successor; do not create a competing workflow writer.

RED acceptance

The existing exact #361 evidence is the reproducible RED:

• head c6d3fd45eba1aceef074cc8b9934937f67b1d41a;
• Scorecard code-scanning check 103545605700;
• conclusion neutral;
• warning 1 configuration not found for scorecard-analysis.yml / supply-chain/branch-protection.

Reproduce on one unchanged same-repository PR head before repair. A central CodeQL failure, queued runner, or unrelated source warning is not this RED.

Minimum causal GREEN

Preserve the protected-main Scorecard scan and its SARIF security evidence while making PR comparison behavior explicit and warning-free on the supported Wardnet contribution path.

• Keep OpenSSF Scorecard and SARIF uploader actions pinned by immutable SHA.
• Do not weaken/remove default-branch Scorecard evidence or code-scanning publication merely to suppress the warning.
• Do not use pull_request_target, execute untrusted PR code with privileged tokens, or grant broader permissions than needed.
• If a same-repository pull_request lane is selected, prove it against current upstream trigger support, keep fork behavior fail-closed/non-failing, and ensure the SARIF category/configuration identity matches the default-branch configuration GitHub compares.
• If GitHub cannot provide a supported safe PR comparison path for this default-branch-only scanner, document the upstream limitation and move the comparison/verification to an owner-supported evidence surface without manufacturing SUCCESS; the neutral warning must not simply be ignored.
• Preserve the existing branch_protection_rule, scheduled and protected-main push purposes unless a narrower supported replacement is proven equivalent.

Exact-head completion gate

On one unchanged #174/successor head require current CI/security/SAST/CodeQL/review/thread evidence plus an actual pull-request Scorecard comparison that no longer emits the missing-configuration warning. Re-fetch the check result after the repair. No force push, destructive rebase, self/model approval, routine bypass, workflow-source duplication, disabled security evidence, mutable action pin, or source churn solely to redispatch.

Traceability

• OpenSSF Scorecard Action documentation: supported triggers are push and default-branch schedule; pull_request is experimental and fork repositories are not supported. https://github.com/ossf/scorecard-action
• OpenSSF Scorecard canonical workflow uses default-branch push/schedule and uploads SARIF to code scanning. https://github.com/ossf/scorecard/blob/main/.github/workflows/scorecard-analysis.yml
• NIST SP 800-218 SSDF PW.8: security verification results should remain attributable and reproducible rather than suppressed for cosmetic gate success.

[seonghobae]

Experiment result on the sole Scorecard writer (#174): the same-repository pull_request hypothesis is rejected, so it has been reverted rather than left as unsupported behavior.

Evidence:

• Hostile contract RED: 455d8c045d517dfe8b3ddf2d8ad57c0ffb9ed4d0 made CI fail until a bounded PR-analysis lane existed.
• Experimental implementation: 8be149733582684b59012e0eb6f9c6426dffd77f added only a same-repo pull_request trigger/guard; local Scorecard Analysis run 34704152220 completed successfully and rust check 103581041468 was GREEN.
• GitHub Advanced Security comparison still failed its acceptance condition on that exact head: Scorecard check 103581117218 remained neutral with 2 configurations not found (supply-chain/branch-protection, supply-chain/online-scm). A successful PR-side SARIF upload therefore did not restore configuration identity for the PR comparison.
• Minimum safe response: 158195e98d1ef26f81b5feb7046ef7495a250bf5 restores Scorecard to supported default-branch evidence events and restores the contract asserting no local PR trigger, while retaining the independent v4.38.0 SARIF uploader bump.

Keep this issue open: completion still requires GitHub/Scorecard-supported configuration identity (or another proven owner-level mechanism) that removes the actual GHAS PR warning without pull_request_target, broader permissions, or weakening default-branch evidence.

[seonghobae]

Fresh independent reproduction on unchanged Agent Artifact Admission root #129@c9fbc8210b2703334d940871eae4f74547668ea1 confirms the same RED. GHAS Scorecard check 103701128517 completed neutral on 2026-09-13 with 1 configuration not found; the missing comparison configuration is Actions workflow scorecard-analysis.yml, category supply-chain/branch-protection. OSV on the same GHAS suite was SUCCESS with no new alerts.

This strengthens the existing causal diagnosis: the warning is repository contribution-path configuration/evidence behavior, not peculiar to #361 and not an Agent Artifact Admission source finding. Keep #174 (or verified complete successor) as sole workflow writer. Acceptance remains warning-free PR comparison/evidence without deleting default-branch Scorecard evidence, broadening token permissions, using privileged untrusted execution, or manufacturing SUCCESS.