Verizon's 2025 Data Breach Investigations Report puts the human element — error, social engineering, or misuse — in roughly 60% of confirmed breaches, a share that has held steady year over year despite a decade of mandatory security-awareness training. That persistence is the uncomfortable starting point for this post: most organizations already run some form of secure coding training, and it is not, by itself, moving the number. OWASP has spent years formalizing a different answer. Its Software Assurance Maturity Model (SAMM) treats "Training and Awareness" and "Organization and Culture" as explicit, scorable maturity streams under a Governance domain, and its Developer Guide project publishes a dedicated Security Champions Guide describing how to embed security ownership directly inside engineering teams rather than bolting it on from outside. The pattern that emerges from that body of work is consistent: training changes what people know, champions programs change who is accountable day to day, and incentives change what gets rewarded — and a program that only does the first of these three is the one still showing up in next year's DBIR statistics. This piece walks through how to design all three so they reinforce each other, what OWASP's own maturity framework says about measuring the result, and where tooling like training-completion telemetry fits into the evidence trail.
Why doesn't security-awareness training alone move the breach numbers?
Training alone doesn't move the numbers because a once-a-year module tests recall, not behavior under deadline pressure — and the human-element share of breaches in the Verizon DBIR has stayed roughly flat across multiple report cycles even as awareness-training adoption has grown. Verizon's own 2025 dataset attributes the human element to three distinct failure modes: error (misconfiguration, misdelivery), social engineering, and misuse of legitimate access — and generic secure-coding training addresses only a fraction of that surface, since it rarely touches configuration discipline or credential handling under time pressure. OWASP SAMM's response is to separate "Training and Awareness" from a second, harder stream called "Organization and Culture," on the premise that knowledge transfer and behavioral incentive are different maturity problems requiring different interventions. In practice this means a training completion rate is a leading indicator at best; it tells you people sat through content, not that they apply it when a sprint deadline and a security control are in tension.
What is a security champions program, concretely?
A security champions program, as OWASP's Developer Guide defines it, embeds one champion per development team as a liaison to the central security organization, given explicit weekly time allocation for security work rather than an unfunded volunteer role bolted onto their existing sprint capacity. The champion attends recurring security briefings, receives additional training beyond what their teammates get, and carries context back to their own team in both directions — surfacing security requirements early in design, and surfacing real friction points back to the security org. OWASP states two explicit goals for the model: increasing the effectiveness and compliance of the AppSec program, and improving the working relationship between security and development so that security stops being an external gate. Critically, OWASP's guidance is explicit that the model requires structured management buy-in and support — without it, champions burn out carrying security work on top of an unchanged delivery workload, and the program collapses within a few quarters.
How do you fund a champions program so it doesn't burn people out?
You fund it by treating the champion's security time as a line item in their actual capacity plan, not as goodwill layered on top of a full sprint — which is precisely the failure mode OWASP's guidance warns produces burnout and program collapse. That means a champion's manager, not just the security team, needs to sign off on the weekly allocation, and that allocation needs to survive the first roadmap crunch it competes against — a program that quietly evaporates under deadline pressure teaches the whole organization that security is optional. Structurally, this is also why OWASP frames champions as a liaison role with two-way traffic: the champion should be bringing real friction (a scanner that's too noisy, a control that blocks a legitimate workflow) back to the security org, not just pushing security requirements downstream. A champions network that only broadcasts outward from security stops being a culture program and becomes an enforcement arm, which undermines the second of OWASP's two stated goals — the relationship between security and development.
What incentives actually change day-to-day developer behavior?
Incentives change day-to-day behavior when they're visible in the same systems developers already use for performance and recognition — pull request review, sprint retros, and promotion criteria — rather than existing as a separate, easily ignored recognition track. Concretely, this means treating a clean secure-code review, a self-reported near-miss, or a fix for a champion-flagged issue as material worth citing in a performance review, the same way a shipped feature is, instead of leaving security contributions invisible to the process that actually determines career progression. OWASP's Organization and Culture stream is explicit that incentive alignment, not just training delivery, is part of the maturity model an organization should be scored against — a team can have excellent training content and still score low on this stream if secure behavior is never recognized or rewarded anywhere developers can see it. The failure pattern to avoid is a security-only incentive (a champion badge, a leaderboard) that has zero connection to compensation, staffing decisions, or manager evaluation — OWASP's guidance ties long-term program survival to genuine management buy-in, and an incentive with no teeth is one that competes with deadline pressure and loses.
How do you measure whether a secure coding culture program is actually working?
You measure it against OWASP SAMM's own maturity axes rather than inventing a bespoke scorecard, because SAMM already defines "Training and Awareness" and "Organization and Culture" as separate, assessable streams with defined maturity levels an organization can self-score against over time. That gives you two independent signals instead of one: a training stream score that reflects whether the right people are getting the right content, and a culture stream score that reflects whether the organizational structure — funded champion time, management buy-in, incentive alignment — actually exists to make that content actionable. A program that only tracks training completion percentages is measuring one SAMM stream and calling it the whole picture, which is exactly the trap that keeps the DBIR's human-element share flat. Re-scoring both streams on a fixed cadence, and treating a stalled culture-stream score as seriously as a stalled training-completion number, is what turns SAMM from a one-time assessment into an actual operating cadence.
How Safeguard helps
Safeguard doesn't run your training content or staff your champions network — those are organizational commitments no platform can substitute for. What Safeguard does is give a security team one place to see whether the training layer of the program is actually happening: its connector catalog includes a dedicated Security Training category covering platforms like KnowBe4, SecureFlag, Immersive Labs, Living Security, Hoxhunt, Pluralsight, and Coursera for Business, so completion and enrollment signals from whichever training vendor an engineering org already uses can be pulled into the same evidence pipeline as code-level findings and SOC 2 controls. That matters for exactly the measurement gap described above — a security team relying on champions and incentives to close the human-element gap in the DBIR needs to know, with real data rather than a self-reported spreadsheet, whether the training stream of their SAMM program is current, and Safeguard's connector layer gives that a live, queryable answer alongside the rest of the compliance and AppSec picture.