Quick take
Pick the engineer who already asks, “but what if someone sends a malformed token?” in code review. Give them time, training, and air cover. That’s your security champion. We did this at our fintech startup with a team of eight, and it caught real problems that would have cost us users and money.
We Had No Security Team
In 2017, our fintech startup processed financial news for thousands of users. Eight engineers. No dedicated security person. No budget for one either.
But we were handling user data, API keys, third-party integrations, and payment flows. The attack surface wasn’t small. And everything I know from NATO cyber defense exercises confirms that “we’ll deal with security later” is how you end up in an incident report.
So I borrowed an idea from military operations: you don’t need every soldier to be a specialist. You need embedded people who know enough to spot danger and escalate fast.
That’s a security champion.
What a Security Champion Actually Is
Not a security expert. Not a penetration tester. Just an engineer on the team who volunteers to keep security visible.
At the fintech startup, our champion was a backend developer with a natural paranoia about input validation. Perfect. I didn’t need him to write a threat model from scratch. I needed him to ask “where does this data come from?” during design discussions. To flag hardcoded credentials in PRs. To be the person other engineers felt comfortable asking basic security questions.
The role boils down to three things:
- Ask the uncomfortable questions during design and code review. Not after. During.
- Keep the basics visible. Auth, data handling, dependency updates, logging.
- Escalate what’s beyond their depth. In our case, that meant escalating to me or to an external advisor we had on retainer for a few hours a month.
That’s it. Lightweight. High leverage.
Why This Works Better Than You’d Expect
Single points of failure kill you. This is a core lesson from NATO cyber defense exercises. If one person holds all the security knowledge, they become a bottleneck, and when they’re on vacation or quit, you’re blind. Champions spread awareness across the org. Security stops being one person’s job and becomes part of how the team thinks.
Context beats checklists. An external auditor can scan your code. But your champion knows that the team just shipped a new webhook endpoint last Thursday, that it accepts user-supplied URLs, and that nobody discussed SSRF. That contextual knowledge is worth more than any automated scan.
Culture shift happens from the inside. When the security voice comes from within the team, not from some outside compliance function, people listen differently. It stops feeling like an audit and starts feeling like engineering discipline. At the fintech startup, after a few months, engineers who weren’t champions started raising security concerns on their own. That’s when you know it’s working.
How to Set It Up
Let people volunteer. Draft picks don’t work here. The engineer who wants the role will actually do the work. The one who gets voluntold will treat it as overhead.
Give them real time. This is where most programs die. If security work sits on top of a full sprint, it won’t happen. We carved out a few hours per week. Not a lot. Enough to signal that leadership actually cares.
Train them, but practically. Skip the theory-heavy workshops. We ran short sessions: here’s how XSS works, here’s how to spot an insecure deserialization pattern in our stack, here’s what our threat model looks like for this feature. Hands-on, specific to our codebase, thirty minutes at a time.
Give them air cover. This is the one that matters most. If a champion pushes back on shipping an unsafe feature and gets overruled by a PM every time, the program is dead. Leadership has to back them up. I made it clear at the fintech startup: if the champion says “this needs a security review before it ships,” that’s what happens. No exceptions.
Make the work visible. If nobody sees the security work, nobody values it. Mention it in standups. Bring it up in performance reviews. Treat it as a real engineering contribution, because it is.
The Pushback You’ll Get
Engineers will say they’re not qualified. Good. That means they understand the limits of the role. Champions aren’t supposed to be experts. They’re supposed to spot obvious risks, ask questions, and know when to escalate. That’s a much lower bar than people think.
Engineers will say they don’t have time. They’re right, unless you give them time. Protect those hours.
Some people will question whether it actually helps. Point to the PR where a champion caught a SQL injection before it hit staging. Or the design review where someone asked “what happens if this JWT is expired but the signature is still valid?” and saved the team a week of debugging in production.
Scaling It
With eight engineers, one champion was enough. As the fintech startup grew, the model scaled naturally: one champion per team, a shared Slack channel for cross-team security questions, and a monthly sync where champions compared notes. Eventually, if you’re lucky enough to grow into needing a real security team, your champions become the connective tissue between that team and the rest of engineering. They already know the code, the people, and the history.
The Honest Truth
A security champion program isn’t a substitute for real security investment. It’s a bridge. It gets a startup from “we have nothing” to “we have something real” without blowing the budget. It builds habits that stick. And it creates a culture where security is part of building software, not a panic that happens after a breach.
We ran this at the fintech startup. It worked. Not because the process was perfect, but because we had one engineer who gave a damn and leadership that backed him up. Start there.