Snyk’s Zero High/Critical Gate functionality is surprisingly about preventing new vulnerabilities from reaching production, not just reporting them.
Let’s see it in action. Imagine you have a GitHub Actions workflow that builds and deploys your application.
name: CI/CD Pipeline
on:
push:
branches:
- main
jobs:
build_and_deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
- name: Install dependencies
run: npm ci
- name: Build application
run: npm run build
- name: Scan for vulnerabilities with Snyk
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --all-projects --severity-threshold=high # This is where the magic happens
The key here is the args: --all-projects --severity-threshold=high in the Snyk action. This tells Snyk to scan all projects within the repository and, crucially, to treat any findings with a severity of "high" or "critical" as a failure. If Snyk finds any new high or critical vulnerabilities, this step will fail, and consequently, the entire GitHub Actions workflow will stop, preventing the deployment.
The problem this solves is the "oops, we deployed something vulnerable" scenario. Traditionally, CI/CD pipelines would happily deploy code even if new vulnerabilities were discovered during the scan. Developers would then have to manually review Snyk reports and initiate a rollback or hotfix. Zero High/Critical Gate automates this by making vulnerability findings a hard stop in the pipeline.
Internally, Snyk maintains a baseline of known vulnerabilities for your project. When you run a scan with the --severity-threshold (or its equivalent in the Zero High/Critical Gate configuration), Snyk compares the current scan results against this baseline. It specifically looks for new vulnerabilities that have been introduced or have recently been identified as high/critical severity. If it finds any such new issues, it returns a non-zero exit code, which CI/CD systems interpret as a failure.
The exact levers you control are the severity-threshold and the fail-on parameters. For Zero High/Critical Gate, you’d typically set severity-threshold to high (or critical if you want to be even more stringent) and fail-on to all (which is the default when using severity-threshold). You can also configure this directly in the Snyk UI under your project’s settings, which then applies to all scans, including those in your CI/CD pipeline.
One thing most people don’t realize is that Snyk’s severity-threshold flag, when used in CI/CD, is not just about reporting. It’s a declarative way to enforce policy. It tells Snyk, "If you find anything at this severity level or higher that wasn’t there before, consider it a critical failure for this execution context." This is distinct from just running a scan and getting a report; it’s an active gatekeeper.
The next concept you’ll likely encounter is how to manage exceptions or false positives for vulnerabilities that are legitimately accepted risks, perhaps due to specific organizational policies or known mitigations.