DEV Community

Rahul Singh
Rahul Singh

Posted on • Originally published at aicodereview.cc

How to Use Snyk in CI/CD: Jenkins, GitHub Actions, More

#codereview #ai #programming #webdev

Why integrate Snyk into your CI/CD pipeline

Running security scans manually is unreliable. Developers forget, timelines slip, and vulnerabilities reach production undetected. The only way to enforce consistent security scanning across every code change is to embed it directly into your CI/CD pipeline - where it runs automatically on every pull request, every build, and every deployment.

Snyk is built for this. Its CLI returns standard exit codes that integrate with any CI platform, its official actions and plugins simplify setup on popular platforms, and its scan times are fast enough to run on every pull request without grinding your pipeline to a halt. A typical dependency scan completes in 10 to 30 seconds. Even a full SAST scan with Snyk Code finishes in under three minutes for most projects.

This guide covers how to set up Snyk CI CD integration across every major platform - GitHub Actions, Jenkins, GitLab CI, and Azure Pipelines. You will learn when to use snyk test versus snyk monitor, how to configure severity thresholds so your pipeline only fails on serious vulnerabilities, how to scan containers in CI, and how to troubleshoot the most common issues teams encounter. If you have not installed or configured Snyk yet, start with our how to setup Snyk guide first.

Snyk screenshot

Prerequisites for Snyk CI CD integration

Before adding Snyk to any CI/CD pipeline, you need three things in place:

  • A Snyk account and API token. Sign up at app.snyk.io, then generate an API token from your account settings at app.snyk.io/account. This token authenticates the Snyk CLI in headless CI environments where browser-based login is not possible.
  • The Snyk CLI available in your CI environment. You can install it via npm (npm install -g snyk), download a standalone binary, or use Snyk's official Docker images that come with the CLI pre-installed.
  • Your SNYK_TOKEN stored as a CI secret. Every CI platform has a mechanism for storing secrets - GitHub Actions secrets, Jenkins credentials, GitLab CI/CD variables, or Azure Pipelines variables. Store your API token there and reference it as the SNYK_TOKEN environment variable.

If you are already using Snyk locally or through the Snyk GitHub integration, you already have an account and token. The same token works for CI/CD authentication.

Understanding snyk test vs snyk monitor

Before diving into platform-specific configurations, it is important to understand the two primary Snyk commands used in CI/CD and when to use each one.

snyk test - the pipeline gate

The snyk test command runs a one-time scan against your project and returns a result immediately:

snyk test --severity-threshold=high
Enter fullscreen mode Exit fullscreen mode
  • Exit code 0 means no vulnerabilities were found at or above the specified severity threshold. The pipeline continues.
  • Exit code 1 means vulnerabilities were found. The pipeline fails, blocking the merge or deployment.
  • Exit code 2 means the scan itself failed due to an error - authentication, network, or configuration issues.

This is the command you use to gate pull requests. It answers the question: "Does this code change introduce or contain security vulnerabilities?"

snyk monitor - the production tracker

The snyk monitor command uploads a snapshot of your project's dependencies to the Snyk dashboard:

snyk monitor
Enter fullscreen mode Exit fullscreen mode

It does not return a pass/fail result. Instead, it creates a monitored project in your Snyk dashboard that Snyk continuously checks against its vulnerability database. When a new vulnerability is disclosed that affects your dependencies, Snyk sends an alert - even if the vulnerability was not known at the time you ran the scan.

Use snyk monitor after a successful deployment to track what is actually running in production. Run it only on your main branch to avoid cluttering the dashboard with feature branch snapshots.

The recommended pattern

Most teams use both commands in their pipeline:

Pull Request  -->  snyk test (gate - blocks merge if vulnerabilities found)
Merge to main -->  snyk test (verify) + snyk monitor (track production state)
Enter fullscreen mode Exit fullscreen mode

This gives you pre-merge gating and post-merge monitoring in a single workflow.

