Run a security champions program with protected time and outcome metrics

A security champion is a developer, tester, SRE or product engineer who stays in their team and spends part of each week on that team's security work. OWASP SAMM 2.2.0 makes this its first Organization and Culture activity: a champion in every development team who links the team to the security function, with a fixed weekly time budget, regular briefings and extra training. BSIMM16 describes the same group, which it used to call the satellite. The point is reach. A central AppSec team cannot sit in every design discussion or read every pull request; a champion is already there.

Decide what the program must change before you recruit anyone, and write it down. Useful goals include security questions answered inside the team the same day, risky changes reviewed before merge by someone who knows the code, findings triaged within the SLA and fewer repeats of the same weakness. Champions do not accept risk for the business, sign off releases alone or become the team's security ticket queue. Risk acceptance stays with an accountable owner, and AppSec keeps the expert review. Within those limits, a champion's week usually covers:

• Join design and threat-modeling sessions for changes that cross a trust boundary.
• Review, or route to AppSec, pull requests that touch authentication, authorization, cryptography, secrets, payments or the build pipeline.
• Triage scanner and external test findings before they reach the backlog, adding the context a tool lacks.
• Teach the team from its own findings in short sessions.
• Escalate anything novel, high-impact or disputed to AppSec.

Ask for volunteers, and get each one's manager to approve in writing. BSIMM16 describes three ways to form the group: spot people who stand out in training, ask for volunteers, or assign members for coverage and keep those who perform. It also observes that enthusiastic volunteers are easier to lead than draftees. Look for someone peers already ask for help, who knows the codebase and can explain a risk calmly. Curiosity and credibility matter more than seniority. Don't load the role onto a tech lead who already handles every escalation.

SAMM's level-1 activity asks for a champion in each team. The OWASP Security Champions Guide warns that a strict one-per-team model breaks when people leave, and suggests pooling champions by specialism at a sensible ratio, giving one per 25 developers as an example for large organizations. Do both: a named champion and a named backup for each in-scope team, plus a shared pool for topics such as cloud, mobile or cryptography. For scale, the median among BSIMM16 firms with 650 or more developers and a champions program was 3 champions per 100 developers; among smaller firms with champions it was 6.4. Use 12-month renewable terms, so leaving the role is normal and comes with a handover to the backup.

SAMM expects champions to have a set number of hours each week for security work but gives no figure. The OWASP guide explains why the time must be formal: when priorities conflict, sprint commitments win unless management has made security work an agreed priority. Start with half a day a week, about 10 percent, entered as reduced capacity in sprint planning. Raise it during onboarding or a major design cycle, and lower it only by agreement with the program lead.

Make the work count. Put a champion goal in the performance review, name the role in promotion criteria and fund one external training or conference a year. BSIMM16 notes that the prospect of real career progression changes behavior, while mugs and t-shirts mostly lift morale. Give the program an owner, too. Interviews behind the OWASP guide found that leading a champions program is a full-time job, and larger organizations may need a small team.

A charter turns an informal arrangement into a commitment that survives a reorganization. Keep it to one page, have engineering leadership, AppSec and each champion's manager sign it, and review it every six months. SAMM likewise expects a charter for the center of excellence it describes at level 2. Adapt the examples; they are starting points, not requirements.

Train in three stages: an onboarding path in the first 90 days, a monthly advanced session, and a specialism once the basics stick. SAMM's role-specific training activity says champions get what developers and testers get, plus threat modeling, secure design and the security tools in the build. BSIMM16 activity T2.5 is explicit that champion training means customized material and events, not routine brown bags or standard e-learning. Build sessions from your own findings and recent penetration test results; people remember bugs in code they recognize. The learning paths on this site map onto the stages as the table shows; the wider developer curriculum the champions help deliver is described in /frameworks/developer-security-training/.

Write down when a champion acts alone and when AppSec joins. Champions handle routine design questions, sensitive-path reviews and first-pass triage. They bring in AppSec for new architectures, authentication and cryptography designs, high-severity findings and anything disputed. SAMM adds a useful check: the champion reviews external test results before they enter the backlog. In return, give champions direct access: weekly AppSec office hours and an open chat channel, as in BSIMM16 activity T2.12, a monthly champions meeting and a promised response time for design reviews.

Encode the routing in the repository so it doesn't depend on memory. On GitHub, list the champion group and AppSec as code owners of sensitive paths, then turn on Require review from Code Owners in a branch ruleset. The last matching pattern wins, an approval from any listed owner satisfies the rule, and each team needs explicit write access to the repository. Name a team rather than a person, so a holiday or a resignation neither blocks merges nor silently drops the review. Make AppSec the owner of the CODEOWNERS file itself, and keep the ruleset's bypass list short.

# .github/CODEOWNERS: the last matching pattern wins.
# Default owner for everything: the product team.
*                       @acme/payments-dev

# Security-sensitive paths. An approval from any listed owner satisfies
# "Require review from Code Owners", so list the champion group, not one person.
/src/auth/              @acme/payments-champions @acme/appsec
/src/crypto/            @acme/payments-champions @acme/appsec
**/migrations/          @acme/payments-champions @acme/appsec
/.github/workflows/     @acme/payments-champions @acme/appsec
Dockerfile              @acme/payments-champions @acme/appsec

# Only AppSec changes who owns what.
/.github/CODEOWNERS     @acme/appsec

