Most application security (AppSec) teams know their OWASP Top 10, the industry-standard list of the most critical software security risks. Fewer know which of those categories their organization actually fixes. In conversations with security teams, I hear the same story: "We prioritize criticals, so the important stuff gets handled." The data tells a different story. Fix rates vary dramatically by OWASP vulnerability class, and not in the ways most teams expect.
The data comes from Semgrep's Remediation at Scale report, which analyzed anonymized remediation patterns across 50,000+ repositories and hundreds of organizations during 2025. The methodology is straightforward: group organizations into two cohorts by fix rate (top 15% as "leaders," remaining 85% as "field"), then compare what each group actually does differently.
The gap between leaders and the field isn't about detection quality or prioritization frameworks. Both cohorts apply the same severity filters and surface the same critical findings. What differs is execution. One organization fixes 63% of its critical findings. Another fixes 13%. Same tools. Same alerts. Different approaches.
The fix rate gaps nobody talks about
When you break Static Application Security Testing (SAST) fix rates by OWASP category, the biggest gaps between high-performing teams and everyone else aren’t in the categories you'd expect.
Authentication Failures (A07) show the largest gap in the dataset: a 48-percentage-point difference between leaders and the field. Leaders fix at nearly 60%, while the field sits at roughly 12%. Cryptographic Failures (A02) follow at a 38-point gap.
These two categories share a trait that may be less apparent from the OWASP label alone: fixing them requires architectural understanding, not pattern replacement.
Consider what an authentication fix actually looks like. You're usually not adding a check on “line 47.” You're tracing session management across middleware, understanding token lifecycle, auditing multi-factor enforcement, and figuring out how credential storage works across service layers. A cryptographic fix may mean migrating from a deprecated algorithm to a modern one across every system that reads the encrypted data. These are usually involved projects, not quick tickets.
SSRF (A10) is one of the only categories where the field outperforms leaders, showing a slightly negative gap. SSRF fixes resist simple patterns because allowlists can be bypassed through DNS rebinding, IP encoding, and cloud metadata endpoints. Both cohorts approach them with similar specialist effort, flattening the gap seen elsewhere.
Injection (A03) sits in the middle at a 23-point gap. The fix itself (parameterized queries instead of string concatenation) is conceptually simple. The challenge is finding every injection point across a large codebase, particularly when untrusted input flows across multiple files before reaching a dangerous sink. More detailed breakdowns in the report reflect this: when a scanner confirms a finding by tracing data flow across files (interfile analysis), leaders fix those findings at 69% versus 43% for single-file findings. This means that when teams see the full path from user input to dangerous sink, they gravitate toward treating it as real work whilst findings without clear data flow evidence get deferred.
The 90-day cliff: when vulnerabilities become permanent
The data also reveals something that, especially to those managing large backlogs, should reframe how you think about aging code security findings.
Findings open for more than 90 days become unlikely to ever be fixed. Among high-performing teams, only 9% of SAST remediations come from the 90+ day backlog. For the field, it's 16%.
Anecdotally, many teams keep an eye on these findings quarter after quarter, waiting for a good time to address them, and that time never comes. If a vulnerability has been sitting in your backlog for three months, the default trajectory is that it stays there. Treat 90 days as an escalation point, not a deadline but a forcing function. At that point, every open finding needs one of three dispositions:
- remediate it with dedicated time
- formally accept the risk with documented justification
- mute it as a confirmed false positive
Letting findings sit indefinitely without a decision is not risk management.
What high-performing teams do differently
The patterns that separate leaders from the field usually involve some kind of workflow configuration, not just tool selection.
If we break code vulnerabilities out by first-party code vulnerabilities (SAST) and vulnerabilities introduced by packages and dependencies (SCA) we can see that there are a number of interesting insights:
PR-level scanning accelerates remediation by 9x, but only if the workflow supports it. 96% of leaders and 95% of field organizations already run SAST and SCA scans on pull requests (the code reviews developers open before merging changes). PR scanning adoption is not the differentiator. What differs is whether findings are actionable at PR time. Leaders resolve PR-detected SAST findings in 4.8 days on average; the same class of finding from a full scan takes 43 days. Among leader organizations, 63% of PR-detected fixes happen same-day. This makes sense when you think about the developer's experience: they're already in the code, the context is fresh, and the fix ships in the same PR with no ticket or reassignment required.
Blocking rules drive the highest fix-rate lift in the dataset. Organizations that configure specific high-confidence rules to block PR merges see measurable results: leaders gain a 12-percentage-point improvement in SAST & SCA fix rate; the field gains 5 points. Why such a disparity? The difference is that leaders have built the downstream workflow to support a blocked merge: the developer knows what to fix, the fix path is unambiguous, and the block isn't treated as noise to override. They restrict blocking to rules where that's true (hardcoded secrets, SQL injection via string concatenation, missing authentication on sensitive endpoints) and avoid blocking on rules with high false positive rates.
Reachability analysis transforms SCA prioritization. The dataset doesn’t just include SAST findings, it also includes findings related to 3rd party packages thanks to Semgrep Supply Chain. For dependency vulnerabilities, knowing a package contains an exploit versus knowing whether your code base actually calls the vulnerable function within the package changes behavior. Leaders fix reachable SCA findings at 92% versus 67% for non-reachable findings. This signal cuts through dependency alert fatigue by separating what's technically present from what's actually exploitable.
Where to start
If you're trying to benchmark your own program, the report offers a simple diagnostic: look at your critical SAST fix rate. If it's below 50%, the problem likely isn't detection quality. Something between detection and remediation is broken. In my experience, it's usually one of three things: findings aren't reaching developers with enough context, there's no clear owner for each finding, or there's no escalation path for aging issues.
The full Remediation at Scale report from Semgrep includes fix rate analysis by CWE (Common Weakness Enumeration, a finer-grained classification than OWASP), ecosystem-specific data across several package managers, and a prioritized set of recommendations organized by implementation timeline.
About the Author: Braden Riggs brings a data scientist’s eye to product marketing. As Technical Product Marketing Manager at Semgrep, he operates at the crossroads of AI, security, and the tools developers actually use.
Braden Riggs — Technical Product Marketing at Semgrep https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEia91JksEFkvNTF_XDKI3thZBBLYRmXQ8ZOvmE8c85r5FvXMfkInjljZ1k3MtVTcUITjrEf_iKUgS_Abeg9Y1tPuXsN54YO4jAba_yI_1xgLBoio9527QrippSjflaeL6hyphenhyphengR4FIac6WsoIcGVBHssv21MZjFFBd8KHojdLd7iY2Ir2dG3tVzhxbQQF3-8/s1600/Braden.png
