CI integration — skip-scan gate

Signet's read path exists so your pipeline can ask "has this been audited?" before your scanners run, and skip the work that a trusted auditor already did (FR-2). This page shows the two supported entry points.

GitHub Action

The repository ships a composite action (action.yml) that runs the gate and writes SARIF 2.1.0 for GitHub Code Scanning, so covered/disputed results show up inline on the PR.

# .github/workflows/signet.yml
name: Signet skip-scan
on: [pull_request]

permissions:
  contents: read
  security-events: write   # required to upload SARIF to Code Scanning

jobs:
  signet-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Signet skip-scan gate
        id: signet
        uses: signet-dev/signet@v1        # your fork/owner; pin a commit SHA in production
        with:
          registry: https://api.signet.dev
          # sbom: sbom.cdx.json           # optional: check every SBOM component
          min-confidence: "0.9"
          fail-on: vuln-found             # vuln-found | disputed | none

      - name: Upload results to Code Scanning
        if: always()                      # upload even when the gate fails the build
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: ${{ steps.signet.outputs.sarif }}

With no repo/commit inputs the gate uses the checked-out repo at HEAD. fail-on: vuln-found fails the build when a covering audit reports a confirmed vulnerability; disputed also fails on contested coverage; none never fails (report-only). Independently of the chosen mode (except none), the gate fails when the registry has recorded verified-grade mapping tampering for a queried package — the immutable registry artifact changed, so its coverage is untrusted and its files are never skip-scanned; a repointed release tag only warns. Add offline-ok: "true" to let the build pass when the registry is unreachable — but note that turns the gate into best-effort, so keep it off for release branches. On GitHub-hosted runners the toolchain is preinstalled; on self-hosted runners add a Rust setup step before the action.

**min-confidence and fail-on are independent — by design.** min-confidence governs only which files count as *covered* (skip-scannable): a file must clear the threshold to be trusted enough to skip. A vulnerability-found (or disputed) attestation, by contrast, fails the build regardless of its confidence — you cannot suppress a reported vulnerability by raising the threshold. A low-reputation auditor's vuln claim is still a signal worth surfacing; the gate fails safe. So min-confidence: "0.9" with fail-on: vuln-found still fails on a 0.03-confidence vuln — that is intended, not a bug.

Any CI (raw CLI)

The action is a thin wrapper. In any pipeline:

# build once (or install a released binary when available)
cargo build --release -p signet-cli
BIN=./target/release/signet

# gate the current checkout, emit SARIF, fail on a confirmed vuln
$BIN gate --registry "$SIGNET_REGISTRY" --fail-on vuln-found --sarif signet-gate.sarif

The exit code is the contract (cli-spec §1): non-zero fails the build. To feed the covered set to a downstream scanner instead of gating, use --emit-excludes semgrep (or paths) to print the already-audited files so the scanner can skip them.

Quick dependency check

For a lockfile-level pre-flight (no SBOM required), signet deps autodetects requirements.txt / package-lock.json / Cargo.lock and reports each dependency's audit + AI status:

signet deps --fail-on vuln-found --sarif signet-deps.sarif
# fail-on: none | vuln-found | disputed | ai-findings | ai-high
# --sarif: Code-Scanning log — vulns/tampering as errors, disputes/repoints as warnings

Like the coverage gate, signet deps fails any gating mode (except none) when the registry has recorded verified-grade mapping tampering for a pinned dependency, and warns when a release tag behind one was repointed.