Webcuris

Developer reference

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=high

GitHub Actions

Nothing is uploaded by ci, so the workflow needs no key and no network access to Webcuris. 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 the site address 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=high

What 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.