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

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.

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.

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.

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.

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.

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.

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.

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.

Central source repair for exact-head security evidence is now split across the existing canonical owners rather than a competing PR:

Security Scan owner fix(security): fail closed on unavailable dependency review #897: exact head 9ac7cef1fc611d010429955d7b1fbd62002929c8; Security workflow + contract tests; full local central suite 1382 passed, 1 skipped, 16 subtests passed.
SAST Semgrep owner fix(semgrep): make the pinned image digest authoritative #941: exact head 476ff5c8b1356b17b2a5801b693644cf03c5e90a; SAST workflow + contract tests; full local central suite 1381 passed, 1 skipped, 16 subtests passed.

Both branches are now mergeable against protected main@23a776ed37027d8ab8ab2aefcf81fac586352e2f, use explicit immutable repository/SHA checkout, attest actual HEAD, fail closed on mismatch, and preserve existing pins, permissions, severities, and gates. Hosted exact-head checks are still queued/in progress, so this is source/test progress only—not acceptance. Keep #1222 open until reviewed protected-main integration and a fresh ScopeWeave #523 canary prove SAST and head-oriented Security jobs actually scanned the then-current contributor head.

Protected-main SAST integration now has fresh downstream exact-head GREEN evidence (2026-08-28); this closes the SAST half of #1222 acceptance but not the Security/Trivy half.

canonical SAST owner PR fix(semgrep): make the pinned image digest authoritative #941 merged under protected governance as .github/main@7dd8a22bdd0ce9aa4a636eb410715134129f5c4d;
unchanged/current consumer: ContextualWisdomLab/scopeweave#523, protected base develop@2c328875e00e86537df3e965170be80532571cad, exact submitted head 135117e0594939240e787a161574b6fb4e10f155;
fresh SAST attempt: run 33148083441, job 98791495212, terminal success.

Exact operational evidence:

checkout input binds repository: ContextualWisdomLab/scopeweave and ref: 135117e0594939240e787a161574b6fb4e10f155;
runtime HEAD is now at 135117e...;
fail-closed attestation emits SAST_CHECKOUT ... expected_sha=135117e... actual_sha=135117e...;
SARIF upload binds sha: 135117e0594939240e787a161574b6fb4e10f155.

The predecessor synthetic merge 7f133dc301c9a2f86bd3a0f0c273ef676bf18e6a is no longer the SAST scanner workspace. Preserve this job as the exact-head SAST consumer canary.

Keep #1222 open: the current Security/Trivy head-oriented path remains owned by open PR #897 and still requires protected-main integration plus a fresh unchanged/current consumer run proving its workspace SHA equals the submitted head. Do not transfer SAST success to Trivy, predecessor runs, or aggregate status-only evidence.

Fresh ScopeWeave canary on the current contributor head keeps this owner defect actionable.

ContextualWisdomLab/scopeweave#523

protected base: develop@2c328875e00e86537df3e965170be80532571cad
exact contributor head: 135117e0594939240e787a161574b6fb4e10f155
centrally required SAST: run 33148083441 (attempt 2), job 98791495212
centrally required Security Scan: run 33148083432

The SAST owner path now demonstrates the correct exact-head pattern: the job has explicit Checkout exact submitted revision and Verify exact submitted revision steps, both GREEN before Semgrep. Preserve that behavior.

The current central security-scan.yml still leaves head-oriented dependency-review, trivy-fs, and scorecard on default actions/checkout with no explicit target repository/ref and no runtime git rev-parse HEAD == pull_request.head.sha attestation. On a pull_request required-workflow run that remains non-authoritative exact-head evidence even though the run metadata reports head_sha=135117e...; the checkout contract itself is still merge-ref-dependent. OSV is the working contrast because it explicitly materializes base.sha and head.sha.

