Jason Chan’s article “Security for High Velocity Engineering” hit me hard. It captures a reality many of us in Product Security face: engineering teams move fast, and unless your security program evolves beyond one-off engagements and reactive fixes, you’ll constantly be playing catch-up.
The Fragile Model: When 1:1 Investment Walks Out the Door
When I started out as an AppSec specialist, I focused heavily on 1:1 relationships. I helped developers set up tools like ZAP pipelines, ran onboarding sessions, and spent time mentoring security champions. But then one of our most reliable security champions left the company. Suddenly, all the hours I invested in upskilling walked out the door.
That moment changed my thinking. Our model was fragile. We had built influence, not infrastructure.
Over time, I transitioned through multiple scaling layers:
- Hosting live workshops at internal security community meetups
- Recording those workshops for asynchronous sharing
- Creating reusable pipeline templates so developers didn’t even need to watch the videos
This wasn’t just convenience, it was survival. But even these weren’t enough.
Security Champions: Only multiplier until a certain point.
I keep hearing that security champions are the secret multiplier of AppSec. And in theory, that sounds great. In practice, this alone doesn’t allow scale.
Security champions are often told they can spend “10% of their time” on security. But security isn’t 10% of the problem. The security champion ends up:
- Distributing work across the product engineering team without structured support
- Acting as the go-between for security and engineering
- Becoming responsible for things they were never hired to do
As orgs grow and engineering velocity increases, AppSec teams are stretched thin. One AppSec specialist might already be supporting 10+ products, juggling BAU, incident response, control ownerships and strategic initiatives. Add a few surprise go-lives to the mix, and there’s simply no time to manually coach new champions, review designs, collect evidence for audits, and run SecChamp community sessions.
You might find yourself with 15 and more security champions but only one AppSec engineer. That’s not a multiplier – it’s a signal that you need to invest in platform-level security, not people-driven patchwork. Elsewhere your AppSec team is burning out chasing it.
Let’s look at some bad examples that slow stuff down.
- WAF → before go-live in log mode only → moved to block → Screenshot taken for audit (evidence collection) → Spreadsheet updated (manual evidence collection)
The control exists on paper. But the WAF might be misconfigured, rules overwritten, or disabled shortly after deployment. No continuous assurance, no meaningful protection.
- DAST scan must be green → triage all findings manually → raise tickets → wait for devs to fix
And if your org is shipping multiple releases per day?
- Attack surface scanner reports FP → Scanner sends report to Vuln Management → Platform Operations team triage it → No reproduction steps, no mitigation guidance
Now 30 product teams all receive the same false positive for their assets – and each platform team (see this blogpost for team topologies) has to triage it separately. A single misfiring rule multiplies Ops effort tenfold.
With those examples you might noticed: Controls designed in a checklist-type, that require manual evidence gathering, don’t scale.
Paved Roads > Checklists: Secure-by-Default at Scale
End of 2024 I was inspired by Google’s research paper on their internal project called security signals, especially how they rolled it out. Their security team rolled out security headers like CSP in a monitoring way, automatically monitored adoption on a reverse proxy across ALL services, and applied guardrails incrementally.
This inspired a workshop I delivered to our own security champion community in early 2025. The idea: build centrally, monitor passively, and apply guardrails deliberately. That’s how you eliminate entire classes of bugs. I called this workshop “Stop Firefighting”.
High-Leverage Security Is Embedded Security
We must stop penalising developers for mistakes we could have prevented.
- Symptom: Developers commit secrets into repos.
- Broken fix: Raise tickets, add to risk register.
- Paved road: Provide a centralised, secure secrets management system with SDKs, rollout instructions, and guardrails.
The modern Product Security team needs to think like a platform team:
- Automated evidence collection and verification
- Secure defaults that don’t need instructions
- Provide opt-in tools that don’t break developer workflows
- Monitor adoption centrally
This is the core idea: eliminate the category of mistake, not the individual instance.
It’s not enough to shift left-we need to scale left.
Security champions are super important and are the most important aspect until a certain point, but they cannot be your core scaling strategy. Big tech companies figured this out years ago. Their product security teams build infrastructure. All of this is only possible with a Product Security Platform team – a dedicated team that builds, maintains, and evolves these paved roads.