Security teams should look for captains, the developers who care about team success and are willing to help others improve. These people are often the most effective security champions because they can translate security goals into team culture and day-to-day practice. They are especially valuable when the message needs trust, momentum, and peer credibility rather than formal authority.
What makes a good AppSec captain
The best captains are not the loudest security advocates, they are the developers others already trust to make practical trade-offs. They tend to care about shipping quality, reducing rework, and helping teammates solve problems before they become incidents. That makes them far more persuasive than a central security team speaking only in policy language.
A captain works because the role is social as much as technical. They can translate secure coding ideas into the team’s language, adapt advice to the codebase and delivery rhythm, and reinforce habits in the flow of normal work. In mature programmes, that peer credibility is what turns AppSec from a side initiative into team behaviour.
Why peer influence scales better than central enforcement
Security teams can define standards, provide tooling, and set expectations, but they rarely have enough proximity to change daily engineering habits on their own. Captains extend reach into design reviews, code review, backlog grooming, and release pressure points where security decisions are actually made. They help security land as part of engineering practice instead of as a late-stage gate.
This is especially important when teams need to balance speed and assurance. A trusted peer can explain why a control matters, what the real failure mode looks like, and which shortcut is acceptable versus dangerous. That sort of judgment is harder to absorb from documentation alone and is one reason AppSec maturity programmes often emphasise embedded champions, such as OWASP SAMM and the NIST Cybersecurity Framework 2.0.
How to support captains without turning them into shadow security staff
Captains should amplify the security team, not replace it. The most effective programmes give them lightweight enablement, clear escalation paths, and reusable guidance they can apply without becoming policy interpreters. If the role becomes too formal or too burdensome, you lose the very peer credibility that made it valuable.
What to verify: Check that captains are being used to spread practical habits, not to absorb every security review task. Look for evidence that they can point teams to the right controls, raise issues early, and keep conversations moving without becoming a bottleneck.
What good looks like: Teams ask captains for early feedback on design choices, captains bring common issues back to the security function, and secure defaults start appearing in normal development conversations. In that model, security influence is distributed, but accountability remains clear.
Practitioner takeaway: Choose captains for trust, credibility, and willingness to help, then give them enough structure to scale good habits without turning them into a second security organisation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 14 — Security Awareness and Skills Training | Captains help spread practical AppSec skills across development teams. |
| Recommendation — Use Control 14 to build role-based AppSec enablement for developers and champions. | ||
| OWASP Agentic AI Top 10 | A1 — Agentic Goal and Authority Boundaries | Peer-led security enablement supports clear boundaries on what development teams should do securely. |
| Recommendation — Define clear security boundaries and escalation paths for developer champions. | ||
| NIST CSF 2.0 | PR.AT — Awareness and Training | This question is about distributing security practice through people and training mechanisms. |
| Recommendation — Build training and enablement paths that let champions reinforce secure practices in teams. | ||
Related resources from NHI Mgmt Group
- How should security teams implement responsible AI practices across model development and production?
- How should security teams streamline vulnerability remediation across AppSec, development, and operations teams?
- How should security teams make NHI best practices usable across the business?
- How should security teams govern access when sensitive data is spread across multiple systems?