Repair-first next action at this owner boundary: add/keep a workflow-contract RED that rejects head-oriented Security Scan checkout lacking repository: ${{ github.event.pull_request.head.repo.full_name }} + ref: ${{ github.event.pull_request.head.sha }} and post-checkout SHA attestation; apply the smallest reusable-workflow fix to dependency-review/Trivy/Scorecard head scans (while retaining OSV's explicit dual-revision semantics), then rerun this unchanged ScopeWeave canary and require the actual checked-out SHA in evidence. Preserve severity thresholds, immutable pins, least privilege, cancellation, SARIF attribution and fail-closed behavior. Do not compensate in ScopeWeave leaf product code.

Fresh Inkspan post-integration canary narrows #1222: the SAST exact-head lane is now GREEN on protected central truth, while the Security Scan half of this issue remains independently open.

Consumer: ContextualWisdomLab/inkspan#389

protected Inkspan base: main@128a239f8b71ca16add4b9e15e21752d1ad63ff0
exact contributor head: 22a17e48d471bde37a3b6672a4775c02db86597a
central Semgrep owner PR fix(semgrep): make the pinned image digest authoritative #941 merged as 7dd8a22bdd0ce9aa4a636eb410715134129f5c4d; a fresh compare proves that merge commit is an ancestor of current protected .github/main@cdde0d82602d9568128fd0c1e985ea40b2292710
SAST Semgrep run/job: 33153865336 / 98791931828

The exact same-head SAST job reports head_sha=22a17e48...; Checkout exact submitted revision succeeded; Verify exact submitted revision succeeded; the pinned-manifest verification and Semgrep scan then completed successfully. This is materially different from the earlier synthetic-merge canaries and is acceptable downstream proof for the SAST PR-head identity slice.

Do not close #1222 yet. The same Inkspan head's required Security Scan still contains a non-passing dependency-review path (run 33153865309, job 98791932194): its support probe succeeds, the actual Dependency review action step is skipped, and the job still concludes success. Treat the SAST acceptance criterion as revalidated after #941, but keep the Security Scan/exact dependency path routed to its existing owner (#810/#897). No Inkspan-local scanner workaround is correct.

Fresh central exact-head reproduction on 2026-08-28:

owner PR: fix(osv): preserve immutable direct-source provenance #1158
submitted head: 3fce14ea991cf5d239ca141d6c24e0d4fe14953f
protected base: e5e0d3652a19d12db29e687924dbaf978cd78912
synthetic merge: effefbe7b18e82382d4c73792bb57dfdffb20983
Security Scan run: https://github.com/ContextualWisdomLab/.github/actions/runs/33179961235

Despite GitHub-success:

trivy-fs job 98878388066 checked out refs/remotes/pull/1158/merge and recorded runtime HEAD effefbe7b….
dependency-review job 98878388133 did the same.
The exact submitted head was therefore not the scanned checkout identity for either head-oriented job.

This independently reproduces #1222 inside the central repository after the SAST repair. The results remain non-passing exact-head evidence even though GitHub marks both jobs successful. No consumer workaround or severity/gate change is appropriate; the owning Security workflow still needs explicit head repository/SHA checkout and pre-scan git rev-parse HEAD attestation.

Fresh downstream canary narrows the remaining owner defect to the reusable Security Scan half after the SAST repair shipped.

ContextualWisdomLab/scopeweave#505 is unchanged at exact contributor head 51418c09e261b7d1b4dd694c42ceee63d22513f4 against protected develop@2c328875e00e86537df3e965170be80532571cad; GitHub's synthetic merge for this state is 10287e9e386e93a0660e9280c89542eff69a4d57.

Working path: SAST Semgrep run 33165298520, job 98829150661, now has explicit Checkout exact submitted revision + Verify exact submitted revision steps and completed successfully, so the central SAST repair is effective on this current ScopeWeave head.

Remaining failure: Security Scan run 33165298499, Trivy job 98829150651, still fetched +10287e9e386e93a0660e9280c89542eff69a4d57:refs/remotes/pull/505/merge, checked out refs/remotes/pull/505/merge, logged HEAD is now at 10287e9 Merge 51418c09... into 2c328875..., then scanned scan-ref: . and reported success. That green result is therefore synthetic-merge evidence, not exact-head evidence for 51418c09....

Please keep the existing #897/security owner lane repair-first: add/retain the RED contract for Trivy/head-oriented security checkout identity, bind the checkout/scanner input to the immutable submitted head, attest git rev-parse HEAD == 51418c09e261b7d1b4dd694c42ceee63d22513f4 (or the unchanged then-current canary head), preserve the separately labeled base/head OSV comparison path, severity thresholds, least privilege, immutable pins, and fail-closed behavior, then regenerate this downstream canary. No ScopeWeave product mutation is appropriate for this defect.

Correction to the fresh Noema downstream canary: the attempted source.path tightening on ContextualWisdomLab/noema#495 was falsified by the full Noema contract and has been non-destructively reverted. Do NOT use that discarded hypothesis as owner acceptance evidence.

Exact Noema evidence:

protected consumer base: main@2c83355529447248c246805d1954f268e027d2ab
test-first experimental head: 1341098aa058c262334e135bda3e0409fcb9420e; CI run 33183287037 / job 98889711198 failed only because the new assertions expected ../package-lock.json and /tmp/package-lock.json to be rejected
candidate production head 5dbb8d7a779281c7e8e4ea0a9546e74e46bcd666 then produced the decisive full-suite contradiction: CI run 33183797692 / job 98891453867 failed 4 tests. Existing generator contracts intentionally accept canonical custom absolute input paths so retained source.path honestly identifies the file actually read; the candidate guard intercepted parent-symlink/output-path and malformed-lockfile tests before their intended boundaries.
Noema therefore restored the exact pre-experiment tree non-destructively at descendant head 21c01972860bcff5ccdc217c08b7b82dbef90a73. The correct retained-evidence contract remains lexical canonicality (normalize(path) === path), not repository-relative confinement.

This correction does not change the independent central scanner defect tracked by #1222. Protected central truth has since advanced to .github/main@e1b03eebc6dc5c85aed393e5928927c96376cf46; its security-scan.yml still gives Dependency Review and Trivy generic PR-event checkout, and the dependency-review support probe still uses curl ... || true plus HTTP 403/404 => supported=false / exit 0.

The existing canonical owner PR #897 has also advanced under its dedicated writer and is now open/Ready/mergeable at exact head 74eb5d1753cba1a48e47e9bc05940373181d7b23 with current base snapshot e1b03eebc6dc5c85aed393e5928927c96376cf46. Continue that owner path; do not create a Noema leaf workaround.

Post-integration Noema acceptance remains unchanged: on an unchanged then-current Noema head, require Dependency Review and every head-oriented Security job to attest the exact submitted head plus independently resolved live protected base; transport failure/non-200 comparison must remain non-passing. Preserve severity thresholds, immutable pins and least privilege.

Fresh ScopeWeave downstream canary confirms the remaining Security Scan exact-head defect on a current mergeable PR while the sibling SAST repair is now working.

Affected consumer: ContextualWisdomLab/scopeweave#610

protected live base: develop@2c328875e00e86537df3e965170be80532571cad
exact submitted head: 3bb2bd95905d590fe3d1d0d9a8fc6c6ec133c04a
GitHub synthetic merge: 4e62fd8e2df98583bc1e640d8cd3669ad4c19479
Security Scan run: 33180751029
Trivy filesystem job: 98881032762

Exact runtime evidence from that Trivy job: its generic Checkout step supplied no submitted-head ref; actions/checkout fetched +4e62fd8e2df98583bc1e640d8cd3669ad4c19479:refs/remotes/pull/610/merge, checked out refs/remotes/pull/610/merge, and logged HEAD is now at 4e62fd8 Merge 3bb2bd95905d590fe3d1d0d9a8fc6c6ec133c04a into 2c328875e00e86537df3e965170be80532571cad. Trivy then scanned . and the job concluded GitHub success with zero CRITICAL/HIGH/MEDIUM findings. That success is evidence for the synthetic merge tree, not exact submitted head 3bb2bd..., so it remains non-passing for ScopeWeave merge acceptance.

Working-path comparison in the same consumer/current head: SAST Semgrep run 33180750999, job 98881032224, now executes Checkout exact submitted revision followed by Verify exact submitted revision and concludes success. This demonstrates the central SAST exact-head repair is deployed and gives the Security Scan owner path a concrete compatible pattern.

Causal owner remains the reusable Security Scan workflow, not ScopeWeave source. Keep the existing owner path for this issue/its canonical Security Scan PR; do not create a consumer-local duplicate. RED acceptance is the current Trivy run above where git rev-parse HEAD != pull_request.head.sha yet the scanner succeeds. GREEN requires the head-oriented Trivy path (and any other generic head-oriented Security Scan checkout such as dependency-review/Scorecard where applicable) to bind the immutable submitted PR head, verify the actual checkout before scanning, and bind resulting evidence to that identity. Preserve current immutable pins, severity thresholds, least privilege, cancellation and fail-closed behavior. After normal central integration, regenerate the then-current unchanged/successor ScopeWeave #610 Security Scan canary and require machine evidence git rev-parse HEAD == pull_request.head.sha; do not grandfather run 33180751029.

Fresh Inkspan release-lane canary narrows #1222 to a partial central repair state; no Inkspan-local checkout workaround is correct.

Affected consumer: ContextualWisdomLab/inkspan#389

protected base: main@128a239f8b71ca16add4b9e15e21752d1ad63ff0
exact submitted head: 4b02834fd56a676589afd6b57516da44f8f984be
synthetic merge for the PR: fe0096342f511e99c56c225f7b6ec7e19565ae27

SAST is now GREEN for the exact-head half of #1222. SAST Semgrep run 33170544299, job 98846340306, explicitly checked out 4b02834fd56a676589afd6b57516da44f8f984be, verified git rev-parse HEAD against that exact SHA, logged the exact repository/SHA identity, scanned the submitted tree, and uploaded SARIF with refs/pull/389/head / SHA 4b02834…. This is current downstream evidence that the SAST synthetic-merge defect has been repaired; predecessor SAST failures must not be carried forward.

Security Scan is still RED for the head-oriented half. Security Scan run 33170544304, Trivy job 98846339660, performed the default checkout of refs/pull/389/merge, materialized fe0096342f511e99c56c225f7b6ec7e19565ae27 (Merge 4b02834… into 128a239…), then scanned scan-ref: .. Its zero-finding result is therefore synthetic-merge evidence and cannot satisfy exact-head acceptance. The same Security run's dependency-review job 98846339820 also used the synthetic merge checkout; its immutable base/head API inputs were correct, but HTTP 403 was normalized to a successful support skip and the pinned Dependency Review action never ran, which remains separately owned by #810.

First causal boundary for the remaining #1222 scope is the central security-scan.yml head-oriented checkout, not Inkspan source. The existing central source writer carrying that correction is #897, currently Ready/open/mergeable at exact head 74eb5d1753cba1a48e47e9bc05940373181d7b23 against protected .github/main@e1b03eebc6dc5c85aed393e5928927c96376cf46; its Security Scan current-head evidence attests exact Trivy/Dependency Review source identity. Do not duplicate that writer or transfer its predecessor evidence.

Post-integration GREEN for #1222: rerun unchanged/current-successor Inkspan #389 and require every head-oriented central Security job to attest git rev-parse HEAD == pull_request.head.sha == 4b02834… (or the then-current successor), while comparison jobs label immutable base and head separately; preserve severity thresholds, SARIF attribution, least privilege, immutable pins, and fail-closed behavior. Keep #1222 open until that downstream Security canary passes; SAST alone is no longer the blocker.

Fresh Inkspan #379 successor canary after an unrelated local performance-test repair confirms the Trivy half of the exact-source defect remains live on the current contributor head; no leaf workaround is correct.

Affected consumer: ContextualWisdomLab/inkspan#379

independently resolved protected base: main@128a239f8b71ca16add4b9e15e21752d1ad63ff0
exact contributor head: e6659b2892774fb4a36fa1803b79e3e4eb7cedf3
Security Scan run: 33228031719
Trivy job: 99035455615
GitHub synthetic merge: 14f58116b657bfcd1d756d4b85f3f9f3f50ed4c1

Exact log reproduction: actions/checkout fetched +14f58116...:refs/remotes/pull/379/merge, checked out refs/remotes/pull/379/merge, and logged HEAD is now at 14f5811 Merge e6659b2... into 128a239.... The Trivy action then ran scan-type: fs, scan-ref: . against that synthetic workspace and reported 0 CRITICAL/HIGH/MEDIUM findings. The job/workflow are terminal success, but they are non-passing as exact-current-head evidence because the scanned tree is not submitted head e6659b2....

Contrast: the organization Semgrep exact-head lane has already progressed through merged #941, while the current central Security/Dependency repair owner #897 remains open at exact head 74eb5d1753cba1a48e47e9bc05940373181d7b23 and includes exact-head Trivy/Dependency identity work. #897 is not currently governance-clean for integration: its current-head OpenCode verdict is CHANGES_REQUESTED because required Strix failed, and no qualifying independent approval exists. Do not bypass those gates or create an Inkspan-local competing scanner.

First causal boundary remains the organization-owned reusable Security Scan checkout: head-oriented Trivy inherits GitHub's pull_request synthetic merge when no explicit exact submitted-head binding/attestation is active on protected central workflow. Falsifiable GREEN for this Inkspan canary: after the existing central repair is normally integrated, rerun an unchanged/successor #379 exact head and require the Trivy checkout/runtime attestation to equal the submitted contributor SHA, with SARIF/evidence bound to that repository/head; synthetic merge 14f58116... and this run's zero-finding result must not be grandfathered.

Fresh downstream canary confirms the remaining central Security Scan exact-head defect on the current ScopeWeave #523 contributor revision; no ScopeWeave source mutation is correct for this boundary.

ContextualWisdomLab/scopeweave#523

protected live base: develop@2c328875e00e86537df3e965170be80532571cad
exact contributor head: 135117e0594939240e787a161574b6fb4e10f155
GitHub synthetic merge: 7f133dc301c9a2f86bd3a0f0c273ef676bf18e6a
central Security Scan run: 33148083432
Trivy job: 98773498227

The Trivy job's fresh log shows actions/checkout received no explicit ref, fetched +7f133dc301c9a2f86bd3a0f0c273ef676bf18e6a:refs/remotes/pull/523/merge, checked out that merge ref, and logged HEAD is now at 7f133dc Merge 135117e0594939240e787a161574b6fb4e10f155 into 2c328875e00e86537df3e965170be80532571cad. Trivy then scanned scan-ref: . and reported zero CRITICAL/HIGH/MEDIUM findings. The job is GitHub-success but remains non-authoritative exact-current-head evidence because the scanned tree is synthetic.

The working path is already proven in this same ScopeWeave lane: repository-owned exact-head workflows explicitly bind the contributor SHA and attest the runtime checkout, so this is not a GitHub platform limitation and should not be compensated for in leaf product code.

Repair-first acceptance for the central owner path remains: add/retain a deterministic workflow-contract RED rejecting any head-oriented Security Scan checkout without the explicit target repository + immutable pull_request.head.sha; attest git rev-parse HEAD before scanning and fail closed on mismatch; preserve immutable action pins, least privilege, severity thresholds, SARIF semantics, and explicit dual-revision handling only where base/head comparison is intentional. After protected central integration, rerun the then-unchanged ScopeWeave #523 head and require the Security Scan job log/machine-readable evidence to attest the exact contributor SHA before its success can count.

Fresh Inkspan release-candidate canary separates the SAST repair from the still-open Security/Trivy identity defect on the current exact consumer; no Inkspan-local scanner workaround is correct.

Consumer: ContextualWisdomLab/inkspan#389

independently resolved protected base: main@128a239f8b71ca16add4b9e15e21752d1ad63ff0
exact contributor head: 4b02834fd56a676589afd6b57516da44f8f984be
GitHub synthetic merge: fe0096342f511e99c56c225f7b6ec7e19565ae27

Current SAST GREEN for the exact-source part of #1222 is concrete: run 33170544299, Semgrep job 98846340306, uses actions/checkout with ref: 4b02834fd56a676589afd6b57516da44f8f984be; the explicit verification step records expected_sha=4b02834... actual_sha=4b02834...; Semgrep then scans 395 tracked files, reports 0 findings, and uploads SARIF against refs/pull/389/head with SHA 4b02834.... This is valid downstream evidence that the merged SAST owner repair is active on Inkspan.

Do not close the broader exact-source lane yet: the same unchanged consumer's required Security Scan run 33170544304, Trivy job 98846339660, still materializes/scans refs/pull/389/merge at synthetic commit fe009634..., so its aggregate-green result is not exact-head release evidence. Dependency Review false-green remains separately owned by #810/#897.

Acceptance split for this canary: SAST exact-head checkout/attestation is GREEN on 4b02834...; Security/Trivy remains RED until the existing central Security owner repair reaches protected .github main and a regenerated unchanged/successor Inkspan run proves the head-oriented Trivy scan checkout equals the then-current PR head. Preserve SARIF attribution, severity thresholds, immutable pins, least privilege, and fail-closed identity checks.

Fresh ScopeWeave canary narrows #1222 after the protected SAST exact-head repair integrated.

Consumer evidence (2026-08-29): ContextualWisdomLab/scopeweave#523, exact submitted head 7779ed29f6bf8836113128c1dbf97b3e73735464, protected develop@2c328875e00e86537df3e965170be80532571cad.

SAST portion is now protected-GREEN. Required SAST run 33246179742, job 99083936246, explicitly checked out ref: 7779ed29f6bf8836113128c1dbf97b3e73735464, attested SAST_CHECKOUT ... expected_sha=7779ed29... actual_sha=7779ed29..., scanned that tree with 0 findings, and uploaded SARIF bound to refs/pull/523/head / SHA 7779ed29.... The old synthetic-merge SAST defect is therefore no longer reproduced on this canary.

Security Scan Trivy remains RED at the central owner boundary. Run 33246179728, job 99083924922, used actions/checkout with no submitted-head ref, fetched +f06f5bae...:refs/remotes/pull/523/merge, checked out synthetic merge f06f5bae286eced7b6c094aa9c5bf8f4b0ab8dfa (Merge 7779ed29... into 2c328875...), then ran trivy fs . and uploaded its SARIF. That terminal-success job therefore scanned the synthetic merge, not exact submitted head 7779ed29..., and remains non-passing exact-head evidence.

A second current-head GHAS symptom corroborates the configuration-identity problem: check 99084308863 (Trivy) is neutral with 1 configuration not found, specifically Actions workflow (trivy.yml): trivy. Fresh reads of both ScopeWeave protected develop and the current PR head return no .github/workflows/trivy.yml, so this missing analysis identity is not owned by ScopeWeave source.

Existing central repair PR #897 is still the correct owner path: it is open/Ready/mergeable at current exact head 2be8184db9f16a06570af90bce24fe2ef3627912 against current main@da49a345bba41ed163e524d7c2c8b068c638445d. Its current-head GHAS evidence itself still has neutral legacy configuration identities (scheduled-security-scan.yml:trivy-fs-scheduled and scorecard-analysis.yml:supply-chain/branch-protection), and its OpenCode check is failing, so no predecessor green or stale PR-body head should be promoted to merge authority.

GREEN acceptance for the remaining Security/Trivy lane: integrate the existing owner repair only after its exact-current-head deterministic/security/review/governance gates pass; then regenerate one unchanged/current ScopeWeave canary and require (1) runtime checkout/attestation equal to the submitted contributor SHA before Trivy scans, and (2) a stable protected-base/current-head GHAS analysis identity so the comparative Trivy check is substantive success/failure rather than neutral configuration not found. Preserve current severity thresholds, immutable pins, least privilege, SARIF publication, and fail-closed behavior; do not add a ScopeWeave-local competing scanner.

Fresh post-integration consumer evidence (2026-08-30 KST; do not close yet):

Protected central main@6c8ee24046d743b3981c566c6e29f99f09137f6a contains merged fix(security): fail closed on unavailable dependency review #897's exact-head Security Scan binding.
ScopeWeave fix(security): isolate privileged review dispatch #635 ran the central Security workflow after that integration on exact contributor head 1424dfcf009df2047a0d21130dc0bb11211f1546: https://github.com/ContextualWisdomLab/scopeweave/actions/runs/33262704542
Trivy job 99127277014 checked out and attested expected_sha=1424dfcf009df2047a0d21130dc0bb11211f1546 actual_sha=1424dfcf009df2047a0d21130dc0bb11211f1546: https://github.com/ContextualWisdomLab/scopeweave/actions/runs/33262704542/job/99127277014
Dependency Review job 99127277068 recorded the same exact-head identity and http_status=200 curl_exit=0 for base 2c328875e00e86537df3e965170be80532571cad to head 1424dfcf009df2047a0d21130dc0bb11211f1546: https://github.com/ContextualWisdomLab/scopeweave/actions/runs/33262704542/job/99127277068

This is a fresh downstream ScopeWeave GREEN for the repaired central contract. ScopeWeave #523 itself remains at exact head e28b5caba7a6f16071ead232b33d0c5d64d78b7a. I requested a rerun of its Security workflow; the new attempt has not yet produced terminal exact-head Trivy evidence, so the historical synthetic-merge scan is not treated as superseded and #1222 remains open pending the required #523-specific operational acceptance.

#1222 downstream acceptance is now complete on the required ScopeWeave canary.

Current immutable identities:

ScopeWeave fix(opencode): App 전용 review identity 계약을 통합 게이트와 일치 #523 head: e28b5caba7a6f16071ead232b33d0c5d64d78b7a
protected base: 2c328875e00e86537df3e965170be80532571cad
protected central workflow source: main@6c8ee24046d743b3981c566c6e29f99f09137f6a

Exact-head evidence:

SAST run/job 33247472709/99087356940 explicitly checked out ref: e28b5caba7a6f16071ead232b33d0c5d64d78b7a, attested expected_sha=e28b5caba7a6f16071ead232b33d0c5d64d78b7a actual_sha=e28b5caba7a6f16071ead232b33d0c5d64d78b7a, completed successfully, and uploaded the resulting Semgrep SARIF against the PR head: https://github.com/ContextualWisdomLab/scopeweave/actions/runs/33247472709/job/99087356940
The post-integration Security rerun's Trivy job 99167410453 explicitly checked out and attested the same exact head, completed successfully, and reported zero CRITICAL/HIGH/MEDIUM findings: https://github.com/ContextualWisdomLab/scopeweave/actions/runs/33247472787/job/99167410453
The same current-head Security evidence retains OSV's explicitly labeled immutable base/head materialization. Dependency Review remains an explicit base/head comparison; the fresh post-integration ScopeWeave fix(security): isolate privileged review dispatch #635 Security run independently attested its exact head and HTTP 200/curl 0 comparison, as recorded above.

No severity threshold, permission, immutable pin, cancellation rule, SARIF association, or fail-closed behavior was weakened. This is downstream operational evidence rather than source-merge-only evidence, so the acceptance criteria are satisfied and the issue can close as completed.

Navigation Menu

Repository navigation

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

Problem

Responsibility boundary

Required design

Acceptance criteria

Downstream dependency

Current exact evidence (2026-08-23 KST)

First failing boundary / root cause hypothesis

RED acceptance test

Smallest causal remedy

Required GREEN consumer evidence

114 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Problem

Responsibility boundary

Required design

Acceptance criteria

Downstream dependency

Activity

seonghobae commented on Aug 22, 2026

seonghobae commented on Aug 22, 2026

seonghobae commented on Aug 22, 2026

seonghobae commented on Aug 22, 2026

seonghobae commented on Aug 22, 2026

Current exact evidence (2026-08-23 KST)

First failing boundary / root cause hypothesis

RED acceptance test

Smallest causal remedy

Required GREEN consumer evidence

seonghobae commented on Aug 23, 2026

seonghobae commented on Aug 23, 2026

seonghobae commented on Aug 23, 2026

114 remaining items

seonghobae commented on Aug 28, 2026

seonghobae commented on Aug 28, 2026

seonghobae commented on Aug 28, 2026

seonghobae commented on Aug 28, 2026

seonghobae commented on Aug 28, 2026

seonghobae commented on Aug 28, 2026

seonghobae commented on Aug 28, 2026

seonghobae commented on Aug 28, 2026

seonghobae commented on Aug 29, 2026

seonghobae commented on Aug 29, 2026

seonghobae commented on Aug 29, 2026

seonghobae commented on Aug 29, 2026

seonghobae commented on Aug 29, 2026

seonghobae commented on Aug 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions