A Jenkins scanner is any security tool you invoke from a Jenkins job to inspect source code, third-party dependencies, container images, or infrastructure definitions before an artifact is promoted. The term is loose on purpose. There is no single product called "Jenkins Scanner"; instead there is a category of scanners that people run inside Jenkins, and the choice depends on what you are trying to catch. This guide walks through the main types, how they attach to a pipeline, and the operational habits that keep the scan from becoming the slowest, flakiest stage in your build.
Jenkins is old, extensible, and still everywhere, which is exactly why the scanner story is messy. You can drive a scan through a plugin, a shell step, a Docker agent, or a call out to an external service. All four are valid. What matters is that the scan runs deterministically, fails the build on the conditions you care about, and does not add ten minutes to every commit.
What kinds of scanners run inside Jenkins?
The scanners that end up in Jenkins fall into a handful of buckets, and most mature pipelines run more than one.
Software composition analysis (SCA) looks at your declared and transitive dependencies and matches them against known-vulnerability databases. This is where the majority of real risk lives, because most applications are mostly other people's code. Static application security testing (SAST) parses your own source for insecure patterns like unsanitized inputs feeding a query. Container image scanning inspects the layers of a built image for vulnerable OS packages and language libraries. Secret scanning catches API keys and credentials that got committed by accident. Infrastructure-as-code scanning flags misconfigured Terraform or Kubernetes manifests.
Each of these answers a different question, and a Jenkins scanner for one is not a substitute for another. A common mistake is bolting on a single SAST plugin, seeing green, and assuming the pipeline is covered when the actual exposure is a five-year-old transitive dependency an SCA tool would have flagged in seconds.
How do you wire a scanner into a Jenkinsfile?
The cleanest approach in modern Jenkins is a declarative Jenkinsfile with a dedicated stage. You do not need a plugin for most scanners; a shell step calling the tool's CLI is more portable and easier to reason about. Here is a dependency scan running in its own stage:
pipeline {
agent any
stages {
stage('Build') {
steps { sh 'mvn -B package -DskipTests' }
}
stage('Dependency Scan') {
steps {
sh 'trivy fs --scanners vuln --severity HIGH,CRITICAL --exit-code 1 .'
}
}
}
}
The --exit-code 1 flag is the important part. Without a non-zero exit on findings, the scanner prints a wall of text and the build stays green, which trains everyone to ignore it. With it, a HIGH or CRITICAL finding breaks the build and forces a decision.
If you prefer to isolate the tooling, run the scanner in its own container so you are not polluting the agent with tool installs:
stage('Container Scan') {
agent { docker { image 'aquasec/trivy:latest' } }
steps {
sh 'trivy image --severity CRITICAL --exit-code 1 myapp:${GIT_COMMIT}'
}
}
How do you keep the scan from wrecking build times?
The fastest way to get a scanner ripped out of a pipeline is to make every commit wait on it. A few habits keep it lean.
Cache the vulnerability database. Most SCA and image scanners download an advisory database on each run, and pulling it fresh every build adds latency and creates a hard dependency on an external service being up. Point the tool at a cached database directory that a nightly job refreshes, and pass an offline or "skip update" flag in the per-build invocation.
Scan the right thing at the right time. A full image scan on every push to a feature branch is usually overkill. Run the fast dependency and secret scans on every commit, and reserve the heavier image and SAST passes for merges to main or for release candidates. Jenkins makes this easy with when conditions:
stage('Full Image Scan') {
when { branch 'main' }
steps { sh 'trivy image --exit-code 1 myapp:${GIT_COMMIT}' }
}
Parallelize independent scans. SCA, secret scanning, and IaC checks do not depend on each other, so run them in a parallel block rather than in sequence.
How should the scanner decide to fail a build?
A scanner that fails on every finding gets disabled within a week. A scanner that never fails is theater. The middle path is a policy that fails on severity plus exploitability, not raw counts.
Fail the build on new CRITICAL findings and on HIGH findings that have a known fix available. Warn, but do not fail, on findings with no upstream patch, because breaking the build over something the developer cannot fix just teaches them to bypass the gate. Track those with a ticket instead. Suppress accepted-risk findings explicitly, in a version-controlled ignore file with an expiration date and a written justification, never with a blanket || true that silences the whole stage.
Reachability matters here too. A vulnerable function that your code never calls is a lower priority than one on a hot path. Some scanners now factor call-graph reachability into severity, which cuts the noise dramatically and keeps the gate credible.
Where do plugins fit versus CLI tools?
Jenkins has hundreds of security-related plugins, and they range from genuinely useful to abandoned. The Warnings Next Generation plugin is worth knowing because it parses the output of many scanners into a unified report and trend graph, which is nice for visibility. But for the scan itself, a pinned CLI tool invoked from a shell step ages better than a plugin. Plugins couple you to the Jenkins release cycle and to whoever still maintains them, and a surprising number of security plugins have gone stale. CLI tools you pin to a version and upgrade on your own schedule.
If your team is moving toward pull-request-native security, you may find that the scanner belongs partly in the SCM layer as well, posting results as checks on the PR rather than only in the Jenkins console. That is a good pattern, and it complements rather than replaces the pipeline gate.
FAQ
Is there an official tool called "Jenkins Scanner"?
No. "Jenkins scanner" refers to any security scanner you run inside a Jenkins job. Popular choices include Trivy, Grype, OWASP Dependency-Check for SCA and images, Semgrep for SAST, and Gitleaks for secrets. The right one depends on what you need to catch.
Should I use a Jenkins plugin or a CLI tool for scanning?
For most cases a pinned CLI tool called from a shell step is more portable and easier to upgrade than a plugin. Plugins couple you to the Jenkins release cycle, and many security plugins are poorly maintained. Reserve plugins for reporting and visualization.
How do I stop a scanner from slowing down every build?
Cache the vulnerability database, run fast scans (dependencies, secrets) on every commit while deferring heavy scans (full image, SAST) to main-branch merges, and parallelize independent checks. Only fail the build on actionable findings.
Can a Jenkins scanner catch transitive dependency vulnerabilities?
Yes, if it is a software composition analysis tool. SCA scanners resolve the full dependency tree, including transitive packages, and flag known CVEs. A tool such as Safeguard can surface these transitively and tell you which direct dependency to bump to clear them.