Repository navigation
fix(ci): repin Security Scan to the panic-attack workflow that builds the scanner - #491
Conversation
… the scanner The pinned scan-and-report.yml at be6ac46 builds the caller repository, not the scanner. An external caller therefore has no panic-attack binary and fails at "Run scan" with exit 127 (hyperpolymath/panic-attack#276). 55ffcc9 is panic-attack main. It fetches the scanner source at the commit of the called workflow, builds it outside the workspace and scans the caller with that binary. actions.lock is not changed here. It is tool-owned, and the official refresh candidate comes from the Workflow Security Linter. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0136P7ZmAsYpFA9gxfQLF3F6 Signed-off-by: Claude <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 36 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
|
This security review couldn’t start because the paying account has exhausted its Codex allowance and has insufficient available credits. The payer can check their balance and add credits in the Codex usage dashboard, then try again. If you do not manage the paying account, contact this repository's admins. |
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bf00d05348
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| jobs: | ||
| scan: | ||
| uses: hyperpolymath/panic-attack/.github/workflows/scan-and-report.yml@be6ac46716eaf049570ec4966f4ae4699b319689 # main 2026-10-20: dtolnay/rust-toolchain v1 at 683b588 (the b689a74 pin was a commit no tag names any more) | ||
| uses: hyperpolymath/panic-attack/.github/workflows/scan-and-report.yml@55ffcc9a240e937edd968487af15ab45c6f0522f # main 2026-11-10: builds the scanner at the workflow commit, not the caller (panic-attack#276) |
There was a problem hiding this comment.
The target tree still maps .github/workflows/security-scan.yml to hyperpolymath/panic-attack@be6ac467... in .github/workflows/actions.lock (lines 86–87), while this line now uses 55ffcc9.... The repository's canonical governance lockfile verification checks managed reusable workflows against that index, so this commit makes the Actions lockfile check fail until the generated lock update is committed alongside the pin.
Useful? React with 👍 / 👎.
Applied without edits from the "Prepare official actions.lock refresh candidate" step of run 42897428598 on 18828c3 (close-lock: 0 dangling refs; check-lock-sync: in sync). It restores the reusable-workflow records that #495 removed, for the 8 job-level reusable calls, with their transitive actions. #495 removed them as stale, but the governance gate accepts them: its verifier (standards a797d30, scripts/update-actions-lock.sh) accepts a stale finding when the workflow calls that exact owner/repo/...@ref. The failure #495 fixed was one record (security-scan.yml at panic-attack be6ac46, after #491 moved the call to 55ffcc9). With this commit the committed lock matches what the standards refresh tool writes, so a refresh no longer shows a diff. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0136P7ZmAsYpFA9gxfQLF3F6
## Summary The Workflow Security Linter refresh and the committed `actions.lock` produced different locks. This PR makes them agree, using the form the owner chose: the form that the standards refresh tool writes. The candidate is applied without edits, from the "Prepare official actions.lock refresh candidate" step of run 42897428598 on `18828c3`. That run reports `close-lock: 0 dangling refs`, `prune-stale: oracle vetoes 0` and `actions.lock is in sync`. It restores the reusable-workflow records that #495 removed: 8 job-level reusable calls, with their transitive actions. ## Why this is safe for governance #495 removed these records as stale. The governance gate accepts them, however. Its verifier (standards `a797d30`, `scripts/update-actions-lock.sh`, `verify_lock_coverage`) accepts a `stale` finding when the workflow calls that exact `owner/repo/.github/workflows/…@ref`. The governance log on `d98b0e2` shows that 7 of the 8 records were accepted. It rejected only 1: `security-scan.yml → panic-attack@be6ac46`, which was stale because #491 had moved the call to `55ffcc9`. This form passed governance on `453fe3b` (#496). The refresh run above printed the same "Accepted reusable-workflow lock coverage" line for each of the 8 current calls. ## Correction #500 said that applying this candidate would turn governance red. That was wrong, for the reason above. ## Test plan - [ ] governance / Actions lockfile verify passes on this head. --- _Generated by [Claude Code](https://claude.ai/code/session_0136P7ZmAsYpFA9gxfQLF3F6)_ Co-authored-by: Claude <noreply@anthropic.com>
Summary
security-scan.ymlcallshyperpolymath/panic-attack/.github/workflows/scan-and-report.ymlatbe6ac46. That commit builds the caller repository, not the scanner. An external caller therefore has nopanic-attackbinary and fails atRun scanwith exit 127 (hyperpolymath/panic-attack#276).This PR moves the pin to
55ffcc9a240e937edd968487af15ab45c6f0522f, which is panic-attackmain. That commit fetches the scanner source at the commit of the called workflow, builds it outside the workspace and scans the caller with that binary.The first run of
Security Scanonmainafter the merge is the external-caller proof for hyperpolymath/panic-attack#276.Changes
.github/workflows/security-scan.yml: theuses:pin moves frombe6ac46to55ffcc9. The trailing comment names the reason..github/workflows/actions.lock: not changed by hand. The file is tool-owned. The official refresh candidate comes from thePrepare official actions.lock refresh candidatestep of the Workflow Security Linter, and a second commit applies that candidate without edits.RSR Quality Checklist
Required
just testor equivalent): not applicable, no code changes. The hosted workflow policy check is the test.unsafeblocks without// SAFETY:comments.envfiles includedAs Applicable
Testing
git ls-remoteshows that55ffcc9a240e937edd968487af15ab45c6f0522fisrefs/heads/mainof panic-attack.scripts/ci/test-issue-regressions.shdid not run locally: it needs mikefarahyqv4, which is not in this session. The hostedWorkflow Security Linterruns it.Security Scandoes not run onpull_request. Its triggers arepushtomain, the weekly schedule andworkflow_dispatch. This PR therefore cannot show a hosted Security Scan run before the merge.Known limit: in panic-attack, the
Send to verisimdb-datastep fails with HTTP 401 because theVERISIMDB_PATsecret there is not valid. If the echidna secret has the same state, the scan steps pass and that last step fails. That is a secret to replace, not a defect of this pin.Screenshots
Not applicable.
Generated by Claude Code