In Q1 2026, a mid-size fintech we spoke with hit 100% completion on its annual secure coding training — every one of its 340 engineers clicked through the modules, passed the quiz, and got the compliance checkbox for their SOC 2 audit. Four months later, a routine SAST scan on a new payments microservice flagged a SQL injection vulnerability in code written by an engineer who had scored 100% on the injection-attacks module three weeks earlier. This isn't an outlier. It's the norm. Security teams have spent a decade treating training completion as a proxy for security posture, and the data keeps saying it isn't one. Completion rates measure attendance, not behavior change — and the gap between the two is where breaches live. This post looks at why the metric persists, what actually predicts secure coding behavior, and how to measure the thing you actually care about.
Does higher training completion actually correlate with fewer vulnerabilities?
No — the correlation is weak enough that several security teams have stopped reporting it as a KPI. Verizon's 2023 Data Breach Investigations Report found the human element was a factor in 74% of breaches, a number that has barely moved even as mandatory security awareness training has become near-universal across regulated industries. Compliance frameworks like SOC 2, ISO 27001, and PCI-DSS require documented training, so completion rates at large enterprises routinely sit at 95-98%. Meanwhile, Veracode's State of Software Security research has repeatedly found that roughly a third of applications carry high-severity flaws that persist for over a year, and that the same OWASP Top 10 categories — injection, broken access control, cryptographic failures — show up scan after scan, year after year, at organizations with mature, fully-completed training programs. If completion drove behavior, that recurrence rate should be trending down. It isn't. The honest read is that training completion and secure coding outcomes are two different curves that happen to share an owner (the security team) but not a causal link.
Why does compliance-driven training fail to change what developers actually do?
Because it's designed to produce a completion record, not a habit, and those are optimized differently. A once-a-year, 45-minute module built to satisfy an auditor is written for breadth and defensibility — it needs to cover the OWASP Top 10, insider threat, phishing, and password hygiene in one sitting so the org can point to it during an audit. It is not written to change what an engineer does at 4:47pm on a Thursday when they're closing a ticket and reach for String.format() to build a SQL query instead of a parameterized statement. Behavioral science on skill retention (the forgetting curve research popularized by Ebbinghaus and repeatedly confirmed in corporate learning studies) shows that people lose 50-80% of new information within a month without reinforcement or application. Annual training has, by design, eleven months of no reinforcement between sessions. A developer who watched a video on injection attacks in January is not meaningfully different in March than a developer who never watched it, because the video was never connected to the fifteen pull requests they merged in between.
What do developers actually retain from a typical training module?
Mostly the answer to the quiz question, not the underlying pattern. Most LMS-delivered security training is assessed with multiple-choice quizzes that test recall of a specific scenario ("which of the following is an example of a broken access control vulnerability?") rather than the ability to recognize the pattern in unfamiliar code. This is a well-documented gap in instructional design known as the transfer problem: training that teaches to a specific example doesn't generalize to novel situations, which is exactly what a developer faces every time they touch a new codebase, a new framework, or someone else's PR. A 2022 SANS survey of security awareness professionals found that fewer than a third of organizations measure any form of behavior change after training — most stop at completion tracking or, at best, a post-training quiz score. Without a mechanism that puts the concept in front of the developer at the moment they're writing code, the training becomes an isolated event with no path back into the actual workflow where the decision gets made.
Does gamification or phishing-style simulation fix the problem for secure coding?
Partially, and only when it's applied to code, not just to inbox behavior. Phishing simulations work — industry data from vendors like KnowBe4 consistently shows click-through rates dropping from around 30% on a first simulated phish to under 5% after repeated, spaced simulations — because they inject a realistic decision point into the employee's actual workflow (their inbox) and give immediate feedback when they get it wrong. That's the mechanism that's missing from most secure coding training: there's no equivalent "simulated phish" for a pull request. A few organizations have started running internal capture-the-flag exercises or vulnerable-code challenges, and these do move the needle more than video modules — but they're typically run quarterly at best, cover a handful of engineers, and still happen outside the IDE and outside the CI pipeline where real code actually ships. The lesson from phishing simulation isn't "gamify the training," it's "move the intervention into the real workflow and make the feedback loop immediate." Secure coding training rarely does either. This is exactly where a secure coding training platform earns its keep or fails: if it can't put a relevant lesson in front of a developer inside the pull request they're currently writing, it's just another LMS module competing with a deadline.
What should security teams measure instead of completion rates?
Vulnerability recurrence and time-to-remediation by engineer and by team, not who clicked "finish." Completion rate answers "did the training happen." The questions that actually matter are: are the same vulnerability classes reappearing in code from the same teams after training was delivered; is the average time to fix a flagged issue going down; and is the ratio of vulnerabilities caught in code review versus caught in production shifting left over time. These are measurable directly from your SAST/SCA scan history, PR review data, and ticket systems — no LMS required. A team that completes training but keeps introducing the same hardcoded-secret pattern in every third PR has a training program that isn't working, regardless of what the completion dashboard says. Conversely, a team with mediocre training attendance but a steadily dropping recurrence rate on injection flaws is probably getting reinforcement from somewhere else in the pipeline — code review comments, static analysis feedback, a senior engineer's mentorship — and that's the signal worth investing in. The uncomfortable implication is that most security teams are reporting the wrong number to their board, because it's the easy number to get out of an LMS.
How Safeguard Helps
Safeguard is built around the idea that secure coding behavior should be measured — and reinforced — where the code actually gets written, not in a once-a-year training portal. Instead of tracking completion checkboxes, Safeguard continuously scans your software supply chain (dependencies, build pipelines, and source repositories) and correlates findings back to the specific commits, PRs, and contributors that introduced them. That gives security and engineering leaders a real behavioral signal: which vulnerability classes are recurring on which teams, whether time-to-remediation is trending down after an intervention, and where the same risky pattern — a hardcoded credential, an unpinned dependency, an unsigned artifact — keeps showing up despite training having been "completed."
Because Safeguard sits in the CI/CD pipeline and integrates with your SCM, findings surface at the moment of the pull request rather than eleven months later on a compliance dashboard. That's the same principle that makes phishing simulations effective: feedback delivered inside the real workflow, immediately after the decision, is what changes behavior — not a quiz score filed away for an auditor. Teams using Safeguard can replace "percentage of engineers trained" with metrics that actually correlate with risk reduction: recurrence rate by vulnerability class, mean time to remediate by team, and drift in dependency and build provenance over time. For organizations that still need to satisfy SOC 2 or ISO 27001 training requirements, Safeguard doesn't replace that documentation — it gives you the evidence that the training is actually working, or the data to show your security leadership where it isn't, before that gap turns into the next production incident.