feat(ci): add fail_on_severity so the scan gate can actually fail

[hyperpolymath]

The problem

panic-attack assail has no non-zero exit path of its own — no
process::exit, no ExitCode, no --fail-on anywhere in its 3,132-line
src/main.rs. It always exits 0.

So a consumer of scan-and-report.yml gets a job whose only real output is the
cross-repo report. When that dispatch is skipped — which is the documented,
supported path when VERISIMDB_PAT is absent — the job scans, throws the
result away, and reports success no matter what it found.

Measured on hyperpolymath/verisimdb at origin/main: 113 findings, including
one live High, with the Security Scan reporting green throughout.

The change

A fail_on_severity input (none | low | medium | high | critical) plus a gate
step that fails when an unsuppressed finding sits at or above the threshold.

Four things worth reviewing specifically:

1. Default none — this is a no-op until opted into. verisimdb, echidna and
   ambientops all stay exactly as green on merge as they are now. Nobody gets a
   surprise red from this landing.
2. Only unsuppressed findings count.suppressed comes from the repo's own
   classification registry and from test-context detection, and it is omitted
   rather than set to false — so the filter is select(.suppressed != true),
   not == false. Getting that backwards would make the gate count nothing.
3. An unrecognised threshold aborts the job. A typo such as hgih must not
   fall through to "threshold 0" and pass everything. A gate that silently
   accepts a malformed configuration is the same class of defect this PR exists
   to remove, so the case has an explicit *) that errors.
4. The failure message points at the classification registry, not at this
   workflow. Suppression should live next to the evidence with an audit
   rationale, in review — not get buried in CI config where nobody re-reads it.

Verification

Gate logic run against a real 113-finding scan (verisimdb origin/main):

threshold	offending
critical	0
high	1
medium	39

The single High was genuine, and instructive: it was live only because a
classification key still named VeriSimVcl.res's pre-rename path, so a rename
had silently un-suppressed it. Exactly the kind of drift a real gate catches and
an always-exit-0 scan cannot. That key is fixed in verisimdb#201, which takes
that repo to 0 High / 0 Critical — so it can adopt fail_on_severity: high
immediately without a flag day.

A malformed threshold was confirmed to abort rather than pass. YAML parses.

Not included

No baseline/grandfathering file. Suppression already has a home — the
per-repo classification registry — and adding a second, CI-local mechanism
would split the audit trail across two places. Happy to add one if you'd rather
have a fast path for bulk-accepting an existing backlog.

🤖 Generated with Claude Code

[gitar-bot]

Note

Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime.
Learn more

Code Review✅ Approved2 resolved / 2 findings

Adds a fail_on_severity input and gate step to the CI scan to enforce unsuppressed finding thresholds. The change requests fixes for case-sensitive threshold validation causing valid inputs to abort and ensuring scan gate failures do not prematurely short-circuit the report dispatch step.

✅ 2 resolved

✅ Edge Case: Capitalized 'None' aborts the job instead of no-op

📄 .github/workflows/scan-and-report.yml:57📄 .github/workflows/scan-and-report.yml:67-76
The step's if: uses an exact, case-sensitive comparison inputs.fail_on_severity != 'none', but the case inside the script lowercases the value and has no none) branch. So a caller passing None or NONE (which they'd reasonably expect to be a no-op, since every other value is treated case-insensitively) passes the if gate, then falls through to *) and fails the job with 'must be one of none|low|medium|high|critical'. Add an explicit none) exit 0 ;; branch to the case statement so the documented default value is honored regardless of casing.

✅ Edge Case: Gate failure suppresses cross-repo report dispatch

📄 .github/workflows/scan-and-report.yml:56-70📄 .github/workflows/scan-and-report.yml:104-105
The 'Send to verisimdb-data' step is guarded by if: steps.scan.outputs.scan_complete == 'true', which GitHub implicitly ANDs with success(). When the new gate step exits 1, the job status becomes failure and the dispatch step is skipped — so scans with the most findings (exactly the ones worth recording centrally) never reach verisimdb-data. If the intent is to still report while failing the job, add a status function such as if: always() && steps.scan.outputs.scan_complete == 'true' to the send step, or place the gate after the dispatch.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}