Blocking policies in AppSec: when merge-time enforcement works

At a glance

What this is: This is an analysis of when blocking code merges for security findings improves AppSec outcomes, with the key finding that selective enforcement materially increases remediation rates.

Why it matters: It matters to IAM practitioners because the same governance problem appears in secrets, service accounts, and privileged access workflows: if enforcement is not tied to remediation capacity, risky access and credentials just move into backlog.

By the numbers:

• Leading teams that block PRs on high-risk findings fix 12% more of their vulnerabilities than teams that only monitor.
• 45% of top-performing organizations use at least one blocking policy for SAST findings, compared to 32% of everyone else.
• Teams who block see a fix rate of 55.9% on findings covered by blocking policies, versus 43.6% on non-blocking findings.

👉 Read Semgrep's report on remediation at scale and blocking policies

Context

Blocking policies are a governance choice, not just a tool setting. In application security, the real question is whether a finding is allowed to persist long enough to become normalised, triaged, and eventually ignored. That is the same control tension IAM teams face with secrets, service accounts, and privileged access, where a signal without enforcement often becomes backlog.

Semgrep's analysis frames a practical divide between visibility and action. For identity security programmes, the lesson is broader than code scanning: when high-risk issues are visible but not enforced, teams accumulate exposure windows. That makes selective blocking relevant to NHI governance, privileged access, and any workflow where a risky change should not enter production unnoticed.

Key questions

Q: What breaks when security findings are only monitored and not blocked?

A: Findings that are only monitored often move into backlog rather than into remediation. Over time, that weakens signal quality, increases exposure dwell time, and normalises risky code or credential patterns. Blocking is most effective when the issue is high-confidence, fixable in context, and owned by the team making the change.

Q: Why do blocking policies improve remediation rates in AppSec?

A: Blocking improves remediation because it forces action at the moment risk is introduced, before the issue is buried under competing work. That matters most for hardcoded secrets, injection flaws, and reachable dependency vulnerabilities. When teams are ready to fix what they block, enforcement becomes a governance control rather than just a gate.

Q: What do security teams get wrong about merge-time enforcement?

A: The most common mistake is turning on blocking too broadly before the signal is trusted. That creates noisy refusals, teaches developers to work around the control, and reduces future compliance. A phased rollout, monitor, comment, then selective block, preserves credibility and improves long-term adoption.

Q: How should teams decide which vulnerabilities deserve a hard stop?

A: Use a mix of severity, confidence, reachability, and fix clarity. Hard stops are best reserved for findings that are likely exploitable, well understood, and fixable in the same workflow. That usually means secrets, critical injection paths, and dependency flaws that are demonstrably reachable.

Technical breakdown

How merge-time blocking changes remediation behaviour

A blocking policy works at the point of merge, which is where new risk enters the shared codebase. In practice, this shifts security from after-the-fact review to pre-commit enforcement. The mechanism is simple: scan results are mapped to policy outcomes such as ignore, monitor, comment, or block. Only the highest-confidence, highest-severity findings should reach block mode, otherwise the control becomes noisy and developers learn to route around it.

Practical implication: reserve blocking for findings that have a clear fix path and strong evidence, then measure whether remediation happens inside the same development cycle.

Why reachability matters for third-party dependencies

Blocking every dependency advisory is usually counterproductive because not every vulnerable package is exploitable in context. Reachability analysis narrows the decision to code paths your application actually invokes, which is the difference between an abstract CVE and a real attack path. That distinction matters for supply chain governance because otherwise teams spend enforcement effort on low-signal issues while missing the dependencies that are truly callable from production code.

Practical implication: tie blocking policies to reachability or equivalent evidence so enforcement follows exploitability, not just disclosure status.

Why developer trust determines whether blocking works

Blocking is a social control as much as a technical one. If teams turn it on before the scanner signal is trusted, the policy creates friction without credibility, and developers begin to treat blocked changes as noise. A phased model, monitor first, then comment, then selective block, gives the organisation time to establish false positive rates, tune categories, and build confidence in the signal before enforcement is introduced.

Practical implication: pilot a small set of high-confidence rules before broadening enforcement, and expand only when developers are engaging with the findings rather than bypassing them.

Threat narrative

Attacker objective: The attacker aims to turn an unblocked code change into a durable exploitation path before the organisation resolves it.

1. Entry occurs when insecure code, hardcoded secrets, or a reachable dependency flaw is introduced into a pull request and reaches merge evaluation.
2. Escalation happens when the finding is not blocked, allowing the vulnerable code or credential to enter production and become part of the attack surface.
3. Impact follows when the exposed secret, injection path, or reachable package vulnerability is exploited before remediation reaches the backlog.

NHI Mgmt Group analysis

Selectively blocking high-risk findings is a governance control, not a developer punishment. The useful distinction is not between strict and lenient teams, but between teams that can enforce on evidence and teams that merely observe risk. In identity programmes, the same logic applies to secrets, service accounts, and privileged workflows. If a high-risk credential can enter production without a hard stop, the programme is managing visibility rather than governance.

Backlog absorption is the hidden control failure this report exposes. The report's 90-day remediation cliff shows that delayed action changes the risk profile of a finding, not just its age. That maps directly to NHI and IAM operations, where leaked secrets, stale credentials, and over-privileged accounts become normalised once they sit unresolved. Practitioners should treat dwell time as a control gap, not an administrative delay.

Reachability-based enforcement is the right model for modern application risk. Blocking based only on the presence of a vulnerability creates avoidable friction, especially in dependency-heavy environments. The stronger governance model is to block only when the code path is reachable and the fix is actionable. That approach aligns with least privilege thinking across identity security because it constrains enforcement to the highest-confidence exposure.

Developer trust is a security control in its own right. Selective blocking works because it preserves the credibility of the signal. When teams overuse enforcement, they create the same failure mode seen in poorly tuned identity governance, where users and administrators stop respecting reviews and exceptions. The practitioner conclusion is straightforward: tune for signal quality before expanding enforcement scope.

Blocking policies surface a broader identity-security lesson: unmanaged exposure persists until governance is operationalised. The named concept here is backlog absorption risk, meaning security findings remain alive in the system because nothing forces action at the point of change. For NHI, IAM, and PAM programmes, that is the same problem as standing privilege without expiry. If the control does not interrupt introduction, the risk simply migrates downstream.

What this signals

Blocking is a useful pattern whenever exposure can be prevented at the point of change, but it only scales when the underlying signal is trusted. For identity and NHI teams, that means merge-time enforcement should be reserved for high-confidence cases such as leaked secrets, standing privilege, or reachable automation credentials, not for every low-signal alert.

Backlog absorption risk: when high-risk findings survive the development workflow, they become operational debt rather than just unresolved alerts. That is the same governance problem seen in leaked secrets and unmanaged service accounts, where delay increases exploitability. Teams should pair blocking with lifecycle controls such as the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

The broader signal is that AppSec is moving toward evidence-based enforcement, not blanket gating. That aligns with identity security programmes that increasingly favour least privilege, expiry, and scoped remediation over open-ended exception handling. Where findings are both credible and exploitable, the right control is to stop them entering production until the risk is removed.

For practitioners

• Classify only high-confidence findings for blocking Start with a narrow list of high-risk rules such as hardcoded secrets, confirmed injection flaws, and reachable critical dependencies. Avoid blocking low-severity or informational findings until the team has evidence that enforcement is trusted and repeatable.
• Use reachability before blocking dependency issues Require evidence that the vulnerable code path is actually invoked before a dependency advisory can stop the merge. That prevents blanket enforcement on packages that are present but not exploitable in your environment.
• Pilot monitoring before enforcement Run new rules in monitor and comment mode first, then review false positives, developer response, and remediation patterns before switching a small set of policies to block mode.
• Track remediation age as a control metric Measure how long findings remain unresolved and treat anything approaching the 90-day backlog threshold as a governance escalation, not just an open ticket.
• Align blocking with code ownership and fix paths Ensure the team that can resolve the issue is the team that sees the block, so merge-time enforcement triggers immediate ownership instead of cross-team deferral.

Key takeaways

• Blocking works when it is selective, trusted, and tied to the team that can fix the issue.
• The report shows a clear remediation advantage for high-confidence enforcement, especially when findings are reachable and actionable.
• For identity and NHI programmes, the real lesson is that exposure left in backlog behaves like standing privilege.

Key terms

• Blocking policy: A blocking policy stops a pull request or build from merging when a scan detects a finding that meets predefined risk thresholds. It is a merge-time enforcement control, not a broad rejection of all findings, and it works best for high-confidence issues with a clear remediation path.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Backlog absorption risk: Backlog absorption risk is the tendency for unresolved security findings to persist until they are treated as routine rather than urgent. In practice, the longer a finding stays open, the more likely it is to be deprioritised, normalised, or forgotten before it can be fixed.
• Merge-time enforcement: Merge-time enforcement is the point at which security policy is applied before code enters the shared branch or production path. It is most effective when the control is tied to credible detections, clear ownership, and remediation capacity inside the development workflow.

What's in the full article

Semgrep's full report covers the operational detail this post intentionally leaves for the source:

• The exact scoring and policy model behind its monitor, comment, and block workflow.
• The full breakdown of which findings produced the best fix-rate lift across tens of thousands of repositories.
• The data-backed rollout sequence for moving from visibility to selective enforcement without overwhelming developers.
• The report's broader remediation strategies beyond blocking, including how teams prioritise what to fix first.

👉 Semgrep's full report covers the rollout sequence, policy examples, and remediation data behind selective blocking.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the operational realities of access, lifecycle, and remediation.