A central security team that reviews every delivery from every product squad has capacity that does not scale. With five squads the pace is manageable. With twenty, centralized review becomes the bottleneck that forces every product team to choose between waiting for approval or skipping the process. The second option becomes standard practice. Security stops working not from lack of intention but from an operational design that does not sustain organizational scale.
Subcapability 04 of 04 · Security Engineering
Security Champions Program
OWASP SAMM-structured Security Champions network that distributes security capability across squads, eliminates the central team bottleneck and multiplies protection without multiplying headcount.
What is at stake
The central security team has four people for twenty squads. Centralized review delays every release. The product team learns to work around the process to meet deadlines. Security becomes an adversary of speed instead of a part of it.
What it is, in practice
How we work
Structured Champion selection and training
We select one to two developers per squad with genuine security interest and build a structured training path: OWASP Top 10 applied to the squad context, secure coding practices, basic threat modeling and escalation criteria to the central team. The Champion receives knowledge, not just a title.
Autonomy with escalation criteria
We define precisely what the Champion decides autonomously, low-risk decisions with established patterns, and what escalates to the central team, high-risk decisions or situations without precedent. Autonomy without escalation criteria creates risk. Criteria without autonomy recreates the central bottleneck.
Program measured by OWASP SAMM
We assess program maturity using the OWASP Software Assurance Maturity Model across five business functions. Each function has maturity activities at three levels. The result is a training roadmap with measurable progress per squad and per quarter.
Community of practice among Champions
We structure periodic meetings among Champions from different squads to share findings, update on relevant new threats and discuss security decisions that cross squad boundaries. Knowledge that today lives in silos begins to circulate across the organization.
Recognition as part of the career model
We establish formal recognition of the security contribution in the career model and performance assessment. A Champion who identifies a critical vulnerability before production is generating measurable economic value. This needs to appear in the contribution record, not just in the security meeting notes.
Measurable gains
What changes in the result when this subcapability matures.
Security coverage ratio per squad
With an active Champion per squad, each product team has embedded security capability. The alternative, a central team reviewing everything, creates bottleneck proportional to the number of squads. The Champion-to-developer ratio is the indicator of distributed capability scale.
Vulnerabilities identified by Champions before production
A Champion who knows the squad's code identifies vulnerabilities with context that a centralized reviewer never has. A vulnerability identified by someone who knows the decision history of the code is remediated faster and with less rework.
Security review time per release
With Champions operating in the squad, security review happens during development, not as an approval gate after delivery. The time between finished code and security approval falls because the control was exercised during construction, not afterward.
Persistence of security culture after reorganization
Culture that depends on a specific individual in the central team dissolves with structural change. Champions distributed across squads create security capability that persists regardless of who is on the central team, because the capability lives in the product, not in a centralized function.
Frequently asked questions
What is the expected workload for a Security Champion?
In mature programs, Champions dedicate between 10% and 20% of their time to security activities: code review with a security perspective, participation in threat modeling, response to SAST or SCA alerts and knowledge updates. This workload varies with squad pace. What defines sustainability is formal recognition of this contribution in performance assessment, without which the Champion inevitably prioritizes activities that appear in the delivery record.
How to measure whether the Security Champions program is working?
By three complementary indicators. Coverage: percentage of squads with an active and trained Champion. Activity: vulnerabilities identified by Champions per quarter versus vulnerabilities that escaped to production. Culture: percentage of squads that initiate threat modeling without a request from the central team. The third indicator is the most relevant because it measures whether the security culture has been internalized or still depends on external impulse.
Does the Champions program replace a central security team?
The program complements the central team, it does not replace it. The central team sets standards, maintains tools, conducts high-impact pentests, responds to major incidents and acts as technical reference for Champions in complex situations. Champions execute day-to-day security in squads within the standards set by the central team. Both need to exist. The ratio between them changes with program maturity.
How to select who will be a Security Champion in each squad?
By genuine security interest, not by mandate or arbitrary designation. A developer who already demonstrates curiosity about vulnerabilities, who questions authentication decisions during code review or who reads security advisories on their own initiative is a natural candidate. Designation without genuine interest produces the anti-pattern of champion in title only: a compliance checkbox without real operational impact.
How long does it take for the Champions program to show measurable results?
A program with structured training, defined autonomy and clear escalation criteria starts showing results in the second or third sprint after initial training. The first indicators are qualitative: champions participating in design reviews, questioning security decisions before code review, escalating situations that previously went unnoticed. Quantitative indicators like vulnerabilities identified per squad become measurable by the end of the first quarter of operation.
Other subcapabilities in this capability
Shift-Left Security
SAST, DAST and SCA integrated into the CI pipeline that reduce correction cost by an order of magnitude and eliminate the annual pentest as the only line of defense.
Threat Modeling
STRIDE and attack trees in design that identify threats before any code exists, eliminate forced redesign from production vulnerabilities and embed risk into architectural reasoning.
Compliance as Code
Open Policy Agent with NIST 800-53 controls as code that transform regulatory requirements into continuously verifiable properties and eliminate the pre-audit sprint assembled on the eve of every certification.
Want clarity on where to invest first?
A complete technology capability assessment with an evolution roadmap connected to financial result.