Teams should fail the build when the policy is to block known high severity issues before the image is promoted. That approach works best when the pipeline is protecting production or shared registries, because it forces remediation before release. If the organisation is still maturing, start with reporting, then move to enforcement once teams trust the signal.
What decides whether a Jenkins image scan is a warning or a release blocker?
The decision is usually policy-driven, not tool-driven. If the team is using image scanning to protect production or a shared registry, then the build should fail on the vulnerabilities that the organisation has defined as unacceptable, because the pipeline is acting as a gate. If the process is still immature, reporting-only is often the better first step because it builds trust in the signal before enforcement is added.
That distinction matters because a failed build changes behaviour, while a reported finding only informs it. When the pipeline is a release control, failure should be reserved for issues that are known to be exploitable, high severity, or outside an agreed exception path. When the pipeline is primarily a visibility tool, the priority is reducing noise and proving that the findings are accurate enough to drive later enforcement.
A useful way to frame the choice is whether the pipeline is protecting a downstream trust boundary. A build that feeds production images, shared registries, or release artefacts should treat serious vulnerability findings as a delivery decision, not just a hygiene report. A build that runs early in development can stay advisory longer, especially when the organisation still needs time to tune false positives, image baselines, and exception handling.
For container image security, NIST’s NIST SP 800-190 Container Security is the most directly relevant external control reference because it treats image, registry, and runtime protections as part of one defensive chain. When a build gate is used, the scan result becomes part of that chain of control, not a separate dashboard item. SLSA also helps when teams want to distinguish ordinary vulnerability reporting from release integrity decisions, because provenance and build integrity are what make a “trusted” image worth promoting.
When failing the build is the right control
Fail the build when the scan is part of an enforced policy and the image would otherwise be promoted into an environment where blast radius is material. That usually means production, pre-production that mirrors production closely, or any shared registry that other teams consume from. In those cases, the build gate is doing exactly what it should do, which is stopping known bad artefacts before they become broadly available.
The threshold should be explicit. Many teams start with high severity only, then expand to include vulnerabilities with known exploitation, sensitive packages, or images that exceed an agreed risk score. The key is consistency: a build gate only helps if engineers can predict when it will trigger and what remediation path follows.
- Fail on vulnerabilities that violate a published release policy.
- Fail on images destined for production or shared consumption, not on every local development build.
- Fail when there is no approved exception, compensating control, or time-bound waiver.
NHIMG’s Ultimate Guide to Non-Human Identities is useful here because the same enforcement logic applies when container images or CI/CD tools carry secrets and authentication material. The article’s stat that 96% of organisations store secrets outside secrets managers in vulnerable locations, including code, config files, and CI/CD tools, is a reminder that “report only” can be too weak when the pipeline itself is part of the exposure path.
When reporting only is the better starting point
Use reporting-only when the team is still learning how to interpret findings, when the scanner is noisy, or when remediation ownership is not yet stable. In that phase, failing builds can train developers to ignore the signal, route around the control, or overuse exceptions. Reporting gives you time to establish severity thresholds, suppress bad detections, and measure how quickly teams can fix issues before you turn the control into a hard gate.
Current guidance suggests treating this as a maturity progression. First prove that the scanner is accurate, then prove that teams can respond, and only then make the pipeline block releases. That sequence avoids converting a security control into a productivity tax before the organisation is ready to act on it.
For deeper operational context, the OWASP Non-Human Identity Top 10 helps teams think about secret sprawl, over-privilege, and rotation failures as delivery risks rather than isolated hygiene issues. The NIST Cybersecurity Framework 2.0 is also useful for framing the maturity step from identify and protect into detect and respond, which mirrors the shift from reporting to enforcement in a CI/CD pipeline.
Risk and Threat Considerations
When container image findings are only reported, vulnerable artefacts can still be promoted, copied, and reused across environments. That creates a predictable exposure path, especially when the same image is pulled into production, a shared registry, or downstream deployments that assume the build pipeline has already filtered out known bad content.
Failure mechanism: A reported vulnerability is accepted as informational even though the image still contains a known exploitable component, so the pipeline never stops the release of an artefact that should have been remediated or excluded.
Impact: The organisation can end up distributing a compromised image at scale, increasing the chance of exploitation, emergency patching, and trust loss in the pipeline’s security signal.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authentication Assurance Level | Release gates often protect trusted delivery paths carrying sensitive credentials or artefacts. |
| Recommendation — Set enforcement thresholds for build-time release decisions that protect trusted delivery paths. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Container images can embed secrets and vulnerable components that must be protected before release. |
| DE.CM — Continuous Monitoring | Build scans are a monitoring control used to detect vulnerable images before deployment. | |
| Recommendation — Treat image scanning as part of protecting artefacts before promotion. Monitor image findings continuously and escalate when policy thresholds are exceeded. | ||
| CIS Controls v8 | 2.4 — Address Unapproved Software | Failing risky images blocks unapproved vulnerable components from being promoted. |
| 16.5 — Account Monitoring and Control | CI/CD tools can carry sensitive secrets and need enforced control before release. | |
| Recommendation — Block promotion of images that violate approved software policy. Enforce release controls where pipeline artefacts may expose credentials or sensitive material. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | Container images often contain leaked secrets that justify blocking promotion. |
| NHI-03 — Overprivileged Non-Human Identities | Pipeline artefacts and registries can propagate overly privileged access material. | |
| NHI-06 — Lifecycle and Rotation Gaps | Reported findings should become enforced blockers once remediation and rotation maturity exists. | |
| Recommendation — Fail the build when images expose secrets or authentication material. Prevent promotion of images that would widen privilege or access blast radius. Move from reporting to blocking when remediation and rotation workflows are reliable. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Images and CI/CD outputs can expose credentials that attackers can harvest. |
| T1204 — User Execution | Unsafe release artefacts increase the chance that downstream users execute compromised content. | |
| Recommendation — Detect and block artefacts that contain exposed credentials or secret material. Stop promotion of compromised artefacts before downstream execution occurs. | ||
Practitioner Guidance
Decision rule: If the image is eligible for production, a shared registry, or another downstream trust boundary, define explicit fail conditions and make them consistent. If the build is still being used to learn, report first, but set a deadline for moving the highest-confidence findings into enforcement.
What to verify: Confirm that the scan policy distinguishes severity from exploitability, that exceptions are time-bound, and that the build result is actionable enough for developers to understand what will block promotion. A gate that nobody can predict is usually a gate that will be bypassed.
Practitioner takeaway: Fail builds when the scan is guarding release trust; report only when you are still proving the signal and the remediation workflow. The maturity question is not whether vulnerabilities exist, but whether the pipeline is ready to enforce the organisation’s risk appetite.
Related resources from NHI Mgmt Group
- Why do AI initiatives fail when teams treat them as a shared service desk instead of embedding them in real work?
- How should security teams handle known container image vulnerabilities when patching is delayed or impractical?
- How should security teams respond when AI discovers vulnerabilities faster than humans can patch them?
- How should security teams build board reporting for NHI risk?
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
