Standard corporate security awareness training is written for accounts payable clerks, not engineers. Forcing developers through annual phishing drills and 45-minute videos on password hygiene drains goodwill without moving the needle on supply chain risk, which is where engineers actually have leverage. The programs that work are built specifically for engineers, taught by peers, focused on the decisions they make daily: which package to add, which PR to merge, which base image to pull. We built this curriculum at a fintech with 620 engineers after the generic annual training scored 34% on post-test retention and the engineering VP openly complained about it in a town hall. Two years later, the supply-chain-specific developer curriculum scores 78% on retention, engineers request additional modules voluntarily, and we can measure behavior change in actual PRs. What follows is the curriculum, the delivery cadence, and the metrics that distinguish real awareness from compliance theater.
What topics belong in a developer-focused curriculum?
The curriculum focuses on seven topics that map to decisions developers make in code: evaluating a new npm/PyPI/Maven package before adding it, recognizing typosquatting and dependency confusion, reading a CVE advisory and deciding relevance, handling secrets in build and runtime, hardening CI/CD configurations, understanding SBOM output and what it means, and responding to a security ticket assigned to their team.
What we dropped from the generic curriculum: the phishing module (covered separately for all staff with a 15-minute refresher), the password hygiene module (solved by the SSO rollout), and the "data classification" module (which engineers already handle via data governance tooling). Developer time is expensive; every minute of training content has to earn its slot by mapping to a real decision or behavior.
How long should the training be and how often?
The annual commitment is 3 hours total, split into six 30-minute modules delivered monthly January through June, with a capstone in July. This beats the single 3-hour block pattern because short modules have roughly 2x retention and they distribute the cognitive load.
Modules are asynchronous: a 12-minute video, a 10-minute interactive scenario, and an 8-minute quiz. Completion tracking hits the LMS; non-completion generates a manager notification at day 30 and a compliance flag at day 60. In the second year, we added optional advanced modules (deep dives on SBOM internals, SLSA levels, provenance) for engineers who wanted more; uptake was around 25% of the population, which is itself a signal worth tracking.
Who should deliver the content?
Engineering peers deliver 70% of the content, AppSec delivers 20%, external experts the remaining 10%. This ratio matters because engineers trust engineers more than they trust security staff, and a senior engineer walking through a real dependency decision is far more credible than a compliance officer reading slides.
Recruit 8-12 instructor engineers per year, each delivering one module. Pay them: we budget $3,000 per module in instructor time, plus external speaker bureau fees for the annual capstone keynote (typically $5,000-$15,000). Record every session and edit into the async module; live delivery is expensive and scaling it does not work. The instructor's job is the initial recording and one office-hours call per month during the rollout window; after that, the content is self-serve.
How do you measure that training is actually working?
Measure four things: completion rate (basic compliance, target above 95%), retention (post-test scores 90 days after completion, target above 70%), behavior change in code (PR-level metrics), and self-reported confidence.
The behavior metrics are the payoff. We track three: new dependency introductions per week (should plateau or decline as teams get more deliberate), percentage of dependency-adding PRs that include an explicit review comment on the justification (should rise from single digits to 30-50% over 12 months), and internal security ticket response time by team (should compress as teams take more autonomous action).
Survey confidence quarterly with a three-question pulse: "do you feel equipped to evaluate a new dependency," "do you know what to do when a CVE is assigned to your team," and "do you know where to find supply chain resources." Confidence scores correlate weakly with actual behavior, so do not over-index, but a dropping confidence trend is an early signal that the curriculum is drifting from real needs.
How do you handle new hires and contractors?
New hires complete the full six-module curriculum in their first 90 days, not spread over six months. The onboarding module compresses the async content into a 2.5-hour first-week block plus mentorship from their team's security champion for the first 30 days.
Contractors and short-term engagements get a 45-minute essentials module covering the three highest-leverage topics: no new dependencies without lead approval, CVE response protocol, and secrets handling. Full curriculum is required only for contractors engaged beyond 6 months. This cuts onboarding friction without creating compliance gaps; we run the same pattern for acquired teams during an M&A integration.
What does the program cost and how do you justify the budget?
Annual direct cost for a 600-engineer org runs roughly $180,000-$240,000: $60,000-$80,000 in instructor time, $30,000-$50,000 in LMS tooling and interactive scenario development, $20,000-$30,000 in external speakers and content licensing, and $60,000-$80,000 in the program manager role (0.5-0.75 FTE). This excludes the 3 hours per engineer of consumption time, which the business absorbs.
Justify the budget against the cost of the decisions the training improves. A single bad dependency choice (a compromised package, an abandoned maintainer with a zero-day) that requires emergency remediation typically costs 40-80 engineering hours across 3-6 teams, or roughly $15,000-$30,000 loaded. Prevent three such events per year and the training pays for itself. In practice, the harder measurement is the events that do not happen because someone paused at a PR and asked a question; that is what the behavior metrics try to capture.
How Safeguard Helps
Safeguard makes the "right choice" easier than the wrong one at the moment of decision, which is when training content actually converts. When a developer adds a new dependency, policy gates surface reachability-aware risk context in the PR itself, making the training abstractions concrete. Griffin AI provides in-line explanations of CVE relevance that engineers can act on without leaving their workflow. SBOM views are accessible directly from each service's dashboard, so the "read an SBOM" skill from the curriculum has a real artifact to practice on. TPRM data lets champions show their teams the vendor-level context behind a dependency choice, connecting abstract supply chain concepts to the actual suppliers whose code they rely on.