OSPS-VM-06.02: backport SCA-style required-check gating and producer-pin protection to SastEnforcedOnChanges

[jmeridth]

🤖 Follow-up from the #423 review (AI-assisted, verified by execution at the time of filing).

Problem

SastEnforcedOnChanges (OSPS-VM-06.02, added in #421) accepts weaker enforcement evidence than its SCA twin EnforcesSCAOnChanges (OSPS-VM-05.03, added in #423). Two gaps, both demonstrated by execution during the #423 review:

1. Security Insights self-declarations can satisfy the required-check correlation directly. requiredCheckMatchesSast matches any sastSource, including raw SI entries. Reproduction: a payload with zero workflow files, an SI entry declaring CodeQL (Type: SAST, Rulesets: ["default"], Integration.Ci: true), and a required status check named CodeQL returns Passed ("A SAST tool runs in CI and is enforced as a required status check ... blocking merges on violations") with no evidence that anything actually runs. CodeQL is literally the default check name GitHub's own CodeQL action publishes, so the name coincidence is common. The SCA twin only correlates workflowContext sources, so self-declarations can lend policy evidence but never satisfy the enforcement match on their own.

2. No producer-pin protection. feat(OSPS-VM-05): evaluate SCA policy, pre-release scanning, and enforcement #423 added RepositoryMetadata.RequiredStatusChecks() preserving IntegrationID, and requiredCheckMatchesSCA treats app-pinned checks as producerUncertain rather than trusting the context name. SastEnforcedOnChanges still uses the older context-only RequiredStatusCheckContexts() and trusts names unconditionally.

Suggested fix

Backport the two mechanisms from EnforcesSCAOnChanges:

• restrict required-check correlation to workflow-derived sources (SI entries contribute policyDocumented only), and
• consume RequiredStatusChecks() with the producerUncertain handling.

Context: #423 review summary (final paragraph) records the original finding.