Counts of champions, training hours, meeting attendance, badges and chat messages describe effort. All of them can rise while risky changes still merge unreviewed. Track them as inputs if you like, but report measures that the program should move:

• Coverage: in-scope teams, taken from the service inventory, with an active champion and a named backup.
• Review reach: merged changes to sensitive paths that a champion or AppSec approved before merge.
• Triage: findings in each team confirmed, rejected or routed within the SLA.
• Outcomes: the share of first-party findings caught before release, and repeats of the same CWE in the same service.
• Retention: champions still active after a year, and backups who stepped up when someone left.

Compare each team with its own baseline from before its champion started, not with other teams. Teams that volunteer first may already be the strongest, so a league table can flatter them and hide whether anything changed. BSIMM16 shows the same trap at firm level: 96 percent of the top-scoring fifth of firms have champions, against 30 percent of the bottom fifth. That is a correlation, not proof that champions raised the scores. Use the escape-rate and repeat definitions from /frameworks/appsec-metrics-and-slas/, so the numbers mean the same thing in every team.

Review reach is easy to get wrong by hand. This script reads a GitHub CLI export and lists sensitive pull requests that merged without a champion or AppSec approval. Explain each miss: a bypass, a path missing from CODEOWNERS or a rule that is not enforced. The CLI returns at most 100 files and 100 reviews per pull request, so the script lists larger ones for a manual check.

"""Share of merged PRs that touch sensitive paths and were approved by a
champion or AppSec reviewer before merge. Export the PRs first:

  gh pr list --state merged --search "merged:2026-07-01..2026-09-30" \
    --json number,mergedAt,files,reviews --limit 1000 > prs.json
"""
import json
import sys
from datetime import datetime

# Champion group + AppSec, e.g. from: gh api orgs/acme/teams/payments-champions/members
REVIEWERS = {"ana-ch", "omar-ch", "lee-appsec"}


def is_sensitive(path):
    # Keep these rules in step with the sensitive entries in CODEOWNERS.
    parts = path.split("/")
    return (path.startswith(("src/auth/", "src/crypto/", ".github/workflows/"))
            or "migrations" in parts[:-1] or parts[-1] == "Dockerfile")


def approved_before_merge(pr, reviewers):
    merged = datetime.fromisoformat(pr["mergedAt"])
    return any(r["state"] == "APPROVED" and r["author"]["login"] in reviewers
               and datetime.fromisoformat(r["submittedAt"]) <= merged
               for r in pr["reviews"])


def review_coverage(prs, reviewers=REVIEWERS):
    sensitive = [p for p in prs if any(is_sensitive(f["path"]) for f in p["files"])]
    missed = [p["number"] for p in sensitive if not approved_before_merge(p, reviewers)]
    return len(sensitive), len(sensitive) - len(missed), missed


if __name__ == "__main__":
    prs = json.load(open(sys.argv[1]))
    total, ok, missed = review_coverage(prs)
    print(f"sensitive PRs: {total}; approved before merge: {ok}; missed: {missed}")
    # gh returns at most 100 files and 100 reviews per PR; check these by hand.
    print("check manually:", [p["number"] for p in prs if len(p["files"]) >= 100])

A program can fail quietly: the launch goes well, and six months later the role is only a title. Watch for these patterns:

• Drafted champions with no hours: the work happens only when nothing else is due.
• The dumping ground: every security ticket is assigned to the champion, who burns out and leaves the role.
• One person per team and no backup: coverage disappears when they change teams.
• Ticket forwarding: AppSec pushes raw scanner output through champions, and teams learn to ignore it.
• Generic training: brown bags and standard e-learning rarely build design-review skills.
• Unrewarded work: effort that doesn't count in reviews loses to effort that does.
• Risk decisions by proximity: whoever is in the room, often the champion, ends up accepting risk.
• Attendance dashboards: the chart looks healthy while sensitive changes merge unreviewed.

Assessors use these models, so map the program to them and cite the edition. Percentages show the share of the 111 BSIMM16 firms in which each activity was observed. BSIMM activity numbers change between editions, and NIST SSDF 1.1 still cites BSIMM12 numbers. In SSDF 1.1, task PO.2.1 names security champions among the roles to define, and PO.2.2 asks for role-based training; the SSDF 1.2 revision was still a draft in October 2026. For choosing between the three models, see /frameworks/bsimm-samm-ssdf/.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP SAMM 2.2.0: Education and Guidance, stream B (Organization and Culture)
2. OWASP SAMM 2.2.0: Education and Guidance, stream A (Training and Awareness)
3. BSIMM16 report (Black Duck): security champions data and activity descriptions. January 2026.
4. OWASP Security Champions Guide: Secure management support
5. OWASP Security Champions Guide: Nominate a dedicated captain
6. OWASP Security Champions Guide: Anticipate personnel changes
7. NIST SP 800-218: SSDF version 1.1 (PO.2 Implement Roles and Responsibilities). Version 1.1 (February 2022).
8. GitHub Docs: About code owners
9. GitHub Docs: Available rules for rulesets (require review from code owners)
10. GitHub CLI manual: gh pr list

Reference information

Tags

Code reviewAppSec programs

SDLC phase

TestingSecurity program

Role

AppSec engineersSecurity leaders

Download this guide as Markdown

Continue exploring