Verizon's 2025 Data Breach Investigations Report found that exploitation of vulnerabilities as an initial-access vector rose to 20% of breaches, up 34% year-over-year, and that for edge devices and VPNs specifically — the fastest-growing target in that vector, up from 3% to 22% of breaches year-over-year — only about 54% of known vulnerabilities were fully remediated within the year studied, with a median remediation time of 32 days. Espionage-motivated attackers used vulnerability exploitation as their initial access method 70% of the time. None of this is a story about developers not knowing vulnerabilities exist. Security teams have shipped findings into backlogs for a decade. The gap is between "flagged" and "fixed," and it is measured in weeks, not minutes. Meanwhile GitHub's own telemetry from its Copilot Autofix public beta showed the opposite pattern is achievable: when a fix arrives inline, at PR time, with working code attached, median time-to-commit dropped to 28 minutes versus 1.5 hours for manual remediation of the same class of alert. This post is a playbook for closing that gap — not through more mandates or more training slides, but through incentives, tooling placement, and metrics that make the secure path the fast path.
Why do secure coding programs fail even when developers know the rules?
They fail because knowing a rule and acting on it inside a sprint are different things, and most programs only invest in the first. A finding that surfaces in a separate dashboard, days after the code was written, competes against a developer's current task, not the one that produced the bug — the mental context is gone, and reproducing it costs real time. Verizon's 2025 DBIR data illustrates the downstream effect at scale: for edge devices and VPNs, a 32-day median remediation time and a sub-55% one-year fix rate are not consistent with a workforce that lacks rules; they're consistent with friction that consistently loses to shipping pressure. Programs that lean on quarterly training or a security champion newsletter add awareness without removing that friction, so the backlog keeps growing at roughly the rate new code ships. The fix isn't a better rulebook — it's making the fix path as fast as the code path it interrupts.
Does putting fixes at PR time actually change behavior?
Yes, and GitHub has published data quantifying it. During the Copilot Autofix public beta (May–July 2024, measured across CodeQL alerts on repositories using GitHub Advanced Security), the median time to commit an autofix at PR time was 28 minutes versus 1.5 hours to resolve the same alert class manually — roughly 3x faster overall. The gap widened for specific vulnerability classes: cross-site scripting fixes landed in a median 22 minutes versus about 3 hours manually (7x), and SQL injection fixes landed in 18 minutes versus 3.7 hours manually (12x). Optum, cited by GitHub as a customer case study, reported a 60% reduction in time spent on security-related code review alongside a 25% productivity increase after adopting Autofix. The mechanism is simple: a suggested, reviewable patch removes the research step (understanding the vulnerability class and writing the correct fix) that consumes most of a manual remediation's time, leaving only review and commit.
What incentives actually move the needle beyond tooling speed?
Speed removes friction, but incentives determine whether a fast fix path gets used consistently. Programs that tie a small, visible portion of engineering-team metrics to open critical/high findings — not raw finding count, which punishes teams for scanning more thoroughly — avoid the classic failure mode where teams quietly disable or ignore a scanner to protect a dashboard. Gating merges on severity thresholds rather than zero-findings policies keeps the bar achievable: a policy of "block on CWE-89 or CWE-502 above a defined severity" is something a team can hit every sprint, where "zero findings" pushes teams toward suppression comments instead of fixes. None of this works without executive-level backing that treats a blocked merge as a normal part of the pipeline rather than an escalation. The teams that sustain secure coding practices over multiple quarters are consistently the ones where the policy is enforced automatically in CI, not the ones relying on a reviewer remembering to ask about it.
What should a team actually measure to know a program is working?
The two numbers that map most directly to real breach risk are mean/median time-to-remediate for confirmed, reachable findings, and the percentage of critical/high findings still open past a defined SLA — both drawn straight from the pattern Verizon's DBIR data shows correlates with breach outcomes. Raw finding counts and scan coverage percentages are useful operationally but don't predict risk on their own; a team can run scans on 100% of repositories and still carry a remediation time in the same range as the DBIR's 32-day edge-device median if nothing routes findings into the actual PR workflow. Tracking reachable findings specifically — rather than every finding a scanner emits — also keeps the SLA metric honest, since a fix-time clock that includes unreachable, low-priority noise produces numbers that look worse than the real exposure and trains teams to distrust the dashboard. A program with a shrinking median remediation time and a shrinking backlog of SLA-breached criticals is demonstrably reducing the exploitation window attackers rely on — the same window the DBIR ties to a fifth of all breaches.
How Safeguard Helps
Safeguard's application security testing is built around the same principle these numbers point to: findings only change behavior when they arrive where developers already work, with enough context to act on immediately. SAST and DAST findings — a capability that's actively rolling out, with platform wiring, CI/pipeline/local-runner integration, and the unified findings model in place today while detection depth continues to expand — share one correlation model, so a DAST-confirmed runtime issue is linked to the exact SAST source-code sink that caused it, letting teams prioritize the small set of findings that are both real and reachable instead of triaging noise. Findings can gate CI directly through Safeguard's guardrails enforcement, so a severity-based merge policy runs automatically rather than depending on a reviewer's memory, and the CLI ( safeguard appsec sast , safeguard findings list --engine sast --severity high ) puts the same query surface engineers use locally into the hands of whoever owns the remediation SLA metric. The goal isn't a longer findings list — it's a shorter time between a vulnerability entering the codebase and leaving it.