ci: scan issue and comment bodies — this repo has never scanned one

[yakimoto]

This repo's public-repo-guard has never scanned a single issue or comment body.

Measured across all 28 public wave-av repos (wave-av/claude-workstation#1747, #1794): two coverage shapes satisfy the one required check name Secrets + content policy.

repos	triggers	jobs
27	pull_request, push, workflow_dispatch	guard
1	+ issues, issue_comment	+ body-guard

This repo is in the 27. All 28 report the same green check — because a required check asserts that something named X passed, never what X examined.

The outlier is wave-moq-edge, and its own comment says why it matters:

edited matters as much as opened: a body can be made to leak long after the PR is first raised, and until this workflow covered it, nothing ever re-scanned.

That gap was not theoretical there: a PR was blocked for naming a private repo in wrangler.toml while the very same name, with more operational detail attached, sat unchallenged in its body.

What lands

Three files — the bundle the workflow's own header names, minus what this repo already has (.gitleaks.toml and content-policy.sh are already vendored, and are checked as prerequisites; a repo missing either is refused rather than half-installed):

.github/workflows/public-repo-guard.yml               replaced (72 -> 163 lines)
scripts/public-repo-guard/body-policy.sh              new, mode 100755
scripts/public-repo-guard/tests/body-policy.test.sh   new, mode 100755

The workflow's header names four files as the install unit but executes a fifth — tests/body-policy.test.sh, in its own self-test step. Omitting it installs a workflow that fails on a step nobody read, so the manifest ships it. Modes are preserved via the git trees API; the contents API creates 100644 regardless, which would silently break running these scripts as executables.

Planned by governance/lib/vendor-bundle.mjs (claude-workstation#1850) against a checked-in manifest, not by ad-hoc shell.

One deliberate divergence from the reference, stated rather than silent

The shipped workflow is wave-moq-edge's with actions/checkout bumped from v5.0.1 to v7.0.1 (3d3c42e5aac5ba805825da76410c181273ba90b1), the pin already used by claude-workstation's own gate.

Copying verbatim was checked first and rejected on evidence: of the 18 target repos, 17 carry a byte-identical guard, and wave-realtime-edge already runs v7.0.0 — so a verbatim copy would have downgraded it, and shipped a stale pin to the other 17. A separate PR brings the reference itself up to the same pin.

Honest about what this can and cannot do

On a PR this PREVENTS the merge. On an issue or comment the text is already public the moment it posts, so this is DETECTION: it says go redact, fast. Only a client-side pre-write hook stops that class before publication.

Also inherited from the reference: concurrency moves from workflow-level to per job, because the two jobs want opposite behaviour. A workflow-level group forced one policy on both, and rapid body edits cancelled the tree job repeatedly — every cancelled check-run stays attached to the commit, so the PR reported UNSTABLE while the live runs were green.

The body gate ships with its own fixtures and runs them in CI. Its negative cases are the load-bearing half: a leak gate that blocks legitimate cross-repo references gets switched off, and then it protects nothing.

Refs wave-av/claude-workstation#1747.

---

---

Note

Medium Risk
Changes security CI behavior (new required-style checks, fail-closed scanner deps, and merge-blocking body rules); misconfiguration of GUARD_PRIVATE_REPOS or missing PCRE2 rg can block merges, but scope is limited to the guard workflow and vendored scripts.

Overview
Extends public-repo-guard so world-readable titles and bodies (PRs, issues, comments, and review text—not only the checked-in tree) are scanned in CI, closing a gap where tree policy could block a file while the same leak sat in the PR body.

The workflow is replaced and expanded: new triggers include edited on PRs/issues/comments/reviews, plus issues, issue_comment, pull_request_review, and pull_request_review_comment. guard still runs gitleaks + content-policy.sh on the tree but with per-job concurrency (tree group can cancel in-flight runs on new pushes/edits) and actions/checkout v7.0.1. It installs PCRE2-capable, pinned ripgrep (Ubuntu apt rg breaks -P rules), runs body-policy.test.sh as a self-test, and no longer runs on pure issue/comment-only events (review events still re-run the tree so a skipped check cannot mask a failing scan).

A new body-guard job materializes untrusted text from the event payload via jq into a file (no shell interpolation), sparse-checkouts only scripts/public-repo-guard, and runs body-policy.sh. Body concurrency keys on comment/review/issue/PR id with cancel-in-progress: false so every edit gets a completed verdict.

body-policy.sh mirrors many tree leak classes (credentials, CF account_id, Tailscale IPs, operator paths) with redacted annotations, guard:allow, and prose rules that exempt discussion of the gate itself. Private-repo handling differs from the tree: bare cross-repo references are allowed; blocking requires a configured private repo name within ~140 chars of operational detail (credential names, secret bindings, secret counts). GUARD_PRIVATE_REPOS unset in CI fails closed.

tests/body-policy.test.sh adds fixture tests for positives, precision negatives, and fail-closed paths.

^{Reviewed by Cursor Bugbot for commit 7e086ee. Configure here.}

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled.}

Note

Scan PR/issue/comment/review bodies for credential and infrastructure leaks in CI

• Adds body-policy.sh, a new Bash scanner that checks materialized PR/issue/comment/review text for credential formats (Stripe, Anthropic, GitHub PATs, AWS keys, PEM headers) and private repo name proximity to operational keywords.
• Adds a new body-guard CI job in public-repo-guard.yml triggered by issues, issue_comment, pull_request_review, and pull_request_review_comment events, with per-event concurrency keyed to the most specific object ID.
• Expands the existing guard job triggers to include review events and body-policy fixture tests; adds PCRE2-capable ripgrep installation to prevent false scanner failures.
• Adds body-policy.test.sh covering must-block, must-pass, and fail-closed fixture cases.
• Risk: the scanner fails closed (exit 2) when GUARD_PRIVATE_REPOS is unset in CI or when a non-PCRE2 rg is detected, blocking the check run.

^{Macroscope summarized c284c89.}

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🚫 Excluded labels (none allowed) (1)

• rr:skip-coderabbit

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: b3ad6b72-3689-476c-8230-754457300ef0

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_31b04dac-ddcf-4755-b62e-bd5e19d92c8d)

[macroscopeapp]

Approvability

Verdict: Needs human review

Unable to check for correctness in c284c89. This PR introduces a new security scanning capability with significant workflow changes. An unresolved review comment identifies a potential security bypass where a malicious PR could modify the scanner script to defeat the control. Human review is needed to address this concern.

^{You can customize Macroscope's approvability policy. Learn more.}

[qodo-code-review]

PR Summary by Qodo

CI: scan issue/PR/comment bodies in public-repo-guard (with fixtures + safe concurrency)

✨ Enhancement ⚙️ Configuration changes 🧪 Tests 🕐 40+ Minutes

AI Description

• Add a dedicated body-scanning job for PR/issue/comment text, including edited events.
• Introduce a fail-closed body policy script with allowlists and redacted reporting.
• Add fixture-only self-tests and per-job concurrency to prevent unstable/cancelled checks.

Diagram

graph TD
  E(["GitHub events\nPR / issues / comments"]) --> W["public-repo-guard workflow"] --> J1["Job: guard (tree)"] --> S1["content-policy.sh"]
  W --> J2["Job: body-guard"] --> M["Materialize body.txt"] --> S2["body-policy.sh"]
  J1 --> T["body-policy fixtures"]
  subgraph Legend
    direction LR
    _evt(["Event"]) ~~~ _job["Workflow/Job"] ~~~ _file["Script/Test"]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use GitHub Advanced Security secret scanning / push protection

• ➕ Native detection with fewer custom regexes to maintain
• ➕ Integrates well with GitHub UX (alerts, remediation, history)
• ➖ Requires GHAS licensing/enablement; not always available for public repos/org policy
• ➖ Doesn’t directly cover custom “private repo + ops detail” proximity rules

2. Single job with a matrix for tree vs body scans

• ➕ Less duplicated workflow boilerplate
• ➕ Easier to keep versions/pins aligned
• ➖ Harder to express different concurrency policies (cancel vs don’t-cancel) cleanly
• ➖ Higher risk of accidentally paying for full checkouts on comment events

3. Webhook-based scanner (external service)

• ➕ Can scan and alert immediately, independent of GitHub Actions runner availability
• ➕ Centralized rules management across many repos
• ➖ Adds operational burden (service hosting, auth, rate limits)
• ➖ More complex security surface than an in-repo workflow

Recommendation: Keep the PR’s approach: a dedicated in-workflow body scan job with event-shape validation, sparse checkout, and non-cancelling concurrency is a pragmatic, low-ops way to close a real visibility gap without granting elevated permissions. Native secret scanning is worth considering where GHAS is available, but it won’t fully replace the custom policy constraints and org-variable-driven private repo proximity logic implemented here.

Files changed (3) +342 / -5

Enhancement (1) +139 / -0

body-policy.shNew body policy scanner with redacted reporting and proximity-based private-repo rule +139/-0

New body policy scanner with redacted reporting and proximity-based private-repo rule

• Adds a fail-closed ripgrep-based scanner for PR/issue/comment text stored in a file, with line-level allowlisting and an allowlist for security/control discussions. Implements blocking rules for credential formats and infrastructure identifiers, plus a proximity rule that flags private repo names only when near operational detail (fed by GUARD_PRIVATE_REPOS). Outputs annotations that never echo matched secret text (line numbers only).

scripts/public-repo-guard/body-policy.sh

Tests (1) +108 / -0

body-policy.test.shAdd fixture-only tests to validate body-policy precision and fail-closed behavior +108/-0

Add fixture-only tests to validate body-policy precision and fail-closed behavior

• Introduces hermetic fixture tests that assert both blocking detections and critical non-blocking cases (to prevent the gate being disabled due to false positives). Verifies annotations do not reprint matched text and exercises fail-closed paths (missing/invalid input). Avoids embedding credential-shaped literals in source by assembling sensitive-looking fixtures at runtime.

scripts/public-repo-guard/tests/body-policy.test.sh

Other (1) +95 / -5

public-repo-guard.ymlAdd body-guard job and event coverage; split per-job concurrency +95/-5

Add body-guard job and event coverage; split per-job concurrency

• Extends triggers to include issues and issue comments (including edited events) and adds a new "Body content policy" job that scans materialized title/body text from the event payload. Introduces per-job concurrency policies so tree scans can cancel on updates while body scans keep all versions, avoiding lingering cancelled check-runs. Updates actions/checkout pin to v7.0.1 and adds a fixtures self-test step for the body policy.

.github/workflows/public-repo-guard.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. PR-controlled body scanner 🐞 Bug ⛨ Security

Description

The body-guard job runs on pull_request events but checks out repo code without pinning to a trusted
base revision, then executes scripts from that checkout; a malicious PR can modify body-policy.sh to
always pass (or change behavior) and defeat the new body leak gate.

Code

.github/workflows/public-repo-guard.yml[R128-131]

+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
+        with:
+          # Only the gate's own scripts are needed — no reason to pay for the whole
+          # tree on every comment.

Evidence

The workflow explicitly runs body-guard on pull_request and then checks out the repo and runs
body-policy.sh from that checkout. Because the checkout step does not specify a trusted ref, the
script source can be influenced by the PR itself during pull_request runs, enabling bypass by
editing the scanner in the PR.

.github/workflows/public-repo-guard.yml[113-163]
scripts/public-repo-guard/body-policy.sh[12-28]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`body-guard` runs on `pull_request` events but executes `scripts/public-repo-guard/body-policy.sh` from the checked-out repository contents. With `actions/checkout` not pinned to a trusted ref, a PR can change `body-policy.sh` in the same PR and make the body scan always pass, defeating the purpose of the new control.

### Issue Context
The workflow already has the untrusted body content in `$GITHUB_EVENT_PATH`; the only reason to checkout is to obtain the scanner scripts. For `pull_request` events, those scripts should come from a trusted source (base branch/commit), not from the PR.

### Fix Focus Areas
- .github/workflows/public-repo-guard.yml[113-163]

### Implementation notes
- In `body-guard`, set the checkout `ref` to a trusted base revision when `github.event_name == 'pull_request'` (e.g. `${{ github.event.pull_request.base.sha }}`), and otherwise to the default branch/`github.ref` for issue/comment events.
- Keep the sparse checkout, but ensure it pulls from the trusted ref.
- Optionally set `persist-credentials: false` since the job doesn’t need git auth after checkout.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context used

Review mode: ⚖️ Balanced: Downgraded extended -> standard: change is below the extended eligibility bar (hunks 5/18, lines 347/200; both must reach the floor). Router rationale: This adds security-sensitive CI behavior plus substantial shell policy logic, workflow event/concurrency paths, and fixture coverage across multiple independent edit sites where subtle failures are easy to miss.

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[qodo-code-review]

1. Pr-controlled body scanner 🐞 Bug ⛨ Security

The body-guard job runs on pull_request events but checks out repo code without pinning to a trusted
base revision, then executes scripts from that checkout; a malicious PR can modify body-policy.sh to
always pass (or change behavior) and defeat the new body leak gate.

Agent Prompt

### Issue description
`body-guard` runs on `pull_request` events but executes `scripts/public-repo-guard/body-policy.sh` from the checked-out repository contents. With `actions/checkout` not pinned to a trusted ref, a PR can change `body-policy.sh` in the same PR and make the body scan always pass, defeating the purpose of the new control.

### Issue Context
The workflow already has the untrusted body content in `$GITHUB_EVENT_PATH`; the only reason to checkout is to obtain the scanner scripts. For `pull_request` events, those scripts should come from a trusted source (base branch/commit), not from the PR.

### Fix Focus Areas
- .github/workflows/public-repo-guard.yml[113-163]

### Implementation notes
- In `body-guard`, set the checkout `ref` to a trusted base revision when `github.event_name == 'pull_request'` (e.g. `${{ github.event.pull_request.base.sha }}`), and otherwise to the default branch/`github.ref` for issue/comment events.
- Keep the sparse checkout, but ensure it pulls from the trusted ref.
- Optionally set `persist-credentials: false` since the job doesn’t need git auth after checkout.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

Qodo Fixer

✅ Merged (0) · ☑ Fixed (0)

Process

• No fixes were applied (no_fixes_applied)

[devin-ai-integration]

Devin Review found 2 new potential issues.

[devin-ai-integration]

📝 Info: Findings on issue/comment bodies land on the default branch, not the PR

For issues and issue_comment events GitHub runs the workflow in the default-branch context, so a failing body-guard run for those events produces a check run on main's head commit rather than anywhere visible on the PR. The job comment already frames this as detection-only, but it is worth noting that nobody is notified unless someone watches the Actions tab — a failure notification/alert path (or an org-level required review) would make the detection actionable.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_86adf5e8-be25-4e09-b0ce-5d6efff24718)

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🔍 Review-event tree scan may check out the base/default branch, not the PR head

The guard job now runs the full tree scan for pull_request_review and pull_request_review_comment events (.github/workflows/public-repo-guard.yml:82-88). The extensive comment at lines 68-77 asserts these events "run in the PR's context and publish a check run on the PR HEAD SHA." For GitHub pull_request_review / pull_request_review_comment events, github.sha/github.ref conventionally resolve to the repository's default branch rather than the PR head, so actions/checkout (line 94, no explicit ref) would scan the default branch tree and publish the check run against the default-branch commit — not the PR head. If that is the case, the review-event re-scan does not actually re-verify the PR head, and the concurrency reasoning (a review event superseding an in-flight PR-head tree scan under cancel-in-progress: true, line 91) could cancel the PR-head scan without landing an equivalent PR-head verdict. Worth verifying the actual github.sha semantics for these event types against current GitHub behavior before relying on this gate.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[blacksmith-sh]

GitHub's events-that-trigger-workflows reference documents GITHUB_REF for both pull_request_review and pull_request_review_comment as the PR merge branch refs/pull/N/merge (GITHUB_SHA = last merge commit on it), not the default branch, so the unqualified checkout scans the PR merge result exactly as the workflow comment states. The default-branch semantics this finding assumes apply to issue_comment/issues events, and the stale-merge-ref safeguards already landed on this PR rely on the same documented merge-ref behavior.