Summary
Raised by Devin review on #1221 (analysis severity, not blocking that PR's own scope): both trusted-verifier checkout steps in `.github/workflows/exact-artifact-sbom-attestation.yml` (`verify-evidence-artifact` and `attest-exact-artifacts` jobs) pin:
```yaml
repository: ContextualWisdomLab/.github
ref: ${{ github.workflow_sha }}
```
Inside a `workflow_call` target, `github.workflow_sha` reflects the top-level calling workflow's commit, not this reusable workflow's own pinned commit (same root class of issue as #1212/#1221, just a different file). The workflow already accepts explicit `source_repository`/`source_sha` inputs and a same-repo runtime check (`test "$SOURCE_REPOSITORY" = "$GITHUB_REPOSITORY"`), implying cross-repo callers are an intended future use case — for those, `github.workflow_sha` would silently resolve to the wrong commit.
No callers currently exist (confirmed via `grep -rln "uses:.*exact-artifact-sbom-attestation.yml"` across all workflow files — zero matches), so there is no live production impact today.
Why not fixed alongside #1221
The correct fix isn't a same-repo swap to `github.repository` (unlike #1221's `pr-review-fix-scheduler.yml` case, which only has same-repo local `uses: ./...` callers) — this workflow is explicitly designed for potential cross-repo use, so getting "this reusable workflow's own pinned commit" right requires resolving it from the OIDC `job_workflow_ref` claim (the only context GitHub exposes for a called reusable workflow's own identity), which needs an OIDC token exchange + JWT claim parsing not currently present in the `verify-evidence-artifact` job (it only has `actions: read, contents: read`, no `id-token: write`). That's a real design/implementation task on a security-relevant attestation boundary, not a one-line swap — flagging for dedicated review rather than rushing it into an unrelated PR.
Suggested next step
When a real caller is added for this reusable workflow, resolve the trusted-verifier checkout ref via the OIDC `job_workflow_ref` claim (requires adding `id-token: write` to `verify-evidence-artifact` and parsing the claim), not `github.workflow_sha`.
Summary
Raised by Devin review on #1221 (analysis severity, not blocking that PR's own scope): both trusted-verifier checkout steps in `.github/workflows/exact-artifact-sbom-attestation.yml` (`verify-evidence-artifact` and `attest-exact-artifacts` jobs) pin:
```yaml
repository: ContextualWisdomLab/.github
ref: ${{ github.workflow_sha }}
```
Inside a `workflow_call` target, `github.workflow_sha` reflects the top-level calling workflow's commit, not this reusable workflow's own pinned commit (same root class of issue as #1212/#1221, just a different file). The workflow already accepts explicit `source_repository`/`source_sha` inputs and a same-repo runtime check (`test "$SOURCE_REPOSITORY" = "$GITHUB_REPOSITORY"`), implying cross-repo callers are an intended future use case — for those, `github.workflow_sha` would silently resolve to the wrong commit.
No callers currently exist (confirmed via `grep -rln "uses:.*exact-artifact-sbom-attestation.yml"` across all workflow files — zero matches), so there is no live production impact today.
Why not fixed alongside #1221
The correct fix isn't a same-repo swap to `github.repository` (unlike #1221's `pr-review-fix-scheduler.yml` case, which only has same-repo local `uses: ./...` callers) — this workflow is explicitly designed for potential cross-repo use, so getting "this reusable workflow's own pinned commit" right requires resolving it from the OIDC `job_workflow_ref` claim (the only context GitHub exposes for a called reusable workflow's own identity), which needs an OIDC token exchange + JWT claim parsing not currently present in the `verify-evidence-artifact` job (it only has `actions: read, contents: read`, no `id-token: write`). That's a real design/implementation task on a security-relevant attestation boundary, not a one-line swap — flagging for dedicated review rather than rushing it into an unrelated PR.
Suggested next step
When a real caller is added for this reusable workflow, resolve the trusted-verifier checkout ref via the OIDC `job_workflow_ref` claim (requires adding `id-token: write` to `verify-evidence-artifact` and parsing the claim), not `github.workflow_sha`.