Every Jenkins build that runs mvn install or npm ci is also, silently, a bet that nothing in the dependency tree has become dangerous since the last time someone checked. Snyk's Jenkins integration turns that bet into an explicit gate: a build step (or a snykSecurity pipeline step) runs the Snyk CLI against your manifest files, compares whatever it finds to a severity threshold you configure, and returns an exit code Jenkins uses to mark the build FAILURE or UNSTABLE. There's no proprietary magic here — it's documented CLI behavior wrapped in a Jenkins plugin available on the Update Center. But the mechanics matter: what "new vulnerability" actually means, when the gate fires, and what happens after the build finishes are all easy to get wrong when you're setting policy. Here's how it actually works, end to end.
How does the Snyk Jenkins plugin trigger a scan during a build?
It adds a build step that wraps the Snyk CLI rather than reimplementing scanning logic itself. In a Freestyle job you add "Invoke Snyk Security task"; in a Jenkinsfile you call the snykSecurity step. Either way, the plugin downloads the platform-appropriate Snyk CLI binary (Linux, macOS, or Windows), authenticates using a SNYK_TOKEN stored as a Jenkins credential, and executes the equivalent of snyk test against whatever manifest it finds in the workspace — package.json/package-lock.json, pom.xml, requirements.txt, Gemfile.lock, go.mod, and similar files depending on ecosystem. If you're scanning a container image instead, the same plugin can invoke snyk container test against a built image tag; for infrastructure-as-code, snyk iac test against Terraform or CloudFormation files. All three modes report back through the same pass/fail mechanism.
What actually causes Jenkins to mark the build as failed?
It's an exit code, not a UI decision. The Snyk CLI returns exit code 1 when it finds vulnerabilities at or above the severity threshold you've set, 0 when the scan is clean, and other non-zero codes (typically 2 or 3) when the scan itself errors out — a bad manifest, an auth failure, a network timeout. The Jenkins plugin's failOnIssues setting (true by default) tells the build step to translate that exit code into a Jenkins build result. Severity itself is bucketed from the underlying CVSS score into four tiers — low, medium, high, and critical — with critical roughly corresponding to CVSS 9.0–10.0. Set --severity-threshold=high and a medium-severity finding (say, CVSS 5.4) won't touch your build result at all; a critical one will. Leave the threshold unset and, by default, any vulnerability of any severity fails the build.
How does Snyk distinguish a "new" vulnerability from one already known?
Mechanically, it doesn't diff against your last Jenkins build — each run is a fresh, stateless snyk test scored against Snyk's vulnerability database at that exact moment. "New" happens two distinct ways, and conflating them is a common source of confusion. First, a code change: someone bumps a dependency version, or adds a new one, and that version happens to carry a known vulnerability the previous dependency tree didn't have. Second, and less intuitive: nothing in your codebase changed, but Snyk's database was updated with a newly disclosed CVE affecting a package you've had installed for months. The clearest real-world example of the second case is Log4Shell (CVE-2021-44228), disclosed on December 10, 2021 — projects with an unchanged pom.xml that had been passing Snyk scans for weeks suddenly started failing the same build the following day, because the vulnerability data changed, not the code. That's the mechanism people usually mean when they say "Snyk caught a new vuln" — it's a moving target, not a static diff.
How do teams configure thresholds and exceptions without disabling the gate entirely?
Through CLI flags at scan time and a policy file checked into source control, not through disabling the check. The --severity-threshold flag (low/medium/high/critical) sets the floor for what fails the build, and --fail-on narrows it further to all, upgradable (only vulns with a fix available), or patchable. For known findings a team has accepted — a transitive dependency with no fix yet, a vuln in a code path that's genuinely unreachable — Snyk supports a .snyk policy file committed to the repo that ignores specific issue IDs, optionally with an expiry date so the exception doesn't survive silently forever. Org-wide policies (which projects report to, default branch protection behavior) are set separately in the Snyk web console rather than in Jenkins itself.
Does this work the same way in scripted and declarative Pipeline as in Freestyle jobs?
Underneath, yes — same CLI, same exit codes — but the configuration surface is different. Pipeline jobs call the snykSecurity step directly in a Jenkinsfile, passing parameters like snykInstallation, snykTokenId, severity, failOnIssues, and monitorProjectOnBuild as named arguments; Freestyle jobs expose the same options through job-configuration UI fields instead of code. Teams that want more control than either wrapper offers often skip the plugin entirely and call the CLI directly with a sh 'snyk test --severity-threshold=high --fail-on=upgradable' step after installing the Snyk CLI as a Jenkins tool — functionally equivalent, just without the plugin's UI convenience or its bundled HTML reporting.
What happens to results after the build finishes?
Two things, and only one of them depends on the build itself. The plugin can generate an HTML vulnerability report and archive it as a Jenkins build artifact via the HTML Publisher plugin, so the findings for that specific run are viewable from the build page rather than only in a terminal log. Separately — and this is easy to miss — if monitorProjectOnBuild is enabled, the plugin also runs snyk monitor, which pushes a snapshot of the current dependency tree to the Snyk web dashboard as a tracked project. That snapshot is what generates alerts later: if a new CVE is disclosed against a dependency in that snapshot next month, Snyk can notify the team even though Jenkins hasn't run a new build. The CI gate and the ongoing dashboard monitoring are two separate mechanisms that happen to share one CLI invocation.
How Safeguard Helps
Snyk's Jenkins plugin does exactly what it's built for: a point-in-time gate on the manifests present in a single job, at the moment that job runs, scored against Snyk's own vulnerability data. That's valuable and worth keeping. But it's also inherently scoped to whatever pipeline it's wired into and whatever ecosystem-specific manifest it knows how to parse — it doesn't see whether the artifact that eventually ships matches what was scanned, whether a downstream build re-pulled an unpinned dependency after the gate passed, or how findings correlate across the dozen other Jenkins jobs, GitHub Actions workflows, and GitLab pipelines a typical org runs in parallel.
Safeguard sits a level above individual scanner integrations, giving teams a consolidated view of software supply chain risk across every pipeline and tool feeding it — including gates like Snyk's Jenkins plugin. Rather than replacing per-ecosystem vulnerability scanning, Safeguard aggregates the signal it produces alongside SBOM data, build provenance, and artifact integrity checks, so a finding surfaced in one Jenkins job is visible in the same place as risk from a different CI system, a container registry, or a production runtime. For teams already relying on Snyk's build-time gate, that means fewer blind spots between "the build passed" and "the artifact that's actually running in production is still what was scanned" — the gap that a single CI plugin, by design, was never built to close on its own.