How should security teams structure a security champions program alongside application security engineering?

Why This Matters for Security Teams

A security champions program only works when it complements, rather than duplicates, application security engineering. AppSec engineers should own standards, secure patterns, and tooling decisions, while champions help those controls land inside delivery teams without becoming a bottleneck. That split matters because most security failure is organisational: friction, unclear ownership, and delayed feedback, not a lack of policy.

When the model is blurred, champions become unpaid security coordinators and AppSec engineers become ticket triage. The result is slower remediation, more exceptions, and weaker developer trust. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports the broader idea that security responsibilities must be clearly assigned and repeatable, not improvised team by team. NHIMG research on The State of Secrets in AppSec found that the average time to remediate a leaked secret is 27 days, which shows how quickly small issues become operational risk when no one is accountable for early detection.

In practice, many security teams discover the gap only after developers have already worked around the control and shipped the risk.

How It Works in Practice

The strongest operating model is a hub-and-spoke arrangement. AppSec engineers define the control baseline: secure code standards, approved libraries, secret scanning rules, threat modeling templates, and CI/CD guardrails. Security champions then localise that program inside product teams by translating the baseline into team-specific workflows, surfacing false positives, and escalating patterns that need engineering attention. This division keeps security architecture consistent while still making it usable in day-to-day delivery.

Champions should not be asked to design controls from scratch. Their value is proximity. They spot where developers are blocked, where a secure pattern is missing, and where a policy is technically sound but operationally unrealistic. AppSec engineers then turn that feedback into reusable fixes, reference implementations, and platform changes. That feedback loop is especially important in environments exposed to risks documented in JetBrains Marketplace AI Plugin Campaign and Code Formatting Tools Credential Leaks, where developer tooling can leak secrets faster than central review can react.

• AppSec engineers own policy, control design, and security tooling selection.
• Champions own communication, local adoption, and early escalation.
• Both teams share metrics, such as fix time, policy exceptions, and recurring friction points.
• Security work should be embedded into pull requests, build checks, and release gates, not handled as a separate queue.

Current guidance suggests using champions to validate usability, while AppSec retains final authority over exceptions and control design. These controls tend to break down in highly decentralised organisations with many autonomous teams because local “security ownership” drifts into inconsistent standards and unmanaged workarounds.

Common Variations and Edge Cases

Tighter central control often increases coordination overhead, requiring organisations to balance consistency against team autonomy. That tradeoff becomes visible in larger engineering groups, regulated environments, and platform-heavy organisations where one model rarely fits every product team.

One common variation is to assign champions by domain, not just by squad. For example, a platform team may need deeper control over pipelines and secrets, while product squads need more help with threat modeling and secure coding reviews. Another is to give AppSec engineers a formal enablement mandate, so they produce templates, office hours, and self-service tooling instead of only reviewing findings. Without that enablement layer, champions can end up relaying the same questions repeatedly.

There is no universal standard for champion selection, but best practice is evolving toward peers who are trusted by developers and close enough to the work to notice friction early. That is especially important when teams are handling secret exposure patterns seen in Hard-Coded Secrets in VSCode Extensions, where weak local practices can spread across tooling and repositories before central security sees the pattern.

The cleanest programs treat champions as a force multiplier for adoption, not as a substitute for engineering ownership. When that boundary is respected, AppSec can scale standards without becoming a gatekeeper, and champions can improve delivery without becoming shadow security staff.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities alongside human accounts?
• What do security teams get wrong about using APIs to manage user roles and application licences?
• How should security teams govern application access when core systems lack off-the-shelf integrations?
• How should security teams prioritise identity governance when cloud, infrastructure, and application access are all changing at once?