Setting up Snyk in GitHub Actions

GitHub Actions is the most common CI platform for Snyk integration, and Snyk provides official GitHub Actions that simplify the setup. For a broader look at using security tools in GitHub workflows, see our guide on Snyk code review.

Basic dependency scanning workflow

Create a workflow file at .github/workflows/snyk.yml:

name: Snyk Security Scan

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main]

jobs:
  snyk-test:
    name: Snyk Open Source
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Snyk to check for vulnerabilities
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high
Enter fullscreen mode Exit fullscreen mode

Replace snyk/actions/node with the action matching your language:

Language Action
JavaScript/TypeScript snyk/actions/node@master
Python snyk/actions/python@master
Java (Maven) snyk/actions/maven@master
Java (Gradle) snyk/actions/gradle@master
Go snyk/actions/golang@master
.NET snyk/actions/dotnet@master
Docker snyk/actions/docker@master
Infrastructure as Code snyk/actions/iac@master

Adding SAST scanning with Snyk Code

To scan your source code for vulnerabilities alongside dependency scanning, add a second job:

  snyk-code:
    name: Snyk Code (SAST)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Snyk Code
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          command: code test
          args: --severity-threshold=high
Enter fullscreen mode Exit fullscreen mode

Snyk Code must be enabled in your Snyk organization settings before this will work. Go to app.snyk.io, navigate to Settings, select Snyk Code, and toggle it on.

Uploading results to GitHub Security tab

You can send Snyk findings to GitHub's Security tab using the SARIF format:

  snyk-sarif:
    name: Snyk SARIF Upload
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Snyk test
        uses: snyk/actions/node@master
        continue-on-error: true
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --sarif-file-output=snyk.sarif

      - name: Upload SARIF to GitHub
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: snyk.sarif
        if: always()
Enter fullscreen mode Exit fullscreen mode

The continue-on-error: true setting ensures the SARIF upload runs even when vulnerabilities are found. The if: always() condition on the upload step guarantees it executes regardless of the test step's outcome. Note that SARIF upload to private repositories requires GitHub Advanced Security.

Adding snyk monitor on main branch

Add a monitoring step that only runs on pushes to main:

  snyk-monitor:
    name: Snyk Monitor
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Monitor with Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          command: monitor
Enter fullscreen mode Exit fullscreen mode

Setting up Snyk in Jenkins

Jenkins integration with Snyk can be done through the Snyk Security plugin or by running the CLI directly. Both approaches work, but they offer different levels of UI integration.

Option 1 - Snyk Security Jenkins plugin

The plugin provides a dedicated build step with HTML reports in the Jenkins UI.

  1. Go to Manage Jenkins and then Manage Plugins
  2. Search for "Snyk Security" in the Available tab and install it
  3. Navigate to Manage Jenkins and then Manage Credentials
  4. Add a new Snyk API Token credential with your API token
  5. Go to Manage Jenkins and then Global Tool Configuration
  6. Under Snyk, add an automatic installer that downloads the latest CLI

Declarative Jenkinsfile with the plugin 

