Gating a pipeline
Fail a build on a severity threshold you choose, using the same engine that runs in the product.
The gate
`ci` runs the same scan as `scan-local` and exits non-zero when a finding at or above the threshold is present. The threshold is yours to set: `critical`, `high`, `medium`, `low`, or `info`.
Start at `critical` on an existing codebase. A gate that fails on day one gets switched off in week one, and a gate that is switched off protects nothing.
node webcuris.cjs ci . --fail-on=highGitHub Actions
Nothing is uploaded by `ci`, so the workflow needs no key and no network access to your deployment. It reads the checkout and exits.
The workflow downloads the tool the same way you did locally, because a runner has no more access to this project than you do. Store your deployment URL as a repository variable so the workflow is not pinned to one environment.
name: security
on: [push, pull_request]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Download the scanner
run: curl -fsSL "$WEBCURIS_URL/cli" -o webcuris.cjs
env:
WEBCURIS_URL: ${{ vars.WEBCURIS_URL }}
- run: node webcuris.cjs ci . --fail-on=highWhat a failed gate means
It means a finding at your threshold is present in the checkout — not that the build is exploitable. Every finding carries a confidence level alongside its severity, and a `potential` finding is a thing to look at rather than a verdict.
If a gate is failing on something you have judged acceptable, the honest move is to fix it or to lower the threshold deliberately. A suppression list nobody reviews becomes the place risk goes to be forgotten.