The Security Champions Model: Embedding Security Expertise in Engineering Teams Without Dedicated AppSec Headcount

Most engineering teams at the seed-to-Series-B stage cannot justify a dedicated Application Security engineer. The salary range is real ($180K-$250K+ in most markets), the hiring pipeline is thin, and the competition is with FAANG. So security gets pushed to “later,” and later arrives as a compliance audit, a breach, or an enterprise prospect walking away because the security questionnaire came back empty.

The security champions model is the practical answer. It does not replace a dedicated AppSec function at scale, but it gets a 10-30 person engineering team from zero to functional security practice without that headcount. This article covers how to build one that actually works, not just on paper.

Why Centralized Security Creates Bottlenecks

The standard alternative to a champions program is a security team that all engineering work routes through: PRs need security sign-off, new services need architecture review, dependencies need approval. This works at organizations with a 1:20 or better AppSec-to-engineer ratio. At a 1:80 ratio (common in growth-stage companies), the security team becomes a permanent bottleneck.

Symptoms are predictable:

• Engineers stop flagging security questions because the queue never clears
• Security review becomes a checkbox at the end of the sprint rather than a design input
• Security team spends 80% of time on reactive review and 20% on anything proactive
• The relationship between security and engineering degrades into adversarial

The root problem is that security knowledge is centralized in a function that cannot scale with the organization. Champions programs decentralize that knowledge. Each team has an engineer who understands the threat model for their surface area, can answer security questions without filing a ticket, and can catch the obvious issues before they reach the review queue.

The goal is not to replace AppSec judgment. It is to move the security knowledge closer to where code is written.

Champion Selection: Volunteers vs. Nominations

Both approaches have failure modes.

Volunteers only tends to select for engineers who are already interested in security, which sounds ideal until you notice that interest does not correlate with influence on their team. A junior engineer who loves OWASP has limited ability to change how the team approaches threat modeling. Volunteers also tend to cluster in certain teams, leaving others uncovered.

Nominations only produces resentful champions who treat the role as a tax on their time. Security advocacy requires genuine engagement. A nominated-but-unwilling champion is worse than no champion because they give the program the appearance of coverage without the substance.

The approach that works: nominations filtered by willingness. Engineering managers nominate candidates based on influence and technical credibility. The program lead then has direct conversations with each candidate before confirming. The question is not “do you want to do this?” but “here is what this involves; does this fit where you want to grow?” That framing filters out the reluctant and attracts engineers who see security as a career dimension they want to develop.

Target ratio: one champion per 6-10 engineers. On a 20-person team, that is 2-3 champions. On a 50-person team spread across 4-5 squads, you want at least one per squad.

Time Commitment: Be Explicit

Ambiguity on time commitment kills programs. Champions deprioritize security activities when delivery pressure arrives unless the commitment is explicit and protected.

A realistic allocation for a functioning champion:

• 4 hours per week for the first 3 months (training-heavy period)
• 2 hours per week steady-state (PR reviews, threat model participation, monthly champion sync)
• Occasional spikes for incidents or compliance work (1-2 days per quarter)

This needs to be acknowledged by engineering managers, not just the champions themselves. If a manager schedules a champion for 40 hours of feature work in a sprint with a security review in the middle, the security review will slip. The program lead needs explicit buy-in from EM leadership that champion time is protected.

Training Curriculum

The training goal is not to produce security specialists. It is to produce engineers who can identify the categories of problems that need deeper review, apply basic security controls correctly, and know when to escalate.

Module 1: OWASP Top 10 Applied to Your Stack

Generic OWASP training fails because it uses abstract examples. Build your curriculum around your actual stack. If you write TypeScript/Node services that talk to PostgreSQL and call third-party APIs, the relevant attack classes are:

• SQL injection via ORM misuse (yes, ORMs can still be vulnerable with raw query escapes)
• Command injection in shell-out calls (child_process.exec with user-supplied input)
• SSRF via outbound HTTP calls that resolve user-supplied URLs
• JWT validation gaps (algorithm confusion, missing expiry checks, accepting unsigned tokens)
• Broken object-level authorization (BOLA) in REST endpoints

// Common BOLA pattern that champions should recognize immediately
// This endpoint fetches a resource by ID without checking ownership
app.get('/api/documents/:id', authenticate, async (req, res) => {
  const doc = await db.documents.findById(req.params.id);
  // Missing: does req.user.id have permission to access this document?
  return res.json(doc);
});

// Correct pattern
app.get('/api/documents/:id', authenticate, async (req, res) => {
  const doc = await db.documents.findFirst({
    where: {
      id: req.params.id,
      ownerId: req.user.id, // enforce ownership at the query level
    },
  });
  if (!doc) return res.status(404).json({ error: 'Not found' });
  return res.json(doc);
});

Run each module as a 90-minute workshop with examples pulled from your own codebase. This is more effective than any off-the-shelf course because the champions recognize the patterns immediately.

