Security culture & champions
Every practice covered so far in this course — threat modeling, scanning, the secure SDLC — only works if the engineers who own the code actually use it, and that's a people problem, not a tooling problem. This page covers the security champions model that lets a small central team scale across an entire engineering org, why a "no" reputation quietly kills a security program from the inside, and the blameless-reporting, internal-bug-bounty, and continuous-training practices that keep people bringing problems to security instead of hiding them.
A hospital doesn't station a doctor in every classroom to catch every scraped knee — it trains one teacher per classroom in first aid, gives them a stocked kit, and tells them exactly when to call the nurse's office. Most scrapes get handled on the spot by someone who's already in the room; only the real emergencies escalate. A security champion is that trained teacher: embedded in a team that already trusts them, equipped to triage the everyday stuff, and wired directly to the people who handle the rest.
The security champions model
A central security team cannot review every pull request, sit in every design meeting, or answer every "is this okay to do" Slack message across an org running dozens of product teams — the ratio of security engineers to developers is commonly cited at somewhere between 1:100 and 1:400, and it only gets worse as engineering headcount grows faster than security hiring. The security champions model closes that gap not by hiring more security engineers, but by designating one embedded, trained advocate per product team: a developer who already writes the team's code, sits in the team's standups, and becomes the local point of contact for security questions, first-pass triage of scan findings, and translating central security policy into decisions the team actually understands.
Champions are not a second security team — they typically keep their regular engineering role and spend a bounded slice of time (often 10-20%) on the champion function, supported by a recurring cross-team sync, a dedicated channel, and a curriculum from the central team covering the org's threat model, its tooling, and its escalation paths. Frameworks like OWASP SAMM and BSIMM both name a champions or "security satellite" function explicitly, because the data behind both models shows the same pattern: maturity correlates less with tool coverage and more with how distributed security ownership is across engineering. The central team's job shifts from doing all the work to training and supporting the network that does most of it.
Making the safe path the easy path
The fastest way for a security program to lose influence is to become the team that only shows up to block a launch. When "talk to security" reliably means a delayed release, a rejected pull request, or a design that gets sent back with no alternative offered, engineers learn to route around the function entirely — looping security in as late as possible, or not at all, precisely when the cost of fixing a problem is highest. That reputation is rational: teams respond to the incentives they're given, and a security review that only ever says no is a cost with no visible upside.
The fix is not lowering the bar — it's shifting where security's effort goes. Instead of gatekeeping at the end, the highest-leverage work is making the compliant path the path of least resistance: a golden container base image with the required scanning and hardening already baked in, a paved-road CI template that wires up SAST and dependency scanning by default, a self-service secrets-manager integration that's faster to adopt than rolling your own. When the secure option is also the fastest option, adoption stops requiring enforcement. Security's role becomes an enabler that ships guardrails and reference implementations, and reserves an actual "no" for the small minority of cases — a genuine critical vulnerability, a clear policy violation — where it's truly warranted, which is also what keeps a "no" credible when it does happen.
Blameless security culture
DevOps culture already has a name for this pattern: the blameless postmortem, where an incident review focuses on the systemic and process gaps that let a failure happen rather than which individual to blame — the same principle this course covers for operational failures applies directly to incident response for security events, and it applies just as directly to how a security team treats the person who reports a problem. An engineer who clicked a phishing link, checked in a secret by accident, or disabled a security check to hit a deadline is a source of information about where the system's real weak points are — punishing that person doesn't undo the mistake, it just teaches everyone else watching to stay quiet next time.
In practice, blameless culture means the incident review after "I think I just clicked a phishing link" asks why the email got past filtering, why the resulting session token was valid for MFA bypass, and what control would catch the next one — not why that particular person was careless. Google's Site Reliability Engineering literature and the DevOps research behind the State of DevOps reports both converge on the same finding for operational incidents: organizations that formally protect reporters from blame get more reports, earlier, which is the entire input a security program needs to actually reduce risk. A reporting culture that looks clean because nobody reports anything is not evidence of safety — it's evidence the reporting channel is broken.
The moment one self-reported mistake results in disciplinary action, the reporting pipeline for that entire team quietly shuts off — not just for that person, but for everyone who heard about it. It rarely reopens on its own; rebuilding trust after a punitive response takes far longer than the incident itself did to happen. Reserve real consequences for deliberate, malicious, or repeatedly negligent acts, and say so explicitly in policy so the distinction isn't left to guesswork under pressure.
Internal bug bounty and vulnerability disclosure programs
External bug bounty programs on platforms like HackerOne and Bugcrowd pay independent researchers for valid, reproducible vulnerability reports, typically scoped by target and severity and paid out against a rate card tied to something like CVSS score. An internal bug bounty program applies the identical mechanic to employees: your own engineers, who already understand the codebase and infrastructure better than any external researcher, are motivated with recognition, swag, or direct payouts to actively hunt for and report vulnerabilities rather than mention them in passing or not at all. Motivated internal testers routinely surface findings a scheduled pentest or automated scan misses, because they know which internal tool nobody's looked at hard, which service still runs a deprecated auth flow, or which "temporary" workaround from eighteen months ago never got cleaned up.
This only works paired with a clear, published vulnerability disclosure policy — the internal equivalent of ISO/IEC 29147 (disclosure) and 29147's companion 30111 (handling), or the pattern documented in OWASP's Vulnerability Disclosure Cheat Sheet: where to report, what's in and out of scope, what response time to expect, and an explicit safe-harbor statement that a good-faith report won't trigger disciplinary or legal action even if it involved something technically against policy (like probing a system outside normal duties) to find it. Without that safe-harbor guarantee spelled out, the same trust problem from blameless culture reappears — nobody tests a system they're not sure they're allowed to touch.
Continuous security awareness training
An annual fifteen-minute training video with a multiple-choice quiz at the end satisfies a compliance checkbox — auditors reviewing against frameworks like SOC 2 or ISO 27001 will accept it as evidence of "security awareness training completed" — but it does almost nothing to change behavior, because a once-a-year event is exactly the cadence humans are worst at retaining. NIST SP 800-50 (rewritten as SP 800-181 in its current revision) and SANS's security awareness maturity model both describe training as an ongoing program with recurring touchpoints, not a single event: short, frequent modules tied to real recent incidents; simulated phishing campaigns run by tools like KnowBe4 or Proofpoint that measure click rates over time rather than once; role-specific content, since a payments engineer and a marketing contractor face genuinely different threat models and don't need identical material.
The metric that matters is trend, not a single pass rate — phishing simulation click-through rate dropping over successive quarters, median time-to-report for a suspicious email getting shorter, self-reported near-misses going up (a good sign under a blameless model, not a bad one). Training that's paired with the champions model compounds: champions are natural first recipients of deeper technical modules and become the people who reinforce awareness content in their own team's context, rather than awareness training and the champions program running as two disconnected initiatives.
1. What does a security champion actually do day to day, and why does the model scale a central security team's reach without adding headcount to it? 2. Why does a security team that only ever says "no" tend to lose influence over time, and what should it do instead? 3. Under a blameless model, what question should an incident review ask instead of "whose fault was this"? 4. Why does an internal bug bounty program need a published safe-harbor disclosure policy to actually work?
Check your answers
- A champion is an embedded developer on a product team who handles local security triage, answers day-to-day security questions, and escalates what's beyond their scope to the central team — it scales reach because one trained person per team replaces the central team having to review every decision on every team directly.
- Engineers route around a team that only blocks launches, looping it in later or not at all — which raises the cost of every fix. The alternative is making the secure option the easy default (paved-road CI templates, hardened base images, self-service tooling) so compliance doesn't require enforcement, and reserving an actual "no" for genuine critical cases.
- It should ask what systemic or process gap let the failure happen and what control would catch the next occurrence — not which individual to blame, since blaming the reporter just teaches everyone else to stop reporting.
- Without an explicit guarantee that a good-faith report won't trigger disciplinary or legal consequences, employees won't test or probe systems they're unsure they're allowed to touch, which defeats the purpose of inviting them to look in the first place.