Blocking is appropriate when a finding represents a policy breach, a material exposure, or a repeatable risk that should not enter the codebase. Teams should reserve hard stops for secrets, critical vulnerabilities, or unsafe infrastructure changes, while using alerts for lower-severity findings. The goal is to reduce noise and keep enforcement tied to clearly defined security policies.
Why This Matters for Security Teams
Flagging in CI/CD is useful for visibility, but it does not change exposure. Blocking is the right response when a change would create a policy breach, introduce a secret, or move an organisation into an unsafe state that cannot be accepted even temporarily. This is especially important for code paths that touch deployment automation, credentials, or shared infrastructure, where a single merge can propagate risk across many environments. The NIST Cybersecurity Framework 2.0 emphasises outcome-driven risk management, which aligns with using hard stops for high-consequence issues rather than treating all findings equally.
NHIMG research on the Guide to the Secret Sprawl Challenge shows why this distinction matters: once secrets spread into source control, pipelines, and collaboration tooling, remediation becomes slower and more expensive. Security teams often underestimate how quickly a “warning only” event becomes a repeatable incident when developers can merge around it. In practice, many security teams encounter the blast radius only after the bad change has already been deployed, rather than through intentional policy enforcement.
How It Works in Practice
Effective enforcement starts by defining which findings are non-negotiable. Blocking should be reserved for conditions that are clearly unacceptable under policy, such as hardcoded secrets, critical vulnerabilities with known exploitation paths, or infrastructure changes that violate approved guardrails. Everything else can remain a warning, ticket, or review item. The aim is to make CI/CD enforcement predictable enough that developers know when a merge will fail and why.
A practical model is to pair severity with context. For example, a secret in a public repository is usually a hard stop, while a low-confidence scan finding in test code may only justify an alert. Teams can also add exceptions for approved remediation windows, but those exceptions should be time-bound and auditable. The Reviewdog GitHub Action supply chain attack is a useful reminder that CI tooling itself can become part of the attack path, so enforcement logic must be trusted as much as the code it evaluates.
- Block on policy breaches, not on every scanner hit.
- Use severity plus asset sensitivity to decide whether a failure is fatal.
- Require explicit approval for temporary overrides and review them quickly.
- Keep alert-only findings visible so teams still see trend data and recurring patterns.
For broader control mapping, the CI/CD pipeline exploitation case study helps frame why pipeline integrity matters, while NIST Cybersecurity Framework 2.0 supports the idea that enforcement should reduce risk, not simply increase friction. These controls tend to break down when pipelines are overloaded with false positives and teams start bypassing checks to keep delivery moving.
Common Variations and Edge Cases
Tighter blocking often increases delivery friction, requiring organisations to balance release speed against the cost of allowing bad changes to ship. That tradeoff becomes most visible in fast-moving teams, monorepos, and shared platform pipelines where one failing rule can halt many unrelated changes. Current guidance suggests using different enforcement levels for different classes of risk, rather than a single universal gate.
There is no universal standard for this yet, but a consistent pattern is emerging. Secrets, public exploit paths, and changes that weaken access controls should usually block by default. Lower-confidence findings, stylistic issues, and medium-severity vulnerabilities are better handled with alerts or required follow-up tickets. In environments with heavy legacy debt, some organisations start with soft enforcement and gradually raise the bar as scan quality improves.
NHIMG’s Guide to the Secret Sprawl Challenge and the Reviewdog GitHub Action supply chain attack show two important edge cases: not every leak is in application code, and not every unsafe condition is obvious at first scan. That is why policy design should distinguish between “needs attention” and “must not merge.”
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, CSA MAESTRO and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Least-privilege gating fits merge blocking for risky code changes. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Secrets in code are a core NHI exposure that often warrants blocking. |
| CSA MAESTRO | GOV-1 | Governance controls define when autonomous delivery actions must be stopped. |
| NIST AI RMF | Risk management is needed to separate high-impact findings from warnings. | |
| OWASP Agentic AI Top 10 | A03 | Agentic workflows need runtime guardrails when code changes are generated autonomously. |
Classify findings by impact and block only when the change creates unacceptable risk.
Related resources from NHI Mgmt Group
- How do organisations decide whether to import existing CI/CD resources before rebuilding them?
- What breaks when organisations rotate CI/CD secrets without mapping every downstream connection first?
- Who should be accountable for authorization policy changes in CI/CD pipelines?
- When should organisations use prebuilt policy templates instead of writing custom policy code?
