Comment structurer une gouvernance de la sécurité applicative

Les composantes d'un Application Security Program

Un Application Security Program (ASP) est le cadre de gouvernance qui structure l'ensemble des activités de sécurité applicative d'une organisation. Ses composantes incluent : une politique de sécurité applicative qui définit les standards et les exigences minimales pour toutes les applications ; un catalogue d'outils approuvés (scanners SAST/DAST, frameworks de tests, gestionnaires de secrets) avec les configurations recommandées ; des processus formalisés pour chaque activité de sécurité (threat modeling, revues de code, gestion des vulnérabilités, tests d'intrusion) ; des métriques de suivi de la maturité ; et un processus de gouvernance des exceptions (comment documenter et gérer les dérogations aux standards).

L'ASP doit être proportionné à la taille et à la complexité de l'organisation — un document de 200 pages que personne ne lit n'a pas de valeur opérationnelle. Un référentiel de standards clair, concis et accessible dans les outils de travail quotidiens des développeurs est plus efficace.

L'évaluation de la maturité : BSIMM et OWASP SAMM

Le BSIMM (Building Security In Maturity Model) est un référentiel empirique construit à partir de l'observation des pratiques de sécurité applicative de centaines d'organisations. Il décrit les activités pratiquées par les organisations matures dans 12 domaines regroupés en quatre catégories (Governance, Intelligence, SSDL Touchpoints, Deployment). L'OWASP SAMM (Software Assurance Maturity Model) offre un modèle similaire avec une approche prescriptive — il définit des niveaux de maturité progressifs pour chaque domaine et fournit des activités de transition.

Ces référentiels sont utiles à deux moments : pour diagnostiquer l'état actuel de la maturité de la sécurité applicative d'une organisation (par rapport aux pratiques sectorielles), et pour planifier une roadmap de progression avec des priorités et des séquences logiques. Ils permettent de répondre à la question "où investir en priorité pour améliorer notre sécurité applicative" avec une base factuelle.

La gouvernance du portefeuille applicatif

La gouvernance de la sécurité applicative doit couvrir l'ensemble du portefeuille d'applications — pas seulement les nouvelles applications développées avec les standards les plus récents. La gestion du portefeuille legacy est souvent la partie la plus complexe : des applications anciennes avec une documentation incomplète, dont les équipes originales ont souvent quitté l'organisation, avec des technologies obsolètes difficiles à auditer et à corriger.

Une approche risk-based permet de prioriser les investissements : identifier les applications legacy les plus critiques (volumétrie de données sensibles, exposition internet, intégration avec des systèmes critiques), évaluer leur niveau de sécurité actuel (scan de vulnérabilités, revue d'architecture), et définir un plan de traitement proportionné — mise à niveau, isolation, migration vers un système moderne, ou décommissionnement.

Intégrer la gouvernance dans les processus décisionnels

La gouvernance de la sécurité applicative n'est efficace que si elle est intégrée dans les processus décisionnels existants — pas si elle est un processus parallèle que les projets contournent. Cela implique que les revues de sécurité architecturale soient des étapes obligatoires dans les processus de validation de projet, que les métriques de sécurité applicative soient présentées aux instances de gouvernance existantes (comité de direction, comité IT, comité des risques), et que les décisions d'exception aux standards soient documentées et approuvées par des responsables désignés.

Cette intégration transforme la sécurité applicative d'une fonction de contrôle externe en une dimension naturelle des processus de développement et de déploiement — ce qui est la condition de son efficacité durable.