Owners and champions
Ownership means each product, finding and accepted risk has a named person who can act on it. A security champion is an engineer who stays in a product team and spends agreed, protected time on its security work, such as design reviews, sensitive code reviews and finding triage, as the team's link to AppSec.
A central AppSec team cannot attend every design discussion or read every pull request; a champion is already there. Ownership stops findings from aging in a shared queue: when a service's team is reorganized and nobody owns it, nobody can fix it, retire it or accept its risk. Named owners also keep risk decisions with someone who has authority, not with whoever happens to be in the room.
- Who
- Engineering leadership names owners and backs the program; AppSec runs it; each team has a champion and a backup
- When
- When the program starts, and whenever a new service, a team change or a reorganization moves who owns what
- How often
- Coverage checked each quarter, a common starting point; roles and responsibilities reviewed at least yearly
- You end up with
- A service inventory with named owners, a signed one-page champion charter, and code owner rules that route sensitive changes
Do this
Name an owner for every service
Start from the list of deployed services, not the repository list. For each, record the engineering owner who decides on fixes and the business risk owner who may accept risk within agreed limits. A service with no owner is itself a finding: escalate it to engineering leadership rather than handing it to AppSec by default.
Get leadership commitment in writing
SSDF task PO.2.3 asks for upper management's commitment to secure development, conveyed to everyone with a development role. Have the head of engineering approve the program and name who is accountable for releasing software to production. The OWASP Security Champions Guide explains why: when priorities conflict, formalized priorities win. Give the program a lead; the guide calls leading a champions program a full-time job.
Recruit a champion and a backup per team
Ask for volunteers and get each one's manager to approve. SAMM's first Organization and Culture activity puts a champion in every development team. The OWASP guide advises against a strict one-champion-per-team model, because people leave, so name a backup and pool champions by specialism, such as cloud, mobile or cryptography. Look for someone peers already ask for help.
Protect the hours in the capacity plan
SAMM expects champions to have a set number of hours a week for security work but gives no figure. Half a day a week, about 10%, entered as reduced sprint capacity, is a common starting point. Count the work in performance reviews and promotion criteria, so it does not lose to sprint commitments.
Write a one-page charter
Record the purpose, the teams in scope, what a champion does (design reviews for trust-boundary changes, review of sensitive code, finding triage, teaching the team), what is not the role (no risk acceptance, no sole release sign-off, not the team's ticket queue), the hours, the term, what AppSec gives in return, such as office hours, and the measures. Have engineering leadership, AppSec and each champion's manager sign it.
Route sensitive changes in the repository
Make the champion group and AppSec code owners of sensitive paths, such as
src/auth/or.github/workflows/, and require code owner review in a branch protection rule or ruleset. Name a team, not a person; on GitHub the team must have write access. SSDF's examples for PO.2.1 include designating a group or team as each project's code owner.Measure coverage and reach, not attendance
Each quarter, check that every in-scope team has an active champion and a backup, and that merged changes to sensitive paths were approved by a champion or AppSec before merge. Explain each miss: a bypass, a path missing from
CODEOWNERSor a rule that is not enforced. Attendance and badge counts are inputs, not results.
Done when
Every product, finding and exception has a named owner, and each team's champion has protected time and takes part in design reviews.
Mark it in the gap checkCommon mistakes
- Drafting champions with no protected hours: the security work happens only when nothing else is due, and the role becomes a title.
- Making the champion the team's security ticket queue. They burn out and leave the role, and the team stops owning its own findings.
- Letting the champion or the security engineer accept risk because they are in the room. Risk acceptance belongs to an owner with authority over the business consequence.
- One champion per team with no backup: coverage disappears when that person changes teams.
- Naming one person as code owner of a sensitive path. A holiday blocks merges, or a resignation silently drops the review.
- Reporting attendance and badge counts as success: the dashboard looks healthy while sensitive changes merge unreviewed.
Who decides what?
Ownership works when each decision has one role. A common split, which each organization adapts:
| Role | Owns | Does not |
|---|---|---|
| Engineering owner | Fixes in the service, due dates, delivery, requesting an exception when a fix cannot ship in time | Approve their own exception |
| Business risk owner | Approving or rejecting an exception, with an expiry, within delegated limits | Accept risk without a tested interim control and an end date |
| Security champion | Design reviews, sensitive code review, first-pass triage, teaching the team | Accept risk, sign off releases alone, or become the ticket queue |
| AppSec team | Methods, expert review of hard cases, verifying that fixes work, supporting champions | Own every product's defects |
| Program lead | The charter, champion recruitment and training, coverage reporting | Run the program as a side task |
Tools and guides
- Workflow: Build an AppSec program
- Run a security champions program with protected time and outcome metrics
Put a trained engineer with protected hours in every in-scope team, write the role into a one-page charter, route sensitive changes and findings through champions and AppSec, and judge the program by coverage and outcomes instead of attendance.
- Start a minimal AppSec program with owners, triggers and metrics
Begin with ownership, a few risk-triggered activities, and evidence that findings are resolved; expand from demonstrated needs.
- Run an AppSec program: owners, finding states, deadlines and champions
Translate a security baseline into service ownership, change triggers, reusable patterns and evidence that work reaches deployment.
Standards
- NIST SSDF 1.1
- PO.2 Implement Roles and Responsibilities
- OWASP SAMM 2
- Education and Guidance
Sources
- OWASP SAMM: Education and Guidance, stream B (Organization and Culture)
- OWASP Security Champions Guide: Secure management support
- OWASP Security Champions Guide: Nominate a dedicated captain
- OWASP Security Champions Guide: Anticipate personnel changes
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. February 2022.
- NIST OSCAL content: SP 800-218 version 1.1 catalog (PO.2 tasks and examples). oscal-content v1.5.0.
- GitHub Docs: About code owners
- GitHub Docs: Available rules for rulesets