Code Security Remediation: What 50,000 Repositories Reveal About PR Scanning

Security teams have gotten good at finding vulnerabilities. Fixing them has always been the hard part. An analysis of remediation patterns across 50,000+ actively developed repositories and 400+ organizations during 2025 reveals a pattern: where a vulnerability is detected has more impact on whether it gets fixed than what the vulnerability is.

PR-Detected Findings Get Fixed 9x Faster

Static Application Security Testing (SAST) tools scan your source code for security flaws like SQL injection, hardcoded secrets, or missing auth checks. When a scan flags one of these issues (a "finding"), how quickly it gets fixed depends almost entirely on when it was detected. Findings caught during a pull request (PR) are resolved in 4.8 days on average. The same class of finding detected via a full repository scan takes 43 days. That is a 9x difference, and the reason is context.

Consider what the PR workflow looks like in practice. A developer opens a PR. A scan runs automatically in CI, and a finding appears as an inline comment: "SQL injection via string concatenation on line 47." The developer is already in that file. The context is fresh. The fix is two lines:

# Before — vulnerable
query = "SELECT * FROM users WHERE name = '" + username + "'"

# After — parameterized
query = "SELECT * FROM users WHERE name = ?"
db.execute(query, [username])

63% of PR-detected SAST fixes happen the same day.

Now consider the full-scan path. Three months later, a different developer is assigned a Jira ticket for the same class of vulnerability in code written by someone else two years ago. They have to locate the file, rebuild context around unfamiliar code, figure out the right fix, and push it through review. That ticket competes with feature work, and it often sits in the backlog for weeks.

The pattern holds for dependency vulnerabilities too, though the gap is smaller. Software Composition Analysis (SCA) findings caught in a PR are resolved in 12.1 days versus 36.4 days for full-scan findings, a 3x improvement. The smaller gap reflects reality: SCA remediation depends on whether a patch exists upstream, which is outside the developer's control.

This is not an argument against full scans. PR scanning depends on full scans to establish the baseline that makes diff analysis possible. And some vulnerability classes, particularly cross-file issues where untrusted input enters one file and reaches a dangerous sink in another, require the full codebase context that only a full scan provides. You need both. But the data makes clear that when a finding can be caught at PR time, it is far more likely to get fixed.

The 90-Day Cliff

Security findings that sit unfixed for 90 days do not get fixed. Teams tell themselves the backlog is temporary, that they will get to those findings next sprint. They rarely do.

After 90 days, the original developer may have moved on. The code may have been refactored around the vulnerability. The organizational memory of why this finding matters has faded. What was once a 20-minute fix is now a research project, and research projects lose to feature work every time.

Among top-performing organizations (the top 15% by fix rate), only 9.4% of SAST remediations come from findings open longer than 90 days. For the remaining 85%, it is 16%. Leaders are not just fixing more; they are fixing earlier. And the most counterintuitive part: these groups use the same scanning tools. One organization fixes 63% of its critical findings. Another fixes 13%. Same scanner. Same severity filters. Same findings surfaced. The difference is what happens after the scan.

In my experience talking to security teams, the gap comes down to three things. Findings sit in a security dashboard that developers never check. Findings reach developers, but without enough context to understand the fix. Or there is no clear owner, so the finding is effectively unassigned.

Treat 90 days as an escalation point, not a deadline. At that threshold, every open finding should go through one of three paths: remediate it with dedicated time, formally accept the risk with documented justification, or suppress it as a confirmed false positive. Letting findings sit in the backlog indefinitely without a decision is not risk management.

Two Diagnostics to Prioritize

Measure your same-day PR fix rate. What percentage of findings detected in PRs get resolved the same day? If it is below 50%, developers are seeing findings but not acting on them. That points to a context problem: the finding does not include enough information to act on, or the developer does not feel ownership over security findings in their code. Leaders hit 63%.

Check your 90-day backlog share. What percentage of your total open findings have been sitting for more than 90 days? If a significant portion of your remediations comes from that bucket, your team is spending effort on findings that have already crossed the threshold where fixes are unlikely. PR scanning, CI policies that block merges on high-confidence findings, and faster triage loops all move fixes into the first 30 days, where they are most likely to happen.

The dataset behind these benchmarks, including fix rate analysis by OWASP category, specific CWEs, package ecosystem breakdowns, and time-to-fix distributions, comes from the Remediation at Scale report. Dig into the full dataset to see how your numbers compare.

Check out the full Semgrep article collection here.