Application security teams rarely grow as fast as engineering, so every security leader eventually has to decide whether to hire more central specialists or push security work into development teams through champions. The two models carry different costs, different failure modes and different evidence for auditors. This guide compares a centralised AppSec team with a security champions network as operating models: what each is good at, how to size coverage, where each breaks, and how hybrid designs split the work. It is written for heads of application security, CISOs and engineering leaders making headcount and structure decisions. Programme design for champions themselves (onboarding, levels, curriculum) is covered in the Security Champions Programme Guide and is not repeated here.
Key takeaways
- It is a work allocation decision, not a staffing fashion. List the AppSec activities, decide which need specialist depth and which need team context, and the model follows.
- Central teams own standards, tooling and hard reviews. Champions own first-line triage, threat model participation and secure defaults inside each team.
- Coverage is a ratio you can plan. Count engineers, teams and critical services against central specialist capacity and champion hours; OWASP gives about one champion per 25 developers as an example for large organisations.
- Champion programmes fail on time, not enthusiasm. Without protected time, a full-time programme lead and management sign-off, champions burn out and the network decays.
- Most mature programmes are hybrid. OWASP SAMM puts a champion in each team at maturity 1 and a secure software centre of excellence at maturity 2, so the models are layers, not rivals.
The short answer
Choose a centralised AppSec team as the core when you have few teams, high regulatory exposure, or nobody yet to set standards and run tooling. Add a champions network once the number of teams exceeds what the central team can review, typically when reviews queue for weeks or scanner findings go untriaged. Never run champions without a central team: someone must own standards, the tool chain, escalation and the programme itself. Never run a central team alone at scale: it becomes a ticket queue that engineering routes around. The Security Operating Model and Organisation Design Guide covers where AppSec sits in the wider security function.
The two models compared
| Dimension | Centralised AppSec team | Security champions network |
|---|---|---|
| Who does the work | Full-time security specialists in one team | Developers or engineers in each team with part-time security responsibility |
| Strength | Depth, consistency, independence, auditable decisions | Context, speed, coverage, culture change inside teams |
| Weakness | Throughput ceiling, distance from code, bottleneck risk | Variable depth, competing priorities, turnover and burnout |
| Cost model | Salaried specialists; cost scales linearly with demand | A share of engineers' time plus programme lead, training and recognition |
| Typical activities | Standards, tooling, penetration test management, design reviews for critical systems, incident support | Finding triage, threat model participation, code review for security, local secure defaults |
| Control evidence | Review records, sign-offs, exception approvals | Role definitions, training records, team-level metrics |
| Framework anchor | NIST SSDF PO.2.1 security roles; SP 800-53 SA-11, SA-15 | NIST SSDF PO.2.1 example naming security champions; SAMM EG Stream B level 1 |
The centralised AppSec team in depth
Threat model. The central model assumes the main risk is inconsistency and missing expertise: insecure design in critical services, poorly configured scanners, unreviewed third-party components, and no one to decide on risk acceptance. A central team counters that with specialist depth and a single place for decisions.
Architecture in words. A head of AppSec reports into the CISO or the CTO. Specialists split by function: tooling and pipeline (SAST, SCA, DAST, secrets scanning), security architecture and threat modelling, testing and assurance (managing penetration tests and bug bounty intake), and sometimes a product security incident response function. Engineering teams raise requests through a queue or intake form; the team publishes standards, secure coding guidance and approved patterns.
Failure modes.
- Review queue as bottleneck: design reviews and release sign-offs wait for days or weeks; teams ship anyway or stop asking.
- Finding firehose: scanners generate more findings than specialists can triage, so backlogs grow and severity loses meaning. See the AppSec Programme Metrics Guide.
- Distance from code: specialists who do not know each codebase raise generic findings that teams discount.
- Single points of failure: one specialist owns the threat modelling practice or the scanner configuration, and leaves.
Controls that make it work. Risk-tier every application so specialist time goes to the critical tier; publish paved-road templates and secure defaults so most teams need no review; automate triage rules and suppressions with an audit trail; set a review service level and measure it.
The security champions network in depth
Threat model. The champion model assumes the main risk is volume and context: hundreds of changes a day that no central team can see, design decisions made in sprint planning, and findings that only someone who knows the code can fix quickly. Champions put a trained person in the room where those decisions happen.
Architecture in words. Each team, or a pool of teams, has a named champion with a written role and protected time. A full-time programme lead (OWASP calls this the captain and treats it as a full-time role, a small team in large organisations) runs the network, the curriculum and the community. Champions route hard questions to the central team and take first-line work back. OWASP suggests grouping champions into specialist pools, such as container or API security, rather than relying only on one champion per team, so the network survives departures.
Failure modes.
- Champion burnout: security is added on top of a full delivery load. OWASP warns that formalised priorities win conflicts, so champions without management backing cannot put security first and become frustrated.
- Volunteer drift: champions are appointed because nobody else volunteered, attend a kick-off, then stop.
- Knowledge concentration: the programme relies on a few key individuals and fails when they move on, the risk OWASP's tenth principle (anticipate personnel changes) addresses.
- Accountability blur: the team assumes the champion owns security, and the champion has no authority to block a release.
- Uneven depth: some teams have strong champions, others nominal ones, and nobody measures the difference.
Controls that make it work. Management sign-off from the head of engineering, the CISO and HR (OWASP's third principle); a written time allocation agreed with each champion's manager; an official role recognised in job descriptions; specialist pools for resilience; team-level metrics so weak coverage is visible.
Coverage ratios and sizing
Published ratios vary by source and sample, so plan from your own numbers rather than an industry average. BSIMM11 found that all 130 participating firms had a software security group, and that 13 of the 15 highest-scoring firms also had a satellite of champions, averaging 269 people. OWASP gives about one champion per 25 developers as an example for large organisations. Build the model in three counts:
- Demand: number of engineers, teams, applications by risk tier, releases per week, and annual design reviews and penetration tests required.
- Central capacity: specialist hours per year after tooling, incident and programme work. Assign critical tier reviews and standards here first.
- Champion capacity: number of champions multiplied by agreed protected hours. Assign triage, threat model participation and team-level review here.
| Activity | Central team | Champions | Sizing driver |
|---|---|---|---|
| Secure coding standards and approved patterns | Owns | Contributes, adapts per stack | Number of languages and frameworks |
| Scanner configuration and pipeline gates | Owns | Tunes rules for their repositories | Repositories and pipelines |
| First-line finding triage | Escalation only | Owns | Findings per week per team |
| Threat modelling, critical tier | Leads | Participates | Critical applications and major changes |
| Threat modelling, standard tier | Reviews samples | Leads | Feature volume |
| Penetration test scoping and remediation | Owns scoping and vendor management | Coordinates fixes | Tests per year |
| Risk acceptance and exceptions | Recommends; risk owner decides | Raises requests | Exception volume |
| Security incident support for applications | Leads technical analysis | Provides code and service knowledge | Incident frequency |
If champion capacity cannot absorb its share, the answer is more champion time or fewer teams per champion, not quietly shifting work back to the central queue.
Cost and funding trade-offs
The central model is easy to budget and hard to scale: each specialist is a visible salary line, and demand grows with every new team. The champion model looks cheap because the cost is hidden in engineering time, which is exactly why it fails when that time is not funded. Make both costs explicit in the business case.
- Central cost: specialist salaries, tooling licences, penetration test budget and training for the team itself.
- Champion cost: agreed hours multiplied by loaded engineering cost, plus the programme lead, curriculum, events, certifications and recognition. OWASP's principles on rewarding responsibility and investing in champions treat this as a real budget, not goodwill.
- Hidden cost of under-funding: review delays that slow releases, findings left open past their target dates, and attrition of the engineers most interested in security.
- Who pays: decide whether champion time is charged to the security budget or absorbed by engineering. Absorbed time is cut first when a deadline slips, so record it in team capacity planning either way.
Hybrid models
OWASP SAMM's Education and Guidance practice describes the progression: at maturity 1 a security champion is named in each development team, at maturity 2 a secure software centre of excellence promotes thought leadership among developers and architects, and at maturity 3 a wider secure software community includes everyone working on software security. In practice hybrids take three shapes.
- Hub and spoke: a central team (hub) with one champion per team (spokes). Simple and common; best below a few dozen teams.
- Hub with specialist pools: champions grouped by topic (cloud, API, mobile, identity) serve several teams each. Resilient to turnover and deeper per topic, but needs routing so teams know whom to ask.
- Embedded security engineers plus champions: full-time security engineers sit inside the highest-risk product groups, with champions elsewhere. Expensive but justified where a single platform carries most of the risk.
The AppSec Maturity Model shows how these structures map to programme maturity, and the OWASP SAMM Guide covers the full model.
Decision guidance
| Situation | Recommended model | Reasoning |
|---|---|---|
| Fewer than about ten teams, no AppSec function | Small central team or one AppSec lead | Standards and tooling must exist before champions have anything to apply |
| Ten to fifty teams, review queues growing | Hub and spoke | Champions absorb triage and standard-tier work; central team keeps critical reviews |
| More than fifty teams or several business units | Hub with specialist pools and a programme team | Pools survive turnover; programme team keeps quality even across units |
| Heavily regulated, independent assurance required | Strong central team, champions for first line | Auditors expect independent review and documented decisions |
| Single high-risk platform carries most exposure | Embedded security engineers plus champions elsewhere | Full-time depth where the risk concentrates |
| Engineering leadership will not protect time | Central team only, fix sponsorship first | Champions without protected time decay within months |
Small organisations: a single AppSec engineer plus two or three champions, a shared channel and a monthly review is enough; write the role agreement anyway. Large organisations: budget for a programme team, HR involvement in job titles and recognition, and a metrics pipeline that reports coverage per business unit.
Implementing the change
- Inventory demand: list teams, applications by risk tier and current AppSec work, including the review queue age and finding backlog.
- Secure sponsorship: agree with the head of engineering, the CISO and HR on protected champion time and an official role, as NIST SSDF PO.2.3 expects upper management commitment and CISA's Secure by Design initiative calls for ownership at executive level.
- Define the split: publish the activity allocation table with named owners and escalation paths.
- Appoint a full-time programme lead: not a side duty for a specialist.
- Pilot with three to five teams: measure review lead time, triage age and champion hours for one quarter.
- Scale in waves: add teams by business unit, introduce specialist pools once there are enough champions per topic.
- Roll back safely: if a team's champion leaves or capacity collapses, return that team's work to the central queue temporarily under a published rule, rather than leaving a gap.
Detection and measurement
- Review lead time: days from request to completed design review, by tier. A rising trend on the central queue signals the need for more champion capacity.
- Finding triage age: median days from scanner finding to triage decision, per team.
- Coverage: share of teams with an active champion (attended training and delivered work in the last quarter), and share of critical applications with a current threat model.
- Champion health: actual hours against agreed hours, and annual champion attrition. Hours far above agreement predict burnout.
- Escalation quality: share of escalations to the central team that needed specialist input, a proxy for champion skill.
- Remediation time: mean time to remediate high-severity findings, compared between teams with and without active champions.
Worked scenario: 400 engineers, four AppSec staff
A software company has 400 engineers in 45 teams and a four-person AppSec team. Design reviews queue for 19 days and 6,000 scanner findings are untriaged. The CTO asks for six more specialists. Modelling shows that even ten specialists could not review every feature, while 45 champions at a modest agreed share of their time would add capacity equivalent to several full-time staff, with code context the specialists lack.
The decision: hire one programme lead and one specialist instead of six, appoint champions in a first wave of 15 teams with written time agreements signed by their managers, and move standard-tier threat modelling and first-line triage to champions. The central team keeps critical-tier reviews, scanner tuning and penetration test management. Specialist pools for cloud and API security form in the second wave. After two quarters, review lead time for the critical tier is the metric the board sees, alongside champion attrition.
Where identity fits
Both models need clear ownership of application secrets, service accounts and API credentials. The central team should set the standard (vault use, no hard-coded secrets, short-lived tokens), while champions enforce it in their repositories and triage secrets scanning alerts quickly. A dedicated pool for identity and secrets is a good early specialist group. See the Secrets Management Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-218 SSDF v1.1 | PO.2.1 create roles and alter responsibilities; PO.2.2 role-based training; PO.2.3 upper management commitment | PO.2.1 examples name security champions; PO.2.3 is the sponsorship requirement |
| OWASP SAMM | Governance, Education and Guidance, Stream B Organization and Culture | Champion per team (L1), centre of excellence (L2), community (L3) |
| NIST SP 800-53 Rev. 5 | SA-3, SA-8, SA-11, SA-15, PM-13, AT-3 | Development lifecycle, engineering principles, developer testing, process, workforce and role-based training |
| NIST CSF 2.0 | GV.RR-02, PR.AT-02 | Defined roles and authorities; training for specialised roles |
| BSIMM | Software security group and satellite | Descriptive benchmark of how firms structure both |
Practitioner checklist
- Inventory AppSec demand by team and risk tier before deciding on headcount.
- Publish an activity allocation table that names central and champion owners for each task.
- Get written sponsorship from engineering leadership, the CISO and HR, including protected champion time.
- Appoint a full-time champions programme lead.
- Form specialist pools so no topic depends on one person.
- Keep risk acceptance with accountable risk owners, never with champions alone.
- Track review lead time, triage age, coverage and champion hours against agreement each quarter.
- Write a fallback rule that returns a team's work to the central queue when its champion leaves.
Standards and references
- NIST: SP 800-218, Secure Software Development Framework Version 1.1
- OWASP SAMM: Education and Guidance
- OWASP: Security Champions Guide
- OWASP Security Champions Guide: Nominate a dedicated captain
- OWASP Security Champions Guide: Anticipate personnel changes
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- CISA: Secure by Design
- Black Duck: Effective software security initiatives (BSIMM11 findings)
Related NHI Mgmt Group resources: Security Champions Programme Guide · AppSec Maturity Model · Security Operating Model and Organisation Design Guide · AppSec Programme Metrics Guide · Secure SDLC vs DevSecOps