feat(actions): add the threatcrush-scan pack

[ralyodio]

Adds a threatcrush-scan action pack: runs ThreatCrush over pull requests and uploads SARIF to the Security tab. This is the unit the fleet installs for the org-wide rollout.

Ships two files: the workflow, and .github/threatcrush-to-sarif.py — a fail-closed converter for CLI versions older than native --format.

Field-tested on a real repo, and it caught me out twice

I installed this on moshcoder/moshpit-name before rolling to 216 more. Four runs, in order:

1 — green, and wrong. Reported 0 findings, having scanned nothing. The runner had 0.2.2, which has no --format; the scan died with error: unknown option '--format' and commander exited 1 — the same code the CLI uses for findings at or above failOn. Read as a result, no SARIF written, empty-run fallback supplied one, repo declared clean.

2 — red, comment still lied. A capability check fixed the job status, but the comment still said "0 findings": it tested status == "error", and a skipped step yields the empty string. Fail-open in the one branch written to prevent exactly this.

3 — red and honest, but it refused to scan anything until a new CLI shipped. Correct and useless.

4 — green, genuinely scanned. Detect the interface up front, convert legacy output when --format is absent.

Design

CLI	Path
Has --format	Native SARIF. Nothing is parsed.
Older	Text scan → .github/threatcrush-to-sarif.py

The check is up front because exit codes cannot separate "argument rejected" from "findings found" — that ambiguity is what produced run 1.

The converter fails closed: unrecognised output exits non-zero and writes nothing. Emitting empty SARIF instead reports "0 findings", indistinguishable from a clean scan. It is written against the testbed's real captured output, because three details each break a naive parser: severity is bare for CRITICAL and bracketed for [HIGH]/[MEDIUM]/[LOW]; paths are relative to the scan root, so they resolve to nothing unprefixed; whole-file findings report line 0, which SARIF rejects.

Beyond that: the SARIF file is the evidence (missing or empty ⇒ error, whatever the process returned); the report is fail-closed (findings render only on clean/findings, every other state is NOT RUN); and failOn actually gates — it was recording findings and letting the step pass, so the gate would never have failed a PR.

Other decisions: no secrets (installs fleet-wide without provisioning); report-only by default (a gate that fires on every pre-existing finding gets switched off within a day); not pull_request_target (runs with repo secrets in scope against untrusted contributor code — asserted in a test); Node 20 for better-sqlite3 prebuilts.

Verification

• Four live runs on a real repository, which is what found both bugs.
• Converter against the testbed's real fixture: 9/9 findings parsed, both severity shapes, :0 clamped, prefix applied. Scored through the testbed's own validator at 12.9% TPR / 0.0% FPR, matching the published CLI's documented baseline.
• Fail-closed paths: garbage input, help screen, and a crashing CLI all exit non-zero and write no SARIF. A clean scan is correctly recognised as clean, not as an error.
• All four scan outcomes against stub CLIs: no SARIF → exit 1 status=error; clean → exit 0 status=clean; findings → exit 1 status=findings; crash → exit 2 status=error.
• Report Python across all four SCAN_STATUS values: '' and error → NOT RUN; clean/findings → results table.
• Rendered through a faithful reimplementation of the fleet renderer, first checked against vu1nz-scan where it reproduces moshcoder/moshcode's committed workflow byte-for-byte.
• bash -n on every shell block; manifest validated field-by-field against actionPackManifestSchema including .strict().

Coverage

The legacy path is a stopgap — 0.2.2 is a secrets scanner at 12.9%. Once profullstack/threatcrush#73 is merged and published, every installed workflow switches to native SARIF automatically and coverage goes to 90.32% at the same 0.0% false-positive rate. No re-render needed.

🤖 Generated with Claude Code

[github-actions]

ThreatCrush security scan

0 finding(s) in files changed by this PR (scanned 7 changed file(s); 75 further finding(s) elsewhere in the repository are not attributed to this PR).

No new findings in the files this PR changes.

_{ThreatCrush CLI ran locally in the runner (npm i -g @profullstack/threatcrush); no code left the container.}

[github-actions]

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.