Snyk in Jenkins: Add Security Scanning to Pipelines (2026)

Jenkins is a Swiss Army knife for CI/CD, and Snyk is your security-aware assistant, but getting them to play nice in a pipeline can feel like teaching a cat to fetch. The core issue is that Snyk, while powerful, needs to be explicitly integrated into your Jenkins jobs to do its job, rather than just "being there."

Let’s see Snyk in action, scanning a simple Node.js project within a Jenkins pipeline.

First, ensure you have the Snyk Jenkins plugin installed. Go to "Manage Jenkins" -> "Manage Plugins" -> "Available" and search for "Snyk." Install it and restart Jenkins.

Next, configure your Snyk API token. Go to "Manage Jenkins" -> "Configure System." Scroll down to the "Snyk" section. You’ll need to obtain a token from your Snyk account (go to https://app.snyk.io/account/ and click "Generate new token"). Paste this token into the "Authentication token" field. This token is how Jenkins authenticates with Snyk to perform scans.

Now, let’s create a Jenkins pipeline job. You can use a "Pipeline" job type. In the job configuration, under "Pipeline," select "Pipeline script."

Here’s a basic Jenkinsfile that scans a Node.js project:

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Snyk Scan') {
            steps {
                snykSecurityScan(
                    skipBuild: false,
                    failOnCVSS: 'high',
                    scanType: 'npm',
                    additionalArguments: '--all-sub-projects'
                )
            }
        }
        stage('Build') {
            steps {
                sh 'npm install'
                sh 'npm run build'
            }
        }
    }
}

In this Jenkinsfile:

• agent any means the pipeline can run on any available agent.
• checkout scm fetches your source code.
• snykSecurityScan is the core step provided by the Snyk plugin.
  • skipBuild: false means the pipeline will stop if Snyk finds critical issues.
  • failOnCVSS: 'high' sets the threshold: if any vulnerability with a CVSS score of 'high' or 'critical' is found, the build will fail. You can also use 'critical' or 'low'.
  • scanType: 'npm' tells Snyk which package manager to expect. Other common values include 'yarn', 'maven', 'gradle', 'pip', 'go', 'docker', etc. This is crucial for Snyk to correctly identify and scan your dependencies.
  • additionalArguments: '--all-sub-projects' passes extra arguments directly to the Snyk CLI. This is useful for more advanced configurations, like scanning all sub-projects in a monorepo.

When you run this job, Jenkins will execute the snykSecurityScan step. The Snyk plugin will, behind the scenes, invoke the Snyk CLI on the Jenkins agent. It will analyze your project’s manifest files (like package.json for npm) and then query the Snyk vulnerability database. The results are then displayed within the Jenkins UI, often as a build summary or a dedicated Snyk tab.

The power of this integration lies in its ability to shift security left. Instead of discovering vulnerabilities in production, you’re alerted to them as soon as code is committed and the pipeline runs. The failOnCVSS parameter is your gatekeeper, preventing vulnerable code from progressing further in your CI/CD process.

A common point of confusion is how Snyk detects the project type. It primarily relies on the presence of specific manifest files (e.g., package.json, pom.xml, requirements.txt). If these files are not in the root of your checked-out repository, or if the scanType parameter doesn’t match the project’s ecosystem, Snyk might not detect it correctly, leading to a scan that reports no issues because it didn’t actually scan anything.

If your snykSecurityScan step fails with an error like "No supported project file found," double-check that the scanType parameter in your Jenkinsfile accurately reflects your project’s dependency manager and that the corresponding manifest file (package.json, pom.xml, etc.) is present in the directory where the Snyk CLI is executed by Jenkins.

Once you’ve successfully integrated Snyk and fixed all high-severity vulnerabilities, the next hurdle is often managing the remediation workflow for the vulnerabilities that remain, especially those you choose to accept.