pipeline {
    agent any

    tools {
        snyk 'snyk-latest'
    }

    environment {
        SNYK_TOKEN = credentials('snyk-api-token')
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Install Dependencies') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Snyk Security Scan') {
            steps {
                snykSecurity(
                    snykInstallation: 'snyk-latest',
                    snykTokenId: 'snyk-api-token',
                    severity: 'high',
                    failOnIssues: true
                )
            }
        }

        stage('Snyk Monitor') {
            when {
                branch 'main'
            }
            steps {
                sh 'snyk monitor'
            }
        }
    }

    post {
        always {
            archiveArtifacts artifacts: '**/snyk_report.html', allowEmptyArchive: true
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

Option 2 - CLI-based Jenkins pipeline

If you prefer not to use the plugin, install the Snyk CLI directly:

pipeline {
    agent any

    environment {
        SNYK_TOKEN = credentials('snyk-api-token')
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Install Snyk CLI') {
            steps {
                sh 'npm install -g snyk'
            }
        }

        stage('Install Dependencies') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Snyk Test') {
            steps {
                sh 'snyk test --severity-threshold=high'
            }
        }

        stage('Snyk Code') {
            steps {
                sh 'snyk code test --severity-threshold=high'
            }
        }

        stage('Snyk Monitor') {
            when {
                branch 'main'
            }
            steps {
                sh 'snyk monitor'
            }
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

The CLI approach is simpler and works in any Jenkins environment, including containerized agents. The plugin approach gives you HTML report artifacts and a richer UI in the Jenkins dashboard.

Setting up Snyk in GitLab CI

GitLab CI integration uses the .gitlab-ci.yml configuration file. Snyk provides a Docker image with the CLI pre-installed, which simplifies the setup.

Store the Snyk token as a CI/CD variable

  1. Go to your GitLab project's Settings and then CI/CD
  2. Expand the Variables section
  3. Add a variable named SNYK_TOKEN with your API token
  4. Check Mask variable to prevent it from appearing in job logs
  5. Optionally check Protect variable to restrict it to protected branches

Basic GitLab CI configuration 

stages:
  - test
  - security
  - monitor

snyk-dependency-scan:
  stage: security
  image: snyk/snyk-cli:npm
  script:
    - snyk test --severity-threshold=high
  only:
    - merge_requests
    - main
  allow_failure: false

snyk-code-scan:
  stage: security
  image: snyk/snyk-cli:npm
  script:
    - snyk code test --severity-threshold=high
  only:
    - merge_requests
    - main
  allow_failure: false

snyk-monitor:
  stage: monitor
  image: snyk/snyk-cli:npm
  script:
    - snyk monitor
  only:
    - main
Enter fullscreen mode Exit fullscreen mode

GitLab Security Dashboard integration

For GitLab Ultimate users, you can output Snyk results in GitLab's security report format so findings appear in the merge request security widget:

snyk-dependency-scan:
  stage: security
  image: snyk/snyk-cli:npm
  script:
    - snyk test --json > snyk-results.json || true
    - snyk-to-gitlab snyk-results.json > gl-dependency-scanning-report.json
  artifacts:
    reports:
      dependency_scanning: gl-dependency-scanning-report.json
  only:
    - merge_requests
Enter fullscreen mode Exit fullscreen mode

This requires the snyk-to-gitlab converter tool, which translates Snyk's JSON output into GitLab's expected security report schema.

Setting up Snyk in Azure Pipelines

Azure DevOps supports Snyk through a marketplace extension or direct CLI usage.

Option 1 - Snyk Security Scan extension

  1. Install the Snyk Security Scan extension from the Azure DevOps Marketplace
  2. Create a service connection with your Snyk API token under Project Settings and then Service connections
  3. Add the Snyk task to your pipeline 
trigger:
  branches:
    include:
      - main

pr:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '20.x'

  - script: npm ci
    displayName: 'Install dependencies'

  - task: SnykSecurityScan@1
    inputs:
      serviceConnectionEndpoint: 'SnykConnection'
      testType: 'app'
      severityThreshold: 'high'
      failOnIssues: true
      monitorWhen: 'always'
Enter fullscreen mode Exit fullscreen mode

Option 2 - CLI-based Azure pipeline 

trigger:
  branches:
    include:
      - main

pr:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  - group: security-tokens

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '20.x'

  - script: npm install -g snyk
    displayName: 'Install Snyk CLI'

  - script: npm ci
    displayName: 'Install dependencies'

  - script: snyk test --severity-threshold=high
    displayName: 'Snyk dependency scan'
    env:
      SNYK_TOKEN: $(SNYK_TOKEN)

  - script: snyk code test --severity-threshold=high
    displayName: 'Snyk Code SAST scan'
    env:
      SNYK_TOKEN: $(SNYK_TOKEN)

  - script: snyk monitor
    displayName: 'Snyk monitor'
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    env:
      SNYK_TOKEN: $(SNYK_TOKEN)
Enter fullscreen mode Exit fullscreen mode

Failing builds on vulnerabilities

Controlling when your pipeline fails is critical for balancing security enforcement with developer productivity. Snyk provides several mechanisms for fine-tuning this behavior.

Severity threshold

The --severity-threshold flag controls the minimum severity that triggers a build failure:

# Fail only on critical vulnerabilities
snyk test --severity-threshold=critical

# Fail on high and critical (recommended for most teams)
snyk test --severity-threshold=high

# Fail on medium, high, and critical
snyk test --severity-threshold=medium

# Fail on any vulnerability (strictest)
snyk test
Enter fullscreen mode Exit fullscreen mode

Starting with --severity-threshold=high is recommended for teams adopting Snyk for the first time. This catches genuinely dangerous vulnerabilities without creating noise from low-risk findings that would slow down development.

The .snyk policy file for exceptions

When Snyk flags a vulnerability that is not exploitable in your context, use the .snyk policy file to ignore it:

snyk ignore --id=SNYK-JS-LODASH-1018905 \
  --expiry=2026-06-13 \
  --reason="Function _.template is not used in our codebase"
Enter fullscreen mode Exit fullscreen mode

This creates an ignore rule in the .snyk file at your project root. Commit this file to version control so the exception applies in CI as well. Always set an expiration date and document the reasoning - permanent ignores without justification are a security anti-pattern.

Gradual rollout for existing projects

If your project has a large backlog of existing vulnerabilities, failing the build immediately on all of them will block every pull request. Instead, use a gradual approach:

  1. Week 1-2: Run Snyk with continue-on-error: true (or allow_failure: true in GitLab) to see what it finds without blocking anyone
  2. Week 3: Review findings and ignore any that are not exploitable using the .snyk policy file
  3. Week 4: Enable strict enforcement with --severity-threshold=high
  4. Ongoing: Lower the threshold to medium as you resolve the backlog

This phased approach prevents Snyk from becoming a bottleneck while still moving toward full security enforcement.

Container scanning in CI/CD

Scanning container images in CI ensures that vulnerabilities in base images and OS packages are caught before deployment. This is separate from dependency scanning - container scanning examines the entire image filesystem.

GitHub Actions container scanning 

  snyk-container:
    name: Snyk Container
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Snyk Container scan
        uses: snyk/actions/docker@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          image: myapp:${{ github.sha }}
          args: --file=Dockerfile --severity-threshold=high
Enter fullscreen mode Exit fullscreen mode

Jenkins container scanning 

stage('Container Scan') {
    steps {
        sh 'docker build -t myapp:${BUILD_NUMBER} .'
        sh 'snyk container test myapp:${BUILD_NUMBER} --file=Dockerfile --severity-threshold=high'
    }
}
Enter fullscreen mode Exit fullscreen mode

GitLab CI container scanning 

snyk-container:
  stage: security
  image: docker:latest
  services:
    - docker:dind
  before_script:
    - apk add --no-cache npm
    - npm install -g snyk
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
    - snyk container test myapp:$CI_COMMIT_SHA --file=Dockerfile --severity-threshold=high
  only:
    - merge_requests
    - main
Enter fullscreen mode Exit fullscreen mode

The --file=Dockerfile flag is important because it enables Snyk to provide base image upgrade recommendations. Without it, Snyk still scans the image but cannot suggest which base image version would reduce your vulnerability count.

Monitoring deployed container images

After deploying an image to production, run snyk container monitor to track it:

snyk container monitor myapp:latest --file=Dockerfile --project-name=myapp-production
Enter fullscreen mode Exit fullscreen mode

This creates a monitored project in the Snyk dashboard. When new CVEs are disclosed that affect packages in your production image, Snyk sends alerts so you can rebuild and redeploy with a patched base image.

Advanced CI/CD patterns

Parallel scanning for faster pipelines

Run all Snyk scan types in parallel rather than sequentially to minimize the total time added to your pipeline:

# GitHub Actions - parallel jobs
jobs:
  snyk-deps:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

  snyk-code:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          command: code test
          args: --severity-threshold=high

  snyk-iac:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: snyk/actions/iac@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=medium
Enter fullscreen mode Exit fullscreen mode

All three jobs run simultaneously. The total pipeline time equals the slowest individual scan rather than the sum of all three.

Caching the Snyk CLI for faster builds

In pipelines where you install the Snyk CLI via npm, cache the npm global directory to skip the download on subsequent runs:

# GitHub Actions caching
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-snyk-${{ hashFiles('**/package-lock.json') }}

- run: npm install -g snyk
Enter fullscreen mode Exit fullscreen mode

Monorepo scanning

For monorepos with multiple projects, run Snyk against each project root:

strategy:
  matrix:
    project: [frontend, backend, shared-lib]
steps:
  - uses: actions/checkout@v4
  - run: cd ${{ matrix.project }} && npm ci
  - uses: snyk/actions/node@master
    env:
      SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
    with:
      args: --severity-threshold=high --project-name=${{ matrix.project }}
Enter fullscreen mode Exit fullscreen mode

The --project-name flag ensures each subproject appears as a separate entry in the Snyk dashboard.

Considering alternatives for CI/CD security

Snyk is a strong choice for CI/CD security scanning, but it is worth evaluating how it compares to alternatives - especially if you want to consolidate tools or reduce costs. For a detailed comparison, see our Snyk alternatives roundup.

CodeAnt AI takes a different approach by bundling SAST security scanning with AI-powered code review in a single platform. Starting at $24 per user per month for the Growth plan and $40 per user per month for the Enterprise plan, CodeAnt AI provides static analysis, security vulnerability detection, and automated code quality review in one CI pipeline step. This can be more cost-effective than running separate tools for security scanning and code review, especially for teams that are currently paying for both Snyk and a separate AI review tool.

The Snyk pricing page breaks down costs in detail, but the key consideration for CI/CD is test limits. The free plan's 400 open-source tests and 100 code tests per billing period can be consumed quickly in active repositories with frequent pull requests. Paid plans start at $25 per contributing developer per month.

For teams evaluating their options, the right choice depends on what you need: Snyk excels at deep vulnerability intelligence with its curated database and fix recommendations, while tools like CodeAnt AI offer broader coverage by combining security with code quality in a single integration point.

Troubleshooting Snyk in CI/CD

Authentication failures in CI

Problem: The pipeline fails with "Missing API token" or "Authentication failed."

Fix: Verify the SNYK_TOKEN environment variable is correctly set. In GitHub Actions, check that the secret name in your repository settings matches exactly what you reference in the workflow. In Jenkins, ensure the credentials binding is using the correct credential ID. Test your token locally:

SNYK_TOKEN=your-token snyk test --dry-run
Enter fullscreen mode Exit fullscreen mode

If the token works locally but fails in CI, the issue is almost always in how the CI platform is injecting the secret into the environment.

"Could not detect supported target files"

Problem: Snyk cannot find a manifest file to scan.

Fix: Ensure your CI job checks out the code before running Snyk. Verify the working directory is correct - some CI platforms change the working directory between steps. Specify the file explicitly if needed:

snyk test --file=path/to/package.json
Enter fullscreen mode Exit fullscreen mode

Snyk Code returns no results

Problem: snyk code test produces no output or returns an error.

Fix: Snyk Code must be enabled in your organization settings at app.snyk.io. This is a separate toggle from the general Snyk product. Also verify that your project's language is supported - Snyk Code supports JavaScript, TypeScript, Python, Java, Go, Ruby, C#, PHP, and several others.

Pipeline timeout during container scan

Problem: Container scanning takes too long and the CI job times out.

Fix: Large container images with hundreds of installed packages take longer to scan. Use slim or Alpine-based images to reduce scan time. Pull the base image in a separate cached step so the scan does not include the pull time. If timeouts persist, increase the CI job timeout and consider running container scans as a separate, non-blocking job.

Scan results differ between local and CI

Problem: Snyk reports different vulnerabilities locally versus in CI.

Fix: This usually happens because the dependency tree differs between environments. Ensure your CI pipeline uses a lock file (package-lock.json, yarn.lock, poetry.lock) and installs dependencies with a deterministic command (npm ci instead of npm install). Also check that the Snyk CLI version matches between local and CI by pinning the version in your CI configuration.

SARIF upload fails

Problem: The upload-sarif step fails with "Advanced Security must be enabled."

Fix: SARIF upload to GitHub's Security tab requires GitHub Advanced Security for private repositories. It is free for public repositories. If you do not have Advanced Security, remove the SARIF upload step - Snyk results are still available in the Snyk dashboard and as PR check annotations.

Summary

Integrating Snyk into your CI/CD pipeline is the most effective way to catch security vulnerabilities before they reach production. The setup varies by platform, but the core pattern is the same across all of them: install the CLI, set the SNYK_TOKEN, run snyk test to gate builds, and run snyk monitor to track deployments.

Start with dependency scanning and a --severity-threshold=high to catch the most critical issues without generating noise. Add Snyk Code SAST scanning to catch vulnerabilities in your own source code. Layer in container scanning if you deploy Docker images. Use the .snyk policy file to manage exceptions with documented reasons and expiration dates.

The key decisions for your pipeline are: which severity threshold to enforce, whether to run scans on all branches or only on pull requests to main, and whether to upload results to GitHub's Security tab or rely on the Snyk dashboard. For most teams, gating on high severity with SARIF upload provides the right balance of security and developer experience.

For more on Snyk's capabilities and how it compares to other tools, explore our Snyk code review guide, Snyk GitHub integration walkthrough, and Snyk alternatives comparison.

Further Reading

Frequently Asked Questions

How do I add Snyk to a CI/CD pipeline?

Install the Snyk CLI in your CI environment, set the SNYK_TOKEN environment variable with your API token, and run 'snyk test' as a build step. The command exits with code 1 when vulnerabilities are found, which causes the pipeline to fail. Most CI platforms support this pattern natively. For GitHub Actions, use the official snyk/actions images. For Jenkins, install the Snyk Security plugin or run the CLI directly in a shell step. For GitLab CI and Azure Pipelines, add the Snyk CLI install and test commands to your pipeline YAML.

What is the difference between snyk test and snyk monitor in CI/CD?

The 'snyk test' command runs a one-time scan and returns a pass or fail result based on whether vulnerabilities are found. Use it in CI pipelines to gate builds and block merges when security issues exist. The 'snyk monitor' command uploads a dependency snapshot to the Snyk dashboard for continuous monitoring and does not fail the build. Use 'snyk monitor' after a successful deployment to track what is running in production. Most teams run 'snyk test' on pull requests and 'snyk monitor' on pushes to the main branch after all checks pass.

How do I set up Snyk in GitHub Actions?

Create a workflow file at .github/workflows/snyk.yml. Use the official snyk/actions GitHub Actions - snyk/actions/node for Node.js, snyk/actions/python for Python, snyk/actions/docker for containers, and snyk/actions/iac for infrastructure as code. Store your Snyk API token as a GitHub secret named SNYK_TOKEN and reference it as an environment variable. Configure the workflow to trigger on pull_request events. Add '--severity-threshold=high' to only fail on high and critical severity vulnerabilities.

How do I configure Snyk in a Jenkins pipeline?

There are two approaches. First, install the Snyk Security Jenkins plugin from the Jenkins plugin manager, configure Snyk credentials under Manage Jenkins, and use the snykSecurity pipeline step in your Jenkinsfile. Second, install the Snyk CLI directly in your pipeline using npm or a standalone binary download, set the SNYK_TOKEN credential, and run 'snyk test' in a shell step. The plugin approach provides a richer UI with HTML reports, while the CLI approach gives you more flexibility and works in any Jenkins environment.

How do I use Snyk in GitLab CI?

Add a security scanning stage to your .gitlab-ci.yml file. Use the snyk/snyk-cli Docker image as the job image, set the SNYK_TOKEN CI/CD variable in your GitLab project settings, and run 'snyk test' as the script command. You can also install the Snyk CLI via npm in your existing job image. For GitLab Ultimate users, Snyk results can be output in GitLab's security report format and displayed in the merge request security widget.

How do I use Snyk in Azure Pipelines?

Install the Snyk Security Scan extension from the Azure DevOps Marketplace, configure a service connection with your Snyk API token, and add the SnykSecurityScan task to your azure-pipelines.yml. Alternatively, add a script step that installs the Snyk CLI via npm and runs 'snyk test'. Store your SNYK_TOKEN as a pipeline variable or in Azure Key Vault. Both approaches support dependency scanning, Snyk Code SAST, container scanning, and IaC analysis.

How do I fail a CI build only on high severity vulnerabilities?

Use the '--severity-threshold' flag with 'snyk test'. Setting '--severity-threshold=high' causes the command to return exit code 1 only when high or critical severity vulnerabilities are found. Medium and low severity findings are reported in the output but do not cause a build failure. This is the recommended approach for most teams because it prevents alert fatigue while still blocking genuinely dangerous vulnerabilities from reaching production.

How do I scan Docker containers with Snyk in CI/CD?

Build your Docker image in a prior CI step, then run 'snyk container test your-image:tag --file=Dockerfile --severity-threshold=high'. The '--file=Dockerfile' flag provides base image upgrade recommendations. For GitHub Actions, use the snyk/actions/docker action. For other CI platforms, install the Snyk CLI, ensure Docker is available in the build environment, and run the container test command. Add 'snyk container monitor' after deployment to track the production image continuously.

Can I upload Snyk results to GitHub's Security tab?

Yes. Add the '--sarif-file-output=snyk.sarif' flag to your snyk test command, then use the github/codeql-action/upload-sarif action to upload the SARIF file to GitHub's Security tab. Set 'continue-on-error: true' on the Snyk step so the SARIF upload runs even when vulnerabilities are found. This provides a centralized view of all security findings directly in GitHub. Note that SARIF upload to private repositories requires GitHub Advanced Security.

How do I troubleshoot Snyk authentication failures in CI/CD?

Verify that the SNYK_TOKEN environment variable is set correctly in your CI configuration. Check that the token has not expired by testing it locally with 'SNYK_TOKEN=your-token snyk auth check'. Ensure the secret is not masked or truncated by your CI platform. In GitHub Actions, secrets are automatically masked - verify the secret name matches exactly. In Jenkins, use the credentials binding plugin to inject the token. Generate a new token at app.snyk.io/account if needed.

Should I run Snyk on every branch or only on pull requests?

Run 'snyk test' on pull requests targeting your main or develop branches. This catches vulnerabilities before code is merged while avoiding unnecessary scans on feature branches that are still in active development. Run 'snyk monitor' only on pushes to the main branch after a successful build to track what is deployed to production. This approach balances security coverage with test quota usage and pipeline speed.

What are alternatives to Snyk for CI/CD security scanning?

Trivy is a popular open-source alternative for container and dependency scanning with native CI/CD support. Semgrep provides SAST scanning with a generous free tier and simple CI integration. GitHub Advanced Security offers CodeQL for SAST and Dependabot for dependency scanning natively in GitHub. CodeAnt AI bundles SAST scanning with AI-powered code review starting at $24 per user per month, providing both security and quality analysis in a single CI pipeline step.

Originally published at aicodereview.cc

Top comments (0)