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.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “Security that Ships: The ROI of AppSec for Engineering Teams”.
Key questions
Q: What breaks when security findings only surface after the sprint closes?
A: Teams lose the original implementation context, so the fix becomes slower, more expensive, and easier to defer.
Q: Why do high-signal findings get fixed faster than noisy ones?
A: Because developers can act on a credible issue without spending time proving whether it matters.
Q: How do security teams know whether Teams remediation is working?
A: They should measure dwell time, removal latency, and the percentage of malicious messages removed before any user interaction.
Practitioner guidance
- Shift critical findings into pull requests Configure scanning so high-confidence issues appear before merge, when the original developer still has context and can fix the code without reopening the whole design conversation.
- Tune for signal, not just volume Reduce false positives and noisy rules so triage time goes to exploitable issues, not debate over whether a finding is worth tracking.
- Use reachability to prioritise dependency findings Separate vulnerable packages that are actually callable from version-only alerts that do not affect runtime behaviour or exposure.
Bottom line: The article’s central claim is that remediation timing and signal quality matter more than scanning volume when teams are trying to reduce application risk.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:47 pm
Shift-left remediation is really a control-placement problem: security findings only change behaviour when they arrive inside the developer’s active context window. Once findings move into tickets and post-sprint scans, the organisation converts a fixable defect into a coordination problem. The practitioner conclusion is that timing is part of the control, not a secondary detail.
A question worth separating out:
Q: Should organisations prioritise remediation verification over more scan coverage?
A: Yes, when the problem is not discovery but closure. Broader coverage helps only if the organisation can confirm that weaknesses were actually removed. Verification is especially important in fast-moving application and cloud environments, where unconfirmed fixes can recreate the same risk in the next release cycle.
👉 Read our full editorial: Shift-left security remediation outperforms delayed fix workflows