A security champion can approve changes that follow an established, documented pattern, and should escalate anything that creates a new trust boundary, changes authentication or cryptography, or leaves them unsure. Escalating a doubt is the job, not a failure. Guessing is.
What the champion role is
The OWASP Secure Code Review Cheat Sheet describes three roles: security reviewers who conduct the analysis and give guidance, developers who implement fixes and follow secure coding practice, and security champions who bridge security and development teams. A champion is not a junior security engineer and not a gatekeeper. They are a developer who knows the team's code and has extra security context.
That framing decides the approval rule. The champion's strength is local knowledge, so they should approve what local knowledge can judge.
Approve on your own
These are well suited to a champion decision:
- A new endpoint that uses the team's existing authorization helper in the same way as its neighbours.
- A new query that uses the same parameterised approach as the rest of the file.
- A dependency bump that stays within the same major version and has a clean changelog.
- A change that adds tests for an existing control.
The test is whether the change copies a pattern the team has already agreed is safe.
Escalate
| Situation | Why it goes up |
|---|---|
| New authentication, session or password handling | Easy to get subtly wrong |
| Any cryptography beyond calling an approved library | Needs specialist review |
| New outbound call to a user-supplied address | Server side request risk |
| New file upload or parser for outside data | Large attack surface |
| A removed or loosened check | Needs a stated reason and a second view |
| New trust boundary between services | Design level decision |
| You are not sure | Doubt is itself the signal |
OWASP's cheat sheet tells diff reviewers to verify security at modified trust boundaries and check new integrations. Those two items map to rows three and six above.
How to escalate well
Escalating badly wastes the security team's time and teaches developers to skip you. Do these:
- Say what you checked and what you could not judge.
- Link the line, not the whole pull request.
- State your worry in one sentence, for example "I cannot tell if this id is checked against the caller's account."
- Keep reviewing the rest, so the security engineer looks at just the open question.
Leave a trail
Mark your approval with what you reviewed: "Reviewed auth and input handling, no concerns. Did not review the migration." That stops a later reader from assuming you covered more than you did, and it is useful evidence if an auditor asks how reviews work.
Grow the approve list
Each time the security team answers an escalation, ask whether it becomes a pattern the champion can approve next time. Write it in a short team guide. Over a quarter the escalation rate should fall because the guide grew, not because champions got bolder.
Try it yourself
Open the demo and see how a pull request gate flags changes by policy. Think about which of its checks a champion could judge alone and which need someone else.
Click through it at your own pace, or open it full screen.
Quick check
Can a champion be the sole approver?
That is a branch protection and policy decision for your team. For high-risk changes, most teams want a second reviewer in addition to the champion.
What if the champion is the author?
Then someone else must review. A champion does not review their own change.
Sources
Last reviewed: 19 October 2026.
