01Rôle et missions : multiplicateur plutôt que substitut de l'équipe AppSec
Un Security Champion est un membre de l'équipe de développement qui fait office de relais entre la sécurité de l'information et le développement – selon OWASP SAMM, il peut s'agir d'un développeur, d'un testeur ou d'un product manager. Ses missions typiques comprennent la recherche, la vérification et la priorisation des défauts liés à la sécurité, la participation aux évaluations de risques, de threat modeling et d'architecture, ainsi que des revues régulières axées sur la sécurité au sein de sa propre équipe. Le NIST Secure Software Development Framework (SP 800-218, version 1.1) mentionne lui aussi les Security Champions dans ses exemples de mise en œuvre – comme rôle SDLC à définir (PO.2.1) et comme public privilégié des formations au threat modeling (PW.1.1). Les champions ne remplacent pas une équipe AppSec centrale : ils démultiplient son impact à grande échelle.
02Sélection et budget temps : les fondations du programme
L'OWASP Developer Guide déconseille toute nomination arbitraire : le rôle suppose un intérêt réel pour la sécurité applicative, raison pour laquelle des membres d'équipe motivés devraient se porter volontaires – ce n'est pas un hasard si le premier principe du manifeste OWASP est « Be passionate about security ». Comme les champions conservent leur fonction d'origine, cette mission supplémentaire nécessite un budget temps formellement garanti ; OWASP SAMM prévoit expressément un nombre d'heures fixe par semaine pour les activités de sécurité, sans imposer de valeur précise. Un champion par équipe de développement et une direction de programme dédiée (« captain »), responsable de la vision, de l'onboarding et de la coordination, ont fait leurs preuves. Sans soutien visible du management (« Secure management support »), l'expérience montre que le budget temps est le premier sacrifié sous la pression des projets.
03Communauté de pratique et incitations
Les champions produisent un effet durable lorsqu'ils ne travaillent pas isolément, mais au sein d'une communauté de pratique : les principes « Create a community » et « Promote knowledge sharing » du guide OWASP recommandent des rencontres régulières, des canaux de communication communs et des ateliers internes transverses aux équipes. Côté incitations, « Reward responsibility » s'applique : reconnaissance formelle (distinctions ou badges, par exemple), budget pour formations et conférences, parcours de carrière et mandats élargis, comme la participation aux comités de sécurité – à adapter, selon les recommandations du guide, aux motivations individuelles des champions. L'essentiel est que la responsabilité supplémentaire soit récompensée de manière visible ; à défaut, la motivation des volontaires s'érode avec le temps.
04Repère : l'OWASP Security Champions Guide
L'OWASP Security Champions Guide (actuellement projet incubateur OWASP) est un référentiel ouvert et indépendant des éditeurs, fondé sur des entretiens avec des responsables AppSec, des coordinateurs de programme et des champions issus de secteurs et de tailles d'entreprise variés. Son cœur est le Security Champions Manifesto et ses dix principes – de « Be passionate about security » à « Anticipate personnel changes », en passant par « Start with a clear vision for your program », « Nominate a dedicated captain » et « Trust your champions ». Le guide se conçoit expressément comme une boîte à outils : il n'existe pas de modèle adapté à toutes les organisations ; pour chaque principe, il fournit des explications et des artefacts adaptables à votre propre programme.
05Positionnement dans le modèle de maturité : SAMM Education & Guidance
Dans l'OWASP Software Assurance Maturity Model (SAMM, version actuelle du modèle 2.2.0 de juillet 2025), les Security Champions sont ancrés dans le stream « Organization and Culture » de la pratique Education & Guidance (fonction métier Governance). Le niveau de maturité 1 exige d'identifier un champion dans chaque équipe de développement et de lui accorder un quota d'heures hebdomadaire fixe ; le niveau 2 ajoute un Secure Software Center of Excellence composé d'architectes et de développeurs seniors de différentes unités métier ; le niveau 3 établit des plateformes de partage de connaissances à l'échelle de l'organisation. Un programme de champions peut ainsi non seulement être mis en place, mais aussi positionné objectivement dans le cadre d'une évaluation SAMM et développé pas à pas.
06Mesure du succès et erreurs typiques
Le guide OWASP recommande d'étayer la vision du programme par des objectifs mesurables et cite en exemple les heures consacrées à la sécurité par champion, les objectifs de formation atteints, le nombre de rencontres de champions et la réduction du risque de sécurité ; le taux de couverture des équipes et les vulnérabilités détectées tôt dans le processus de développement constituent des compléments utiles. Les erreurs les plus fréquentes sont le miroir des principes : des champions alibis sans mandat, un budget temps absent ou purement informel, une nomination par voie hiérarchique plutôt que sur la base du volontariat, une communauté qui s'endort après le kick-off et l'absence de plan de succession en cas de changement de personnel. SAFECode souligne expressément que la simple désignation d'un champion, sans programme formalisé et porté par le management, se heurte généralement à des résistances ou échoue purement et simplement.
