Notifications
Clear all
Topic starter
02/08/2026 11:33 am
TL;DR: SAST findings fixed in pull requests were resolved in 4.8 days on average versus 43 days when they surfaced after the sprint, according to Semgrep’s analysis of 50,000 active repositories, while leaders also fixed 39.6% of findings compared with 16.8% for the rest of the field. Early signal quality and workflow placement drive remediation ROI more than tool volume does.
NHIMG editorial — based on content published by Semgrep: Remediation at Scale and the patterns that improve security fix rates
By the numbers:
- Leading teams fix 39.6% of SAST findings while everybody else averages 16.8%, a 2.4x advantage.
- The same class of vulnerabilities, caught in a full scan after the sprint closes and code ships, is 43 days.
Questions worth separating out
Q: How should security teams reduce the time it takes to fix code security findings?
A: Put the finding in front of the developer while the change is still fresh.
Q: Why do some teams fix security findings much faster than others?
A: The difference is usually workflow design, not developer effort.
Q: What breaks when security findings are left unresolved for too long?
A: They stop behaving like actionable defects and start behaving like organisational debt.
Practitioner guidance
- Move security findings into pull-request workflows Place the first meaningful security check where developers still own the code context.
- Tighten rules for precision, not alert volume Review findings that routinely trigger manual triage and remove low-confidence rules, noisy patterns, and non-production paths.
- Adopt reachability analysis for dependency issues Prioritise third-party findings that can be traced to real code paths.
What's in the full report
Semgrep's full report covers the operational detail this post intentionally leaves for the source:
- Cohort methodology for defining Leaders by fix rate and comparing remediation performance across 50,000 repositories
- Rule-tuning and workflow examples for reducing false positives before they reach engineering teams
- Language-by-language tool coverage patterns across polyglot repositories and monorepos
- Benchmark breakdowns that show how timing, reachability, and signal quality affect remediation outcomes
👉 Read Semgrep's analysis of remediation performance across 50,000 repositories →
Shift-left security remediation: are your fix workflows keeping up?
Explore further
02/08/2026 12:47 pm
Shift-left remediation is really a context-retention strategy. The article shows that the advantage of pull-request findings is not merely earlier detection, but preserving the developer’s working memory at the moment a defect is easiest to fix. That same governance principle applies to NHI and IAM workflows, where delayed review of service accounts, secrets, or access exceptions turns routine control work into archaeology. The operational conclusion is simple: the closer the control sits to the change event, the higher the remediation rate.
A question worth separating out:
Q: How should teams decide which security findings to fix first?
A: Prioritise findings that are both reachable and tied to active code paths. A raw alert list is not enough because many issues will never be exploitable in practice. The best triage model combines severity with code-path evidence, so engineering time goes to defects that can actually affect production risk.
👉 Read our full editorial: Shift-left security remediation outperforms delayed fix workflows