Module 2: Threat Modeling Basics

Champions do not need to run full STRIDE threat models independently. They need to recognize when a design has threat model implications and know how to frame the conversation.

Teach the four questions that belong in every design doc for any feature with a security surface:

1. What assets are we protecting? (user data, credentials, financial records, PII)
2. Who are the realistic attackers? (external anonymous users, authenticated users acting outside their permission scope, internal actors)
3. What are the trust boundaries? (where does data cross from one process/service/user context to another)
4. What happens if this component fails or is compromised?

A champion who can ask these questions during design review prevents a meaningful percentage of security issues before any code is written.

Module 3: Secure Code Review Checklist

This is the highest-leverage training artifact. Give champions a concrete checklist they apply during PR review for any PR touching authentication, authorization, external inputs, or data storage.

## Security PR Review Checklist

### Authentication & Authorization
- [ ] Does this endpoint require authentication? Is the middleware applied?
- [ ] If the endpoint returns or modifies resources, is ownership verified at the query level?
- [ ] Are JWTs validated (signature, expiry, issuer, audience)?
- [ ] Are session tokens invalidated on logout and password change?

### Input Handling
- [ ] Is all user input validated before use (type, range, format)?
- [ ] Are parameterized queries used for all database operations?
- [ ] Is user input ever passed to shell commands, eval, or dynamic requires?
- [ ] Are file upload types and sizes validated server-side?

### Data Exposure
- [ ] Do API responses include only the fields the caller needs?
- [ ] Are sensitive fields (passwords, tokens, SSNs) excluded from logs?
- [ ] Is PII handled according to your data classification policy?

### External Calls
- [ ] Are outbound URLs validated against an allowlist or at minimum not user-supplied?
- [ ] Are third-party responses validated before use?
- [ ] Are API keys and credentials stored in environment variables, not code?

### Error Handling
- [ ] Do error responses avoid exposing internal stack traces or system details?
- [ ] Are security-relevant events (failed auth, permission denials) logged?

Champions apply this checklist selectively: not every PR, but every PR that touches the relevant surfaces. Applying it to a CSS change is noise. Applying it to a new API endpoint or an authentication flow change is where it earns its cost.

SDLC Integration Points

A champions program that only does PR review is better than nothing but leaves most security value on the table. The highest-leverage integration points are earlier in the development process.

Design Doc Security Review

Establish a convention: any design doc for a feature that touches authentication, authorization, payment flows, data storage of PII, or third-party integrations requires a security section. The champion for that team either writes it or reviews it.

A minimal security section template for design docs:

## Security Considerations

**Assets at risk:** [List the data or capabilities this feature touches]

**Trust boundaries crossed:** [List where untrusted input enters the system]

**Authorization model:** [How does the system determine who can do what]

**Known threat scenarios:** [1-3 realistic attack scenarios and mitigations]

**Open questions:** [Security decisions that need explicit resolution before implementation]

This is a 15-minute addition to a design doc that surfaces issues at the cheapest point in the development cycle.

Dependency Audit Rotation

Every project accumulates vulnerable dependencies. Automated tools (Dependabot, Snyk, npm audit) generate alerts that engineers ignore because they arrive in bulk with no triage. Champions own a monthly dependency audit rotation:

• Review all high and critical severity alerts for their team’s services
• Triage: exploitable in your context vs. theoretical
• Create tickets for genuine risks with clear severity and effort estimates
• Update the security debt backlog

Distributing this across champions prevents it from becoming a single team’s burden and keeps each champion engaged with actual vulnerabilities in code they understand.

PR Review Security Checklist Integration

The checklist is most effective when it is embedded in the PR template, not left to memory. Add a collapsible security section to your PR template that appears for any PR modifying files in security-relevant paths:

# .github/pull_request_template.md

## Changes
[Describe what this PR does]

## Security Checklist (complete if touching auth, APIs, or data storage)
- [ ] Authorization verified at query level, not just endpoint level
- [ ] No user input passed to shell commands or eval
- [ ] Sensitive data excluded from logs and error responses
- [ ] New dependencies reviewed for known vulnerabilities
- [ ] Champion reviewed (tag: @security-champions)

The tag on the last line automatically requests a champion review without requiring the author to know which champion covers their area.

The AI-Generated Code Angle

This is where the champions model has become more urgent in the last 18 months. Teams using Cursor, GitHub Copilot, or Claude Code are shipping more code per engineer per week. That code has predictable security patterns that human review should not miss.

Sonar’s State of Code 2026 survey found that 96% of developers do not fully trust AI-generated output, yet only 48% verify it before committing. Champions are the verification layer.

AI-generated code has specific failure signatures that champions should be trained to recognize:

Pattern 1: Authorization that looks correct but is not enforced at the right layer

AI models generate authorization checks at the function entry point but often miss enforcement in helper functions called by multiple paths. The check exists; it just does not cover all code paths that reach the sensitive operation.

