Notifications
Clear all
Topic starter
02/08/2026 11:49 am
TL;DR: Teams using blocking policies for high-risk findings fix 12% more vulnerabilities, and 55.9% of findings covered by blocking rules are remediated versus 43.6% for non-blocking findings, according to Semgrep's Remediation at Scale report. Enforcement only works when organisations are ready to act on the signal, not just surface it.
NHIMG editorial — based on content published by Semgrep: Remediation at Scale and blocking policies for AppSec teams
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Use reachability before blocking dependency issues Require evidence that the vulnerable code path is actually invoked before a dependency advisory can stop the merge.
- 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.
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.
👉 Read Semgrep's report on remediation at scale and blocking policies →
Blocking policies in AppSec: are your merge controls keeping up?
Explore further
02/08/2026 12:59 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Blocking policies in AppSec: when merge-time enforcement works
