security: bind reusable SAST and security scans to the exact pull-request head

[seonghobae]

Problem

Organization-required reusable security workflows currently produce synthetic-merge evidence for pull requests instead of scanning the exact submitted head.

Fresh reproduction on ContextualWisdomLab/g7#1 on 2026-08-22:

• exact PR head: 4a1773f604b3971478f486557dac137d4202086c
• GitHub synthetic merge: 8fb41406de757dd2c8edf7a7006c8bd4c68bb29f
• Security Scan run 32558956134 checked out the synthetic merge ref;
• SAST Semgrep run 32558956167 checked out the same synthetic merge ref;
• the current central sast-semgrep.yml checkout has no explicit PR-head ref;
• the current central security-scan.yml Trivy/dependency-review checkout paths likewise do not bind the scan to the submitted head.

This violates the organization merge-evidence contract: synthetic merge, predecessor-head, queued, skipped-required, or otherwise non-exact evidence must never be promoted to exact-current-head proof.

The g7 canary also shows why the distinction matters operationally: the reusable scans currently fail on broad repository/base findings (Trivy dependency findings and 234 Semgrep warning/error findings), so the leaf readiness PR must not absorb unrelated remediation simply to manufacture a passing gate.

Responsibility boundary

Fix this in the organization-central reusable workflow layer. Do not duplicate or weaken the gate in downstream repositories and do not change leaf application code to compensate for checkout semantics.

Required design

For pull-request runs, resolve and verify the immutable target repository plus pull_request.head.sha before scanning. Preserve the repository's normal default ref for protected-branch pushes and other explicitly supported events. Where a scanner legitimately compares base and head, materialize both immutable revisions and make the evidence labels unambiguous rather than treating a synthetic merge ref as the submitted head.

SARIF attribution, job summaries, logs, artifacts, and any machine-readable evidence should record the target repository, exact submitted head SHA, base SHA where relevant, and the actual checked-out commit. Fail closed if those identities disagree.

Acceptance criteria

• SAST Semgrep pull-request jobs scan github.event.pull_request.head.sha from the correct target/head repository, not refs/pull/*/merge.
• Trivy filesystem and other head-oriented Security Scan jobs scan the exact submitted PR head.
• Base/head comparison jobs materialize and label both immutable revisions without conflating either with the synthetic merge commit.
• A focused workflow contract test rejects a PR checkout without an exact-head ref.
• A downstream canary proves git rev-parse HEAD == pull_request.head.sha in SAST and Security Scan evidence.
• SARIF/check evidence remains associated with the intended pull request without weakening severity thresholds or suppressing valid findings.
• Existing least-privilege permissions, immutable action/container pins, cancellation behavior, and fail-closed security gates remain intact.
• No manual success status, stale evidence, or branch-protection bypass is introduced.

Downstream dependency

g7#1 must remain unmerged while its exact-current-head CI/security/review/protection contract is incomplete. Its broad pre-existing dependency/SAST baseline should be handled as separate security-owner work rather than mixed into the bounded readiness change.

[seonghobae]

Second independent downstream canary reproduces this defect on a buyer-critical ScopeWeave lane.

ContextualWisdomLab/scopeweave#523

• protected base: develop@2c328875e00e86537df3e965170be80532571cad
• exact contributor head: 9e72573a9f61f440bd63eaa47ab972711a7e8c52
• synthetic merge: 4b919e609ae8fc0869e0f7ed5cf99070858c51f5

Exact evidence:

• SAST Semgrep run 32538200939, job 96942943379: actions/checkout fetched +4b919e6...:refs/remotes/pull/523/merge, checked out refs/remotes/pull/523/merge, and logged HEAD is now at 4b919e6 Merge 9e72573... into 2c328875... before Semgrep ran.
• Security Scan run 32538200920, Trivy job 96942943227: the checkout fetched that same synthetic ref and logged HEAD is now at 4b919e6 ...; Trivy then scanned scan-ref: . and returned 0 CRITICAL/HIGH/MEDIUM findings on the merge tree.

Both runs are terminal-success but are non-authoritative for ScopeWeave's exact-current-head acceptance because the scanned tree is synthetic. This is not a leaf-product defect and ScopeWeave should not mutate product code to compensate.

Use this unchanged ScopeWeave head as an additional post-repair canary: SAST and every head-oriented Security Scan job must log git rev-parse HEAD == 9e72573a9f61f440bd63eaa47ab972711a7e8c52 (or the then-current unchanged successor head), with the target repository/head identity bound into machine-readable/SARIF evidence. Preserve severity thresholds, immutable pins, least privilege, and fail-closed findings semantics.

[seonghobae]

Fresh ScopeWeave contrast evidence narrows this to the central reusable security-workflow boundary rather than a leaf checkout limitation.

On unchanged ContextualWisdomLab/scopeweave#523 head 9e72573a9f61f440bd63eaa47ab972711a7e8c52 against live protected develop@2c328875e00e86537df3e965170be80532571cad, repository-owned Dependency Review run 32538200940, job 96942943190 now proves the intended contract end-to-end: actions/checkout uses ref: 9e72573..., git rev-parse HEAD is checked against EXPECTED_CHECKOUT_SHA, git ls-remote origin refs/heads/develop independently resolves the live base to 2c328875..., ancestry is fail-closed, and dependency-review-action receives explicit immutable base-ref: 2c328875... / head-ref: 9e72573....

The same exact ScopeWeave head's centrally required SAST run 32538200939 / job 96942943379 and Security Scan run 32538200920 / Trivy job 96942943227 still checked out synthetic merge 4b919e609ae8fc0869e0f7ed5cf99070858c51f5. That working-path comparison rules out a GitHub platform inability to bind PR evidence to the contributor head.

Repair-first acceptance for this owner lane: add a central workflow-contract RED that fails whenever head-oriented SAST/Security checkout omits the exact submitted PR head; implement the smallest reusable-workflow identity binding with explicit target repository/head and runtime git rev-parse HEAD attestation; keep base/head comparison jobs explicitly dual-revision; preserve severity, immutable pins and least privilege; then rerun this unchanged ScopeWeave canary and require SAST plus every head-oriented Security job to attest 9e72573... before their success can count as exact-head evidence.

[seonghobae]

Fresh owner-path escalation: there is still no open repair PR matching #1222. Keep this as a repair-first control-plane lane, not a blocker-reporting lane. Current ScopeWeave canaries remain suitable without leaf churn: #523 exact contributor 9e72573a9f61f440bd63eaa47ab972711a7e8c52 versus synthetic merge 4b919e609ae8fc0869e0f7ed5cf99070858c51f5, and #552 exact contributor d153ec943ca9e9cdca07a2c7e49e2e80b5a66ee4 where centrally-owned SAST/Security likewise materialized the PR merge ref. The repository-owned Dependency Review working path on #523 already demonstrates the intended pattern: explicit exact-head checkout, runtime SHA attestation, independently resolved live base, ancestry validation, and explicit base/head inputs. Required next action remains: add a central RED workflow-contract regression for PR-head identity, bind SAST/Security checkout and scanner input to pull_request.head.sha (protected-push fallback github.sha), fail closed on mismatch, then rerun an unchanged downstream ScopeWeave canary and preserve actual checkout-SHA evidence. Do not weaken severity, permissions, immutability, or existing gates.

[seonghobae]

Fresh current-head canary confirms #1222 remains live on the latest ScopeWeave root lane; no leaf mutation is correct.

ContextualWisdomLab/scopeweave#523

• protected base: develop@2c328875e00e86537df3e965170be80532571cad
• exact contributor head: a73e8be6d25b422b69acdeacf3b3b161f6f4ff7d
• GitHub synthetic merge: a45d5fddf0bd951c1f66f3ca92513db616d21f21

Current exact evidence:

• SAST Semgrep run 32594482805, job 97083198497, completed success, but actions/checkout fetched +a45d5fdd...:refs/remotes/pull/523/merge; runtime log reports HEAD is now at a45d5fd Merge a73e8be6... into 2c328875... before Semgrep scans. The 0-finding result therefore describes the synthetic merge tree, not the submitted head.
• Security Scan run 32594482813, Trivy filesystem job 97083198646, completed success, but its checkout likewise fetched +a45d5fdd...:refs/remotes/pull/523/merge, checked out that merge, and reported runtime HEAD = a45d5fdd...; Trivy then scanned scan-ref: . and reported 0 CRITICAL/HIGH/MEDIUM findings on the synthetic tree.
• In contrast, ScopeWeave's repository-owned Server Tests run 32594482787 is already exact-head-aware: both unit-and-api and cloud-e2e passed an explicit Verify exact checkout step on the current contributor head. This continues to rule out a platform inability to bind PR work to the immutable submitted head.

These green central scans remain NON-PASSING exact-head evidence. Drive the existing owner lane test-first: add a deterministic RED workflow-contract fixture that rejects head-oriented PR checkout without the exact submitted repository/head; bind SAST and head-oriented Security Scan jobs to pull_request.head.sha; attest git rev-parse HEAD against the expected SHA before scanning; keep genuine base/head comparison jobs explicitly dual-revision; fail closed on identity mismatch; preserve current severities, least privilege, immutable pins, cancellation and SARIF semantics. GREEN acceptance is an unchanged/then-current ScopeWeave #523 canary whose SAST and head-oriented Security jobs record actual checkout SHA equal to the exact contributor head.

[seonghobae]

Fresh downstream reproduction from ScopeWeave confirms this is still live and required-workflow-owned, not a leaf-repository defect.

Current exact evidence (2026-08-23 KST)

Target: ContextualWisdomLab/scopeweave#523

• protected live base: develop@2c328875e00e86537df3e965170be80532571cad
• exact contributor head: a73e8be6d25b422b69acdeacf3b3b161f6f4ff7d
• GitHub synthetic merge: a45d5fddf0bd951c1f66f3ca92513db616d21f21
• central required-workflow SAST Semgrep run: 32594482805, job 97083198497
• run metadata reports head_sha=a73e8be..., but workflow_url is actions/required_workflows/312345790, proving the owning boundary is the organization required workflow rather than ScopeWeave source.
• the Semgrep job's checkout has no explicit PR-head ref; its log fetches +a45d5fdd...:refs/remotes/pull/523/merge, checks out refs/remotes/pull/523/merge, and scans that synthetic merge. It then reports 0 findings and uploads SARIF. Under the exact-head evidence contract this success is non-passing evidence for a73e8be....

Working-path comparison on the same ScopeWeave head proves the leaf repository can bind exact evidence correctly:

• Server Tests run 32594482787: immutable checkout pin, explicit ref: a73e8be..., detached exact checkout, explicit git rev-parse HEAD == EXPECTED_CHECKOUT_SHA; 100% owned production statement/branch/function/line coverage and 154 browser tests pass.
• Fuzz run 32594482887, job 97083198541: exact a73e8be... checkout + explicit SHA verification, 20,000-run budget, 14/14 fuzz/property targets pass.
• repository OSV Scanner run 32594482954, job 97083198820: independently resolves protected develop to 2c328875..., separately checks out and verifies exact a73e8be..., compares base/head findings fail-closed, reports no issues, and preserves exact-head SARIF.
• repository Dependency Review run 32594482970: resolves current protected base 2c328875..., verifies compare/dependency endpoints before the hard gate, then evaluates exact head a73e8be....

First failing boundary / root cause hypothesis

The central required sast-semgrep.yml still relies on default actions/checkout pull-request behavior. For pull_request, that resolves the synthetic refs/pull/<n>/merge commit even though run metadata exposes the contributor head. The scanner therefore attests the merge-test tree, not the submitted head.

RED acceptance test

Add/retain a central workflow-contract fixture for a PR event with deliberately different pull_request.head.sha and synthetic merge SHA. It must fail while the SAST checkout lacks an explicit immutable contributor-head ref, and must reject any evidence where git rev-parse HEAD != github.event.pull_request.head.sha (with correct head-repository handling for forks).

Smallest causal remedy

For PR runs, bind SAST checkout to the immutable submitted head SHA and correct head repository, immediately verify the actual checkout SHA, and bind SARIF/check metadata to that verified identity. Preserve protected-branch behavior for non-PR events, immutable action/container pins, current severity threshold, least privilege, code-scanning upload, and fail-closed engine behavior. Do not synthesize success for the leaf repository.

Apply the same exact-head identity contract to head-oriented Security Scan jobs; comparison jobs should materialize base and head separately and label both immutable revisions.

Required GREEN consumer evidence

After the central fix reaches protected .github main, rerun the required workflows on the then-current unchanged ScopeWeave #523 head (or its fresh successor) and require logs to prove git rev-parse HEAD == pull_request.head.sha in SAST and every head-oriented Security Scan job before those checks are accepted as exact-head evidence. ScopeWeave must regenerate all current-head security evidence after that integration; the present synthetic SAST success must not be grandfathered.

[seonghobae]

Fresh current-head evidence from ContextualWisdomLab/scopeweave#552 confirms the central checkout defect still reproduces after that contributor branch moved; no ScopeWeave source mutation is an appropriate workaround.

• protected base: develop@2c328875e00e86537df3e965170be80532571cad
• exact contributor head: ba2aab41d037b5f0e7334b1b70b7732fe976d2c9
• GitHub synthetic merge: 9be76f8f94e2d8298fc65e52f1e3035eff58850f

Exact current evidence:

• SAST Semgrep run 32603898670, job 97106048262, completed success. actions/checkout fetched +9be76f8...:refs/remotes/pull/552/merge, checked out refs/remotes/pull/552/merge, and logged HEAD is now at 9be76f8 Merge ba2aab41... into 2c328875... before Semgrep scanned the workspace and reported 0 findings.
• Security Scan run 32603898651, Trivy filesystem job 97106048360, completed success. Its checkout independently fetched the same pull/552/merge ref and logged runtime HEAD = 9be76f8f94e2d8298fc65e52f1e3035eff58850f; Trivy then scanned scan-ref: . and reported 0 CRITICAL/HIGH/MEDIUM findings on that synthetic merge tree.

This is a fresh successor-head reproduction, not transferred predecessor evidence. The first failing boundary remains the centrally reusable head-oriented SAST/Security checkout contract: green scanner conclusions are bound to the PR merge ref instead of the immutable submitted contributor head.

Repair-first acceptance remains unchanged: add a deterministic central RED contract that fails when a PR head-oriented scan does not materialize the submitted repository/head SHA; bind SAST and head-oriented Security jobs to the exact pull_request.head.sha; assert git rev-parse HEAD == expected_head_sha before scanning; keep genuine base/head comparison jobs explicitly dual-revision; preserve current severity thresholds, immutable action/image pins, SARIF behavior, cancellation and least-privilege permissions; then rerun an unchanged/then-current ScopeWeave canary and require machine-readable actual-checkout evidence equal to the contributor head before those green scans count as exact-head evidence.

[seonghobae]

Fresh ScopeWeave canary after a same-invocation branch repair confirms the central exact-head defect is still live and also shows why terminal-success must remain non-authoritative.

ContextualWisdomLab/scopeweave#586

• live protected base: develop@2c328875e00e86537df3e965170be80532571cad
• exact contributor head: ba0e9b7669a00554b6a201d857a02646c83a7955
• GitHub synthetic merge materialized by current checks: 88626d13912b2b92b2aa171053c539294a9de893

Current-head evidence:

• SAST Semgrep run 32611406693, job 97124990038, terminal success: checkout fetched +88626d1...:refs/remotes/pull/586/merge, checked out that ref, and logged HEAD is now at 88626d1 Merge ba0e9b7... into 2c328875... before Semgrep scanned 64 tracked files and reported 0 findings.
• Security Scan run 32611406714, Trivy job 97124990200, terminal success: checkout fetched and checked out the same synthetic merge 88626d1...; trivy fs . then scanned that merge tree and reported 0 CRITICAL/HIGH/MEDIUM findings.
• Repository-owned Server Tests run 32611406700, unit-and-api job 97124990243, also checked out 88626d1...; this leaf-side behavior is separately repairable by ScopeWeave fix(opencode): App 전용 review identity 계약을 통합 게이트와 일치 #523 and does not change ownership of the centrally reusable SAST/Security defect.

This canary is especially useful because #586's actual current diff is only two modulepreload declarations in index.html, so no leaf security mutation is a correct substitute for immutable scan identity. Keep #1222 repair-first: add/retain the RED workflow-contract test for PR-head identity, bind every head-oriented SAST/Security checkout and scanner input to the submitted immutable head, attest git rev-parse HEAD, preserve dual-revision base/head jobs where semantically needed, and rerun an unchanged ScopeWeave canary before promoting a terminal success to exact-head evidence. Preserve severity thresholds, least privilege, immutable pins, SARIF attribution, and fail-closed mismatch handling.