Pattern 2: Correct syntax, wrong cryptographic primitive

AI tools frequently generate code using deprecated or weak cryptographic functions because the training data contains a lot of them. MD5 for passwords, ECB mode for symmetric encryption, seeded random numbers for token generation. The code compiles and runs correctly. The security is wrong.

// AI-generated code that compiles and runs but is insecure
import crypto from 'crypto';

function generateResetToken(userId: string): string {
  // AI generated MD5 hash: looks reasonable, is incorrect for security tokens
  return crypto.createHash('md5').update(userId + Date.now()).digest('hex');
}

// Champion-reviewed replacement
function generateResetToken(): string {
  // Cryptographically secure random bytes, not a hash of predictable input
  return crypto.randomBytes(32).toString('hex');
}

Pattern 3: Missing rate limiting and abuse controls

AI tools generate the happy path. They produce functional authentication endpoints, password reset flows, and OTP verification systems without rate limiting, account lockout, or brute force protection. These are not bugs in the code that was written; they are omissions of code that should have been written.

Champions reviewing AI-generated PRs should explicitly ask: what happens if an attacker calls this endpoint 10,000 times in a minute?

Metrics and Incentives

Programs without metrics drift. Champions do security work until delivery pressure arrives, then deprioritize it. The right metrics make the contribution visible to engineering leadership and create a feedback loop for champions themselves.

What to Track

Security debt tracking: Count open security tickets by severity, age, and team. Report this in engineering all-hands quarterly. Making security debt visible in the same context as feature debt changes how it is prioritized.

Champion activity log: Per-champion, track PRs reviewed with the security checklist, design docs with security sections contributed, and dependency audits completed. This is not for performance review. It is for the program lead to identify when a champion has gone inactive and check in before coverage gaps accumulate.

Issue discovery rate: Count security issues found by champions (in PR review, design review, audits) vs. issues found later (in production, by external pen tests, by customers). The goal is to shift the ratio toward earlier discovery. This metric tells you whether the program is working.

Mean time to remediate (MTTR) for security tickets: Track how long it takes to close high-severity security tickets once filed. Champions own follow-through for their team’s tickets.

Incentives That Work

Champions take on real work for no additional compensation. The incentives that sustain programs over time:

• Visibility: Security champion work should be cited explicitly in performance reviews and promotion packets. If engineering leadership does not acknowledge it, it will not be sustained.
• Conference and training budget: Champions get first access to security conference attendance and training budget. SANS courses, AppSec conference tickets, and bug bounty participation are tangible recognition.
• Rotation path: Experienced champions who want to move toward a security-focused role have a documented path. Some will use the champion experience to transition into a dedicated AppSec role as the company grows.

Do not use swag, titles, or recognition ceremonies as the primary incentive. Engineers who are motivated by security advocacy want substantive engagement with security work, not a Slack badge.

Scaling the Program

The program that works for a 15-person team needs adjustment at 50 people and significant restructuring at 100+.

Team size	Champion count	Champion meeting cadence	Dedicated AppSec?
10-20	2-3	Monthly sync, async Slack channel	No
20-50	4-8, one per squad	Bi-weekly sync, shared review queue	Consider fractional/part-time
50-100	8-12	Bi-weekly squad-level, monthly program-level	Yes, 1 dedicated
100+	12+, structured guild	Weekly guild meetings, dedicated tooling	Yes, 1 per 40-50 engineers

The transition point where you need at least one dedicated AppSec hire is roughly 50-75 engineers. At that scale, threat modeling complexity, compliance requirements (SOC 2, HIPAA, enterprise security questionnaires), and the surface area of new services exceeds what champions can handle in their allocated time. The champions program does not go away at that scale; it becomes the distributed layer that extends a small AppSec team’s reach.

The maturity signals that tell you the program is working:

• Security questions appear in design docs without being requested
• Champions are paged for security input before PRs are written, not after
• Security debt backlog is actively groomed alongside feature backlog
• Incident post-mortems include security root cause analysis as a standard section

The maturity signals that tell you the program has stalled:

• Champions have not filed a security ticket in two months
• Design docs do not have security sections
• PR security checklist completion rate is below 40% for relevant PRs
• Champions report that their managers do not protect their time allocation

A stalled program requires direct intervention with engineering leadership, not more training for champions. The problem is almost always organizational, not knowledge-based.

Putting It Together

The security champions model is not a substitute for security expertise. It is a mechanism for distributing security awareness to the people who write code every day. A program that runs for 12 months produces engineers who recognize authorization gaps on sight, design docs that surface threats before implementation, and a team that treats security debt with the same discipline as technical debt.

That is achievable without a dedicated AppSec hire. It requires a program lead with enough security knowledge to build the curriculum and run the monthly syncs, explicit time protection from engineering managers, and consistent measurement so the work stays visible. The hard part is not the security knowledge. It is sustaining the organizational commitment long enough for the habits to take hold.