feat(enrichment): detect GitHub Actions workflow-injection and pwn-request risk

[joaovictor91123]

Summary

Adds review-enrichment/src/analyzers/workflow-injection.ts, a new REES analyzer that flags the GitHub Actions "pwn request" trust-boundary pattern: a pull_request_target/workflow_run workflow (which runs with the base repo's secrets and token even for a fork PR) that checks out the untrusted PR head, interpolates untrusted event fields (PR title/body/head ref, issue/comment body) directly into a run: shell step instead of via env:, or carries no narrowed permissions: block. Registered in registry.ts/analyzer-metadata.json alongside the existing actionPin/iacMisconfig analyzers, whose shape it follows.

No issue is linked: this repo's linkedIssuePolicy is preferred, not required, and the proposal, rationale, and full test plan are self-contained in this PR. I checked for duplicates first: PR #2668 (workflowPermissions) proposed a related but narrower analyzer (permission-escalation flags and bare trigger-declaration detection) and was closed for a specific correctness bug in its trigger tracking; it never merged, so nothing in main covers this today. This PR does not overlap it — it targets the untrusted-checkout and shell-injection vectors #2668 didn't attempt — and its own trigger detection reads both added and unchanged context lines in a hunk (not just added lines gated behind seeing on: in the same hunk), which avoids the specific defect that got #2668 closed.

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked an issue, or this is small enough that the summary explains why an issue is not needed.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally; codecov/patch requires ≥99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

• npm run test:mcp-pack crashes on my local Windows dev machine with a pre-existing, unrelated ERR_INVALID_ARG_TYPE in scripts/check-mcp-package.mjs that I confirmed reproduces identically on a clean, unmodified main checkout — it is a local Node/Windows environment issue, not something this PR introduces. Likewise npm run ui:lint and part of npm run test:coverage show failures on this machine (CRLF-vs-LF noise across the whole apps/gittensory-ui tree from core.autocrlf, and ~30 shell/script-based test files that need bash/sentry-cli/docker tooling this Windows box doesn't have); I verified every one of these also fails identically on a clean main checkout, so I'm listing them as run rather than skipped, with this caveat. The new analyzer's own test suite (review-enrichment/test/workflow-injection.test.ts, run via npm run rees:test) passes in full (10/10), and the full review-enrichment suite is green apart from those same 2 pre-existing sentry-upload.test.ts failures.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests.
• API/OpenAPI/MCP behavior is updated and tested where needed.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots arranged as organized, captioned, clickable thumbnails. SVG screenshots are not used as review evidence. Review-only screenshots or recordings are not committed to the repository.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

UI Evidence

Not applicable — this PR adds a new REES analyzer (backend/enrichment logic) with an accompanying apps/gittensory-ui/src/lib/rees-analyzers.ts metadata entry, but no new visible UI surface.

Notes

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 Gittensory review result - reject/close recommended

_{Review updated: 2026-07-05 06:33:25 UTC}

12 files · 1 AI reviewer · 1 blocker · readiness 73/100 · CI pending · blocked

🛑 Suggested Action - Reject/Close

• AI reviewers agree on a likely critical defect: review-enrichment/src/analyzers/workflow-injection.ts:96 treats `PULL_REQUEST_TARGET_RE` matches on comments or arbitrary string values as an active trigger, so a changed workflow containing only `# pull_request_target` plus no visible `permissions:` will emit a `missing-permissions` finding even though the workflow has no elevated trigger
• change this to parse or at least key-match YAML trigger declarations, e.g. only accept `pull_request_target:` / `workflow_run:` under `on:` or the bracket/list trigger forms, or explain why comment/scalar matches are acceptable for this analyzer. — Resolve the flagged defect, or override if the AI reviewers are mistaken, then re-run the gate.

Review summary
This adds a new local REES analyzer and wires it through the registry, rendering, metadata, UI analyzer list, scheduler skip reasons, and engine-side analyzer-name allowlist. The integration shape matches the existing analyzer pattern, but the analyzer’s trigger detection is too broad because it treats any textual occurrence of `pull_request_target`/`workflow_run` in a visible hunk line as an active workflow trigger, including comments and unrelated scalar text. That produces reachable false-positive security findings from valid workflow patches that do not actually run under the elevated trigger.

Blockers

• review-enrichment/src/analyzers/workflow-injection.ts:96 treats `PULL_REQUEST_TARGET_RE` matches on comments or arbitrary string values as an active trigger, so a changed workflow containing only `# pull_request_target` plus no visible `permissions:` will emit a `missing-permissions` finding even though the workflow has no elevated trigger; change this to parse or at least key-match YAML trigger declarations, e.g. only accept `pull_request_target:` / `workflow_run:` under `on:` or the bracket/list trigger forms, or explain why comment/scalar matches are acceptable for this analyzer.

Nits — 6 non-blocking

• nit: review-enrichment/src/analyzers/workflow-injection.ts:98 overwrites `pullRequestTargetLine` on every later textual match, so even after trigger detection is tightened the reported `missing-permissions` location can drift away from the actual trigger line; keep the first trigger line or track the parsed trigger node.
• nit: review-enrichment/src/types.ts:119 says `missing-permissions` means no top-level `permissions:` block, but review-enrichment/src/analyzers/workflow-injection.ts:29 treats any indented job-level `permissions:` as sufficient; align the contract and render text with the implemented file-scoped behavior, or make the analyzer specifically detect top-level permissions.
• nit: review-enrichment/src/analyzers/workflow-injection.ts:95 applies `UNSAFE_TRIGGER_RE` to every visible line, so the same comment/scalar issue also gates `unsafe-interpolation` and `untrusted-checkout` findings for `workflow_run`; use the same tightened trigger detection for both trigger booleans.
• Add a regression test in review-enrichment/test/workflow-injection.test.ts with a workflow patch containing `# pull_request_target` but only a safe `pull_request` trigger, and assert that `scanPatchForWorkflowInjection` returns no findings.
• In review-enrichment/src/analyzers/workflow-injection.ts, split trigger detection into a small helper that recognizes workflow trigger syntax and returns `{ unsafe: boolean, pullRequestTargetLine?: number }`; that gives you one place to cover mapping/list/inline forms and prevents future regex drift.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

Why this is blocked

• review-enrichment/src/analyzers/workflow-injection.ts:96 treats `PULL_REQUEST_TARGET_RE` matches on comments or arbitrary string values as an active trigger, so a changed workflow containing only `# pull_request_target` plus no visible `permissions:` will emit a `missing-permissions` finding even though the workflow has no elevated trigger; change this to parse or at least key-match YAML trigger declarations, e.g. only accept `pull_request_target:` / `workflow_run:` under `on:` or the bracket/list trigger forms, or explain why comment/scalar matches are acceptable for this analyzer.

Signal	Result	Evidence
Code review	❌ 1 blocker	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	❌ 5/25	Preflight is holding this PR: the review lane is unavailable, so it is not ready for automated review.
Contributor workload	✅ 10/10	Author activity: 108 registered-repo PR(s), 61 merged, 8 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	joaovictor91123; Gittensor profile; 108 PR(s), 8 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: joaovictor91123
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 108 PR(s), 8 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Explain no-issue PR.
• Await review-lane availability.
• Refresh registry data or choose a registered active repo.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[loopover-orb]

Gittensory is closing this pull request on the maintainer's behalf (AI reviewers agree on a likely critical defect: review-enrichment/src/analyzers/workflow-injection.ts:96 treats `PULL_REQUEST_TARGET_RE` matches on comments or arbitrary string values as an active trigger, so a changed workflow containing only `# pull_request_target` plus no visible `permissions:` will emit a `missing-permissions` finding even though the workflow has no elevated trigger; change this to parse or at least key-match YAML trigger declarations, e.g. only accept `pull_request_target:` / `workflow_run:` under `on:` or the bracket/list trigger forms, or explain why comment/scalar matches are acceptable for this analyzer.). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.46%. Comparing base (4dc106e) to head (fbf19cd).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3410   +/-   ##
=======================================
  Coverage   93.46%   93.46%           
=======================================
  Files         289      289           
  Lines       30784    30784           
  Branches    11220    11220           
=======================================
  Hits        28773    28773           
  Misses       1355     1355           
  Partials      656      656           

Files with missing lines	Coverage Δ
src/review/enrichment-analyzer-names.ts	100.00% <ø> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.