Security teams should treat image scanning as a build stage, not a separate afterthought. Embed the scanner in the pipeline or freestyle job, set clear severity thresholds, and decide in advance which findings fail the build. That keeps feedback close to the change, reduces manual review, and makes vulnerability control part of normal delivery rather than an exception process.
Why image scanning belongs inside the Jenkins build itself
Image vulnerability scanning works best when it is treated as a build-quality control, not a separate security review step at the end of delivery. In Jenkins, that usually means running the scanner in the same pipeline stage that builds or packages the container image, then deciding immediately whether the result is informational, warning-only, or a hard failure. The closer the scan is to the build event, the less context switching and rework the team creates.
The practical advantage is not just earlier detection. It is also consistency: every build gets the same scan, the same policy, and the same escalation path. That helps teams avoid “we will scan it later” drift, where images move through environments before anyone checks whether they contain known vulnerabilities. For container-specific guidance, NIST SP 800-190 Container Security is a strong reference for treating the image, registry, and runtime as connected risk points.
Teams also need to think about build performance. Scanning every layer at full depth on every commit can become noisy and slow, so the more durable pattern is to tune the scan for developer feedback first and deep analysis second. Fast checks should gate the common path, while heavier checks can run on merge, release, or nightly builds if the repo and delivery cadence justify it. That keeps delivery moving without turning vulnerability management into an after-hours batch process.
How to set thresholds without creating a delivery bottleneck
The core control is not “scan or do not scan”, it is “which findings should block progression.” Security teams should define severity thresholds, package ownership rules, and exception handling before the pipeline is live. If every medium finding fails every build, developers learn to ignore the tool. If nothing ever fails, the scan becomes theatre. The right balance usually fails only on issues that are exploitable, high confidence, and relevant to the image actually being delivered.
That policy should also distinguish between newly introduced vulnerabilities and inherited ones. A build gate that blocks on every pre-existing finding can stall delivery on legacy images and create pressure to bypass the control. A more workable approach is to fail the build when a new image introduces unacceptable risk, while tracking older issues through remediation backlog, time-bound exceptions, or separate release criteria. Supply-chain guidance such as SLSA is useful when teams want to connect build integrity and artifact trust, even though image scanning itself remains a vulnerability-management control.
Where teams need a broader operational baseline, CIS Controls v8 supports the underlying discipline of vulnerability management, secure configuration, and asset awareness. For organisations that need a maturity path rather than a single pipeline rule, OWASP SAMM helps frame scanning as part of a repeatable secure delivery practice rather than an isolated tool decision.
What usually slows Jenkins down, and how teams keep feedback fast
Most build slowdowns come from three places: overly broad scanning scope, repeated scanning of unchanged artifacts, and long queues caused by synchronous failure handling. The fix is to make the scan stage narrowly targeted, cache where the scanner supports it, and separate the policy decision from the raw scan execution where possible. Teams often get better delivery performance by scanning the newly built image once, rather than rescanning every upstream dependency at every stage.
Another common mistake is forcing the same scan depth for all branches and all use cases. A feature branch usually needs fast feedback on obvious issues, while a release branch may justify deeper inspection or stricter policy. That is where pragmatic tuning matters: scan early enough to catch problems before promotion, but not so expensively that developers start batching changes just to avoid the build. If your organisation also depends on good artifact hygiene, NHI Lifecycle Management Guide is useful for understanding how scanning, visibility, and rotation fit into broader control hygiene.
One relevant data point from NHI Mgmt Group’s Ultimate Guide to Non-Human Identities is that 96% of organisations store secrets outside secrets managers in vulnerable locations, including code and CI/CD tools. That matters here because Jenkins jobs often touch the same build artifacts, environment variables, and credential paths that scanners are trying to protect. A vulnerable pipeline can expose both images and the secrets used to build or sign them.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 7 — Continuous Vulnerability Management | Image scanning is a vulnerability-management control in the build pipeline. |
| CIS Control 16 — Application Software Security | Container images are software artifacts that need secure build-time checks. | |
| CIS Control 4 — Secure Configuration of Enterprise Assets and Software | Image scanning helps catch insecure packages and configuration states before deployment. | |
| Recommendation — Embed image scanning into the CI workflow and enforce remediation or risk acceptance for material findings. Gate releases on build-time verification of software artifacts and fix issues before promotion. Validate build outputs for insecure software composition and configuration before release. | ||
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | Embedding scanning into Jenkins is a repeatable protection process. |
| DE.CM — Continuous Monitoring | Pipeline scanning provides ongoing monitoring of build artifacts for vulnerabilities. | |
| RS.MI — Mitigation | Thresholds and exceptions define how the team responds to scan findings. | |
| Recommendation — Standardize image scanning as part of normal delivery procedures and enforce consistent gate criteria. Continuously monitor container images during build and promotion for emerging vulnerabilities. Use defined thresholds to trigger mitigation actions for newly introduced critical image vulnerabilities. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Build pipelines often rely on authenticated automation and credential handling. |
| Recommendation — Use strong authenticated access for Jenkins and its scanner integrations. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Pipeline and registry access should be explicitly validated and minimized. |
| Recommendation — Constrain Jenkins-to-registry access and verify every build-time trust path. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Jenkins builds often interact with secrets that must not be left in images or job configs. |
| Recommendation — Keep build credentials out of images and rotate any secrets exposed during pipeline execution. | ||
Practitioner Guidance
What to verify: Confirm that the scanner runs on the actual built image, not just on source code or a stale cached artifact. Also verify that the pipeline decision is deterministic: the same finding should produce the same build outcome, regardless of who triggers the job.
Decision rule: If a finding is new, high confidence, and clearly exploitable in the image you are about to ship, fail the build. If it is inherited, low confidence, or already covered by a documented exception, route it into remediation tracking instead of blocking delivery indefinitely.
What good looks like: Developers get fast, consistent feedback in the Jenkins job they already use, security gets a predictable gate on material risk, and release teams do not need a separate manual review for every image. The control should reduce surprises, not create a parallel approval queue.
Practitioner takeaway: The objective is to make scanning routine enough that teams trust it, but selective enough that it only interrupts delivery when the vulnerability materially changes the release risk.
Related resources from NHI Mgmt Group
- How should security teams build AI systems to meet EU AI Act requirements without slowing delivery too much?
- How should security teams embed secret detection and vulnerability scanning into developer workflows without slowing releases?
- How should security teams add approval gates to infrastructure changes without slowing delivery too much?
- How should federal security teams implement segregation of duties in DevSecOps pipelines without slowing delivery too much?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
