Janvier 2024. Le RSSI d’une scale-up fintech de 200 personnes présente ses résultats au COMEX. En 18 mois, l’équipe est passée de 45 jours de délai moyen pour corriger une vulnérabilité critique à 3 jours. Le nombre d’incidents de sécurité en production a chuté de 78%. Comment ont-ils obtenu ces résultats spectaculaires ? Pas en embauchant une armée de consultants, pas en achetant les outils les plus chers du marché, mais en mesurant méthodiquement leur maturité DevSecOps et en priorisant les actions à fort impact.
Leur secret tient en une pratique simple mais rigoureuse : un audit de maturité tous les 6 mois, basé sur l’OWASP DSOMM, pour savoir exactement où ils en étaient et où concentrer leurs efforts. Cette approche leur a permis de transformer une équipe de 8 développeurs débordés en une organisation capable de livrer rapidement tout en maintenant un niveau de sécurité exemplaire.
Pourquoi évaluer sa maturité ?
Section intitulée « Pourquoi évaluer sa maturité ? »Avant de lancer une transformation DevSecOps, vous devez savoir d’où vous partez. Cette affirmation semble évidente, pourtant la majorité des organisations se lancent dans des initiatives de sécurité sans avoir établi de baseline. Elles achètent des outils, embauchent des experts, lancent des programmes de formation, mais sans savoir si ces investissements produisent des résultats. Sans baseline, impossible de mesurer le progrès. Sans mesure, impossible de justifier les investissements auprès de la direction.
L’évaluation de maturité répond à trois questions fondamentales que tout responsable sécurité doit pouvoir adresser. La première concerne l’état actuel : où en sommes-nous ? Cette question révèle les forces et faiblesses de l’organisation, ce qui fonctionne bien et ce qui nécessite une attention urgente. Le livrable associé est un score par dimension qui permet une vision à 360 degrés.
La deuxième question est stratégique : par où commencer ? Avec des ressources limitées et une liste de chantiers potentiels longue comme le bras, il faut prioriser. L’évaluation identifie les actions à plus fort ROI — celles qui produisent le maximum d’impact pour un effort minimal. Le livrable est une roadmap priorisée qui guide les investissements.
Enfin, la troisième question concerne la dynamique : progressons-nous ? Six mois après avoir lancé des initiatives, il faut pouvoir démontrer leur efficacité. Sans cette mesure, les programmes de sécurité sont les premiers à être coupés en période de restriction budgétaire. Le livrable est le delta entre deux évaluations successives, preuve tangible du retour sur investissement.
Le modèle OWASP DSOMM
Section intitulée « Le modèle OWASP DSOMM »L’OWASP DevSecOps Maturity Model (DSOMM) s’est imposé comme le framework de référence pour évaluer la maturité sécurité des pratiques DevOps. Développé par la communauté OWASP avec des contributions d’experts du monde entier, il offre un cadre structuré et actionnable pour mesurer où vous en êtes et planifier votre progression.
Contrairement à d’autres frameworks parfois trop théoriques ou orientés vers de grandes entreprises, le DSOMM a été conçu pour être pratique et accessible. Une équipe de 5 personnes comme une organisation de 500 peut l’utiliser. Les pratiques qu’il évalue sont concrètes : avez-vous un scan de code automatisé ? Vos secrets sont-ils centralisés ? Vos équipes sont-elles formées à la sécurité ?
Le modèle structure ces pratiques en 5 dimensions complémentaires et 4 niveaux de maturité progressifs. Cette double organisation permet à la fois une vue d’ensemble (où en est l’organisation globalement ?) et une analyse fine (quelles dimensions sont en retard ?).
Les 5 dimensions du modèle
Section intitulée « Les 5 dimensions du modèle »Chaque dimension couvre un aspect différent de la maturité DevSecOps. C’est important de comprendre que ces dimensions ne sont pas indépendantes : une faiblesse dans l’une peut compromettre les efforts dans les autres. Par exemple, avoir les meilleurs outils de scan (dimension Build & Deployment) ne sert à rien si personne n’est formé pour interpréter les résultats (dimension Culture & Organization).
La première dimension, Build & Deployment, évalue la sécurité de votre pipeline CI/CD. C’est le cœur technique de la transformation DevSecOps : comment le code est construit, testé et déployé. Les pratiques évaluées incluent le scan de code automatisé (SAST), l’analyse des dépendances (SCA), la génération de SBOM, la signature des artefacts et la gestion des secrets. Une organisation mature sur cette dimension a un pipeline qui détecte les vulnérabilités avant qu’elles n’atteignent la production.
La deuxième dimension, Culture & Organization, mesure la transformation culturelle. Les outils ne suffisent pas si les équipes ne sont pas engagées. Cette dimension évalue l’existence d’un programme Security Champions, la formation des développeurs, la clarté des responsabilités partagées et le sponsorship de la direction. C’est souvent la dimension la plus difficile à améliorer car elle touche aux comportements humains, mais c’est aussi celle qui a le plus d’impact à long terme.
La troisième dimension, Implementation, couvre les pratiques de développement au quotidien. Comment les développeurs écrivent-ils du code sécurisé ? Les guidelines existent-elles ? Les code reviews incluent-elles un angle sécurité ? Le threat modeling est-il pratiqué sur les nouveaux projets ? Cette dimension évalue ce qui se passe avant que le code n’entre dans le pipeline.
La quatrième dimension, Information Gathering, concerne la collecte de données sécurité. Avez-vous un inventaire de vos assets ? Les logs sont-ils centralisés ? Les vulnérabilités sont-elles suivies dans un dashboard ? Les métriques DORA sont-elles mesurées ? Une organisation mature sait à tout moment quelles vulnérabilités existent, depuis combien de temps, et leur niveau de criticité.
Enfin, la cinquième dimension, Test & Verification, évalue vos capacités de validation. Au-delà du SAST et SCA (couverts dans Build & Deployment), cette dimension inclut les tests dynamiques (DAST), le fuzzing, les pentests réguliers et les programmes bug bounty. C’est la dernière ligne de défense avant la production.
Les 4 niveaux de maturité : de réactif à prédictif
Section intitulée « Les 4 niveaux de maturité : de réactif à prédictif »Le modèle DSOMM définit une progression en quatre niveaux. Chaque niveau représente non seulement des pratiques techniques plus avancées, mais surtout un changement de posture face à la sécurité. Passer d’un niveau à l’autre ne se fait pas simplement en ajoutant des outils : cela requiert une évolution dans la façon dont l’organisation pense et traite la sécurité.
Au niveau 1 (Initial), l’équipe fonctionne en mode réactif. Il n’y a pas de processus défini pour la sécurité : quand un incident survient, on improvise. Les vulnérabilités sont découvertes par hasard ou lors d’audits externes. C’est le mode “pompier” que connaissent beaucoup d’organisations — on court d’urgence en urgence sans jamais prendre le temps de construire des fondations solides.
Le niveau 2 (Managed) marque un premier tournant significatif. Certaines pratiques sont documentées et reproductibles, mais pas encore généralisées à tous les projets. L’équipe commence à anticiper plutôt qu’à subir : un scan de vulnérabilités existe peut-être sur les projets critiques, quelques développeurs ont reçu une formation. C’est un stade de transition où les bonnes pratiques émergent mais restent fragiles.
Au niveau 3 (Defined), l’organisation atteint un stade de maturité où les pratiques sont standardisées, documentées et appliquées de manière cohérente. Plus de 75% des projets suivent les mêmes processus. Les métriques sont collectées, les responsabilités sont claires, les exceptions sont gérées formellement. C’est le niveau cible pour la plupart des organisations : suffisamment mature pour être efficace, sans nécessiter les investissements massifs du niveau 4.
Enfin, le niveau 4 (Optimized) représente l’excellence. L’organisation est en amélioration continue : les processus sont régulièrement revus, les métriques guident les décisions, l’approche devient prédictive plutôt que simplement proactive. À ce niveau, la sécurité est intégrée dans l’ADN de l’organisation. C’est l’objectif ultime, mais attention : viser le niveau 4 sur toutes les dimensions n’est ni réaliste ni souhaitable pour la plupart des organisations.
Grille d’auto-évaluation
Section intitulée « Grille d’auto-évaluation »Maintenant que vous comprenez le modèle, passons à l’évaluation concrète. Pour chaque pratique listée dans les sections suivantes, vous attribuerez un score de 0 à 4 selon le niveau d’implémentation dans votre organisation. La clé est d’être honnête : surévaluer votre maturité ne fera que retarder les vraies améliorations.
Le score 0 signifie que la pratique n’existe pas du tout — vous n’avez même pas commencé à y réfléchir. Le score 1 correspond à un pilote : la pratique est testée sur 1 à 2 projets, moins de 25% de couverture. Le score 2 indique une implémentation partielle : entre 25% et 75% des projets sont couverts, mais ce n’est pas généralisé. Le score 3 représente une pratique standardisée : documentée et appliquée sur plus de 75% des projets. Enfin, le score 4 signifie que la pratique est optimisée : mesurée activement et en amélioration continue.
Dimension 1 : Build & Deployment
Section intitulée « Dimension 1 : Build & Deployment »Cette dimension est souvent la plus facile à évaluer car elle porte sur des éléments techniques objectifs : soit vous avez un scan SAST, soit vous n’en avez pas. Prenez le temps de vérifier chaque pratique dans vos pipelines réels, pas dans la documentation théorique.
Pour chaque pratique, cochez le niveau qui correspond à votre situation actuelle :
| # | Pratique | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 1.1 | Pipelines CI/CD définis en code (GitLab CI, GitHub Actions…) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.2 | Scan de vulnérabilités automatisé du code (SAST) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.3 | Analyse des dépendances automatisée (SCA) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.4 | Scan des images conteneur | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.5 | Scan de l’Infrastructure as Code | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.6 | Génération de SBOM pour tous les artefacts | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.7 | Signature des artefacts (images, binaires) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.8 | Gestion centralisée des secrets (vault) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.9 | Environnements éphémères pour les tests | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.10 | Déploiements immuables | ☐ | ☐ | ☐ | ☐ | ☐ |
Score maximum : 40 points
Une fois les cases cochées, additionnez vos points pour cette dimension. Votre score vous indique où concentrer vos efforts :
Score inférieur à 10 points : vous êtes au début du chemin. Les fondamentaux ne sont pas en place. La bonne nouvelle, c’est que les quick wins sont nombreux. Commencez par définir vos pipelines en code si ce n’est pas déjà fait — c’est le prérequis à tout le reste. Ensuite, ajoutez un scan SCA (Trivy ou Grype sont gratuits et faciles à intégrer) et centralisez vos secrets avec une solution comme HashiCorp Vault ou même SOPS pour commencer.
Score entre 10 et 25 points : vous avez des bases, mais l’industrialisation manque. C’est le moment d’ajouter un SAST automatisé sur toutes les PRs (Semgrep est un excellent choix open source), de scanner votre Infrastructure as Code avec Checkov, et de commencer à générer des SBOM avec Syft. L’objectif est de passer de “quelques projets couverts” à “tous les projets couverts”.
Score supérieur à 25 points : vos fondamentaux sont solides. Vous pouvez maintenant viser l’excellence avec la signature d’artefacts (Cosign), les environnements éphémères, et les déploiements immuables. Ces pratiques demandent plus d’investissement mais apportent un niveau de sécurité supply chain significatif.
Dimension 2 : Culture & Organization
Section intitulée « Dimension 2 : Culture & Organization »Cette dimension est plus subjective que la précédente. Un “programme Security Champions” peut signifier beaucoup de choses différentes selon les organisations. Soyez rigoureux dans votre évaluation : un champion nommé mais jamais formé et sans temps alloué n’est pas vraiment un champion.
| # | Pratique | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 2.1 | Sponsorship explicite de la direction pour la sécurité | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.2 | Programme Security Champions actif | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.3 | Formation sécurité régulière pour les développeurs | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.4 | Responsabilités partagées documentées (matrice RACI) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.5 | Rétrospectives incluant un volet sécurité | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.6 | Collaboration Dev / Sec / Ops formalisée | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.7 | Standards de sécurité documentés et accessibles | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.8 | Processus d’exception documenté et suivi | ☐ | ☐ | ☐ | ☐ | ☐ |
Score maximum : 32 points
Score inférieur à 8 points : la sécurité n’est pas encore ancrée dans la culture. C’est souvent le cas dans les organisations où la sécurité est vue comme la responsabilité d’une équipe dédiée plutôt que comme une responsabilité partagée. La priorité absolue est d’obtenir un sponsor au COMEX — sans appui de la direction, les initiatives de sécurité s’essoufflent. En parallèle, identifiez 1 à 2 Security Champions par équipe : des développeurs volontaires qui serviront de relais.
Score entre 8 et 20 points : les fondations existent mais manquent de structure. Vous avez probablement des champions nommés mais pas formés, ou une formation ponctuelle mais pas régulière. L’effort doit porter sur la formalisation : documenter les standards, créer un programme de formation structuré (pas juste un one-shot), intégrer la sécurité dans les rétrospectives de sprint. Le processus d’exception est souvent négligé à ce stade — c’est pourtant crucial pour éviter les “shadow IT” où les équipes contournent les règles sans les documenter.
Score supérieur à 20 points : votre culture sécurité est solide. L’enjeu maintenant est l’amélioration continue : mesurer l’efficacité des formations, faire évoluer le rôle des champions, documenter les lessons learned. Les organisations à ce niveau commencent souvent à partager leurs pratiques en externe (conférences, blog posts), ce qui renforce l’engagement des équipes.
Dimension 3 : Implementation
Section intitulée « Dimension 3 : Implementation »Cette dimension évalue ce qui se passe avant que le code n’entre dans le pipeline. Les meilleures protections automatisées du monde ne rattrapent pas un code mal conçu dès le départ. Le threat modeling, les guidelines de secure coding et les pre-commit hooks sont des investissements qui paient sur le long terme.
| # | Pratique | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 3.1 | Guidelines de secure coding documentées | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.2 | Code review incluant systématiquement la sécurité | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.3 | Pre-commit hooks (détection secrets, linting) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.4 | Gestion des dépendances avec lock files | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.5 | Mise à jour régulière et automatisée des dépendances | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.6 | Threat modeling pour les nouveaux projets | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.7 | Validation systématique des inputs utilisateur | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.8 | Gestion sécurisée des erreurs (pas d’info sensible) | ☐ | ☐ | ☐ | ☐ | ☐ |
Score maximum : 32 points
Score inférieur à 8 points : les développeurs codent sans filet de sécurité. Commencez par les pratiques les plus faciles à adopter : installer des pre-commit hooks avec Gitleaks pour détecter les secrets avant le commit, épingler toutes les dépendances avec des lock files, et activer Dependabot ou Renovate pour automatiser les mises à jour. Ces actions ne changent pas radicalement les habitudes de développement mais créent une première couche de protection.
Score entre 8 et 20 points : vous avez les bases mais pas la systématisation. L’effort doit porter sur deux axes : formaliser les guidelines de secure coding (elles existent souvent dans la tête des seniors mais pas sur papier), et intégrer la sécurité dans les code reviews. Pour ce dernier point, une checklist simple suffit au début. Le threat modeling sur les projets critiques est aussi un excellent investissement : 2-3 heures en début de projet peuvent éviter des semaines de remediation plus tard.
Score supérieur à 20 points : vos pratiques de développement intègrent la sécurité. Vous pouvez maintenant affiner : systématiser le threat modeling avec une méthodologie comme STRIDE ou PASTA, améliorer la qualité des code reviews avec des outils d’aide à la décision, former les équipes aux patterns de secure coding spécifiques à vos technologies.
Dimension 4 : Information Gathering
Section intitulée « Dimension 4 : Information Gathering »Cette dimension est souvent la plus négligée. Les organisations investissent dans les outils de détection mais pas dans l’observabilité. Résultat : elles détectent des vulnérabilités mais ne savent pas lesquelles prioriser, ne mesurent pas leur temps de correction, et ne peuvent pas démontrer leur progression.
| # | Pratique | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 4.1 | Inventaire des assets à jour (CMDB) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.2 | Centralisation des logs sécurité | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.3 | Alerting automatisé sur événements sécurité | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.4 | Tableau de bord vulnérabilités centralisé | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.5 | Métriques DORA collectées et suivies | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.6 | Métriques sécurité (MTTD, MTTR) mesurées | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.7 | Veille vulnérabilités (flux CVE critiques) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.8 | Threat intelligence intégrée | ☐ | ☐ | ☐ | ☐ | ☐ |
Score maximum : 32 points
Score inférieur à 8 points : vous êtes en aveugle. Vous détectez peut-être des vulnérabilités mais vous ne savez pas combien, depuis quand, ni lesquelles sont critiques. La priorité est de centraliser les logs (Loki ou Elastic en open source) et de créer un dashboard vulnérabilités simple. Inscrivez-vous aux flux CVE critiques de vos technologies principales — c’est gratuit et ça prend 5 minutes.
Score entre 8 et 20 points : vous avez de la visibilité mais pas de métriques. C’est le moment d’implémenter les 4 métriques DORA (Deployment Frequency, Lead Time, MTTR, Change Failure Rate) et leurs équivalents sécurité (Mean Time To Detect, Mean Time To Remediate). Ces métriques sont indispensables pour démontrer la valeur de vos investissements sécurité à la direction.
Score supérieur à 20 points : vous avez une excellente observabilité. L’étape suivante est l’intégration de la threat intelligence : croiser vos vulnérabilités avec les menaces actives pour prioriser intelligemment. Les organisations les plus matures à ce niveau utilisent aussi l’IA pour détecter des patterns anormaux.
Dimension 5 : Test & Verification
Section intitulée « Dimension 5 : Test & Verification »Cette dimension complète la dimension Build & Deployment en ajoutant les tests plus avancés : DAST, fuzzing, pentests et bug bounty. C’est la dernière ligne de défense avant la production.
| # | Pratique | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 5.1 | Tests unitaires de sécurité dans la CI | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.2 | SAST automatisé sur toutes les PRs | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.3 | DAST automatisé en environnement de test | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.4 | SCA automatisé avec alertes bloquantes | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.5 | Fuzzing sur les composants critiques | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.6 | Pentests réguliers (au moins annuels) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.7 | Programme bug bounty actif | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.8 | Validation systématique des remediations | ☐ | ☐ | ☐ | ☐ | ☐ |
Score maximum : 32 points
Score inférieur à 8 points : vous n’avez pas de filet de sécurité automatisé. La priorité est d’ajouter SCA automatisé (Trivy est le plus simple à intégrer) et SAST sur les PRs (Semgrep offre un excellent rapport qualité/prix pour commencer). Planifiez aussi un pentest annuel sur vos applications critiques — c’est souvent une exigence réglementaire ou contractuelle.
Score entre 8 et 20 points : vous avez les tests de base mais pas les tests avancés. Ajoutez le DAST automatisé (ZAP ou Nuclei) pour compléter le SAST. Le fuzzing est un excellent investissement pour les APIs critiques. Si vous n’avez pas encore de pentests réguliers, passez à un rythme trimestriel sur les applications exposées.
Score supérieur à 20 points : vos tests sont matures. Le bug bounty est le niveau suivant : il apporte une perspective externe et continue que les pentests ponctuels ne peuvent pas offrir. Commencez par un programme privé avec quelques chercheurs de confiance avant de passer en public.
Calculer et interpréter votre score global
Section intitulée « Calculer et interpréter votre score global »Une fois les 5 dimensions évaluées, vous disposez d’une image complète de votre maturité DevSecOps. Le score global donne une indication du niveau moyen, mais c’est surtout la répartition par dimension qui guide les actions.
Synthèse des scores
Section intitulée « Synthèse des scores »Reportez vos scores dans le tableau ci-dessous pour avoir une vue d’ensemble :
| Dimension | Score obtenu | Score max | Pourcentage |
|---|---|---|---|
| Build & Deployment | ___ | 40 | ___% |
| Culture & Organization | ___ | 32 | ___% |
| Implementation | ___ | 32 | ___% |
| Information Gathering | ___ | 32 | ___% |
| Test & Verification | ___ | 32 | ___% |
| TOTAL | ___ | 168 | ___% |
Interpréter le score global
Section intitulée « Interpréter le score global »Le score total donne une indication du niveau de maturité global de votre organisation. Cependant, gardez en tête qu’une moyenne peut masquer des disparités importantes. Une organisation avec 80% en Build & Deployment mais 20% en Culture n’est pas vraiment à 50% de maturité — elle a un déséquilibre qui limite l’efficacité de ses investissements techniques.
Un score entre 0 et 40 points (niveau Initial) indique que la sécurité fonctionne en mode réactif. Les pratiques sont ad-hoc, il n’y a pas de processus défini. L’organisation découvre les problèmes quand ils surviennent, souvent par des sources externes (audits, incidents, clients). C’est le point de départ de beaucoup d’organisations, et ce n’est pas une honte — l’important est de commencer à structurer.
Un score entre 41 et 80 points (niveau Managed) signifie que certains processus sont en place mais pas généralisés. C’est le stade où les bonnes pratiques émergent : quelques projets ont un pipeline sécurisé, quelques développeurs sont formés, quelques métriques sont collectées. L’enjeu est maintenant de passer de “quelques” à “tous”.
Un score entre 81 et 120 points (niveau Defined) représente une organisation où les pratiques sont standardisées et mesurées. Plus de 75% des projets suivent les mêmes processus. L’organisation est proactive : elle anticipe les problèmes plutôt que de les subir. C’est le niveau cible pour la plupart des entreprises.
Enfin, un score entre 121 et 168 points (niveau Optimized) caractérise une organisation en amélioration continue. Les processus sont régulièrement revus, les décisions sont guidées par les données, l’approche devient prédictive. À ce niveau, l’organisation est souvent une référence dans son secteur et partage ses pratiques.
Identifier les priorités d’action
Section intitulée « Identifier les priorités d’action »Le score global est moins important que les écarts entre dimensions. Visualisez vos résultats pour identifier les déséquilibres :
Build & Deployment: 32/40 (80%) ████████░░Culture & Organization: 12/32 (38%) ████░░░░░░ ← PrioritéImplementation: 20/32 (63%) ██████░░░░Information Gathering: 8/32 (25%) ███░░░░░░░ ← PrioritéTest & Verification: 24/32 (75%) ████████░░Dans cet exemple, malgré un bon score technique (Build & Deployment à 80%), l’organisation a deux points faibles majeurs : Culture & Organization et Information Gathering. Investir davantage dans les outils techniques aurait peu d’impact tant que la culture et l’observabilité ne sont pas renforcées.
Plan d’action : prioriser par ROI
Section intitulée « Plan d’action : prioriser par ROI »Une fois les priorités identifiées, il faut construire une roadmap réaliste. Toutes les actions ne se valent pas : certaines demandent peu d’effort pour un impact immédiat, d’autres nécessitent des mois de travail. La clé est de prioriser par ratio effort/impact.
Matrice de priorisation
Section intitulée « Matrice de priorisation »Classez chaque action dans l’une des quatre catégories :
Priorité P0 (Quick wins) : faible effort, impact immédiat. Ce sont les actions à faire dans les 2 premières semaines. Exemples : installer des pre-commit hooks, activer Dependabot, créer un channel Slack dédié à la sécurité. Ces actions ne transforment pas l’organisation mais créent une dynamique positive.
Priorité P1 (Fondations) : effort moyen, impact structurant. Ces actions prennent 1 à 3 mois mais construisent les bases de la transformation. Exemples : lancer un programme Security Champions, implémenter les métriques DORA, documenter les standards de sécurité. Sans ces fondations, les améliorations techniques restent fragiles.
Priorité P2 (Optimisation) : effort élevé, impact à long terme. Ces actions prennent 3 à 6 mois et demandent des investissements significatifs. Exemples : atteindre SLSA Level 3, intégrer la threat intelligence, automatiser le threat modeling. Elles ne sont pertinentes qu’une fois les fondations en place.
Priorité P3 (Excellence) : effort très élevé, différenciation. Ces actions prennent 6 à 12 mois et positionnent l’organisation comme référence. Exemples : programme bug bounty public, IA pour la détection d’anomalies, contribution à des projets open source de sécurité.
Exemple de roadmap 12 mois
Section intitulée « Exemple de roadmap 12 mois »Voici comment une organisation typique pourrait structurer sa transformation sur 12 mois, en partant d’un score initial de 46/168 :
-
Mois 1-3 : Quick wins (P0)
L’objectif de cette première phase est de créer une dynamique visible rapidement. Les équipes doivent voir que quelque chose change, et la direction doit voir des premiers résultats.
Concrètement, installez des pre-commit hooks avec Gitleaks sur tous les repos — c’est une action qui prend une journée et qui évite immédiatement les fuites de secrets. Activez SCA automatisé avec Trivy sur tous les pipelines : moins d’une heure de configuration par projet, et vous avez une visibilité immédiate sur les CVE de vos dépendances.
Centralisez les secrets dans HashiCorp Vault ou au minimum dans les secrets managers de vos plateformes CI/CD. Enfin, créez un dashboard vulnérabilités simple dans Grafana ou Kibana pour visualiser l’état de la sécurité.
Résultat attendu : +15 points, principalement sur Build & Deployment.
-
Mois 4-6 : Fondations culturelles (P1)
Cette phase est la plus importante sur le long terme, même si elle est moins visible que la précédente. Sans changement culturel, les outils techniques seront contournés ou ignorés.
Identifiez et formez 1 Security Champion par équipe de développement. Ce n’est pas une charge à temps plein : 2-4 heures par semaine suffisent. Formez-les ensemble pour créer une communauté. Obtenez un sponsorship explicite de la direction : un message du CTO ou CEO sur l’importance de la sécurité fait une différence énorme.
Documentez les standards de sécurité de façon accessible. Un wiki interne avec des exemples concrets vaut mieux qu’un document de 200 pages que personne ne lit. Documentez aussi le processus d’exception : comment une équipe peut-elle déroger à une règle de façon contrôlée ?
Résultat attendu : +25 points, principalement sur Culture & Organization.
-
Mois 7-9 : Pipeline sécurisé (P1)
Avec les fondations culturelles en place, l’investissement technique prend tout son sens. Les équipes comprennent pourquoi ces outils sont importants et sont prêtes à les adopter.
Ajoutez SAST automatisé sur toutes les PRs avec Semgrep. Scannez votre Infrastructure as Code avec Checkov ou KICS. Générez des SBOM automatiquement avec Syft sur tous les artefacts. Intégrez DAST avec ZAP ou Nuclei sur les environnements de test.
L’objectif est que chaque commit soit analysé sous tous les angles avant d’atteindre la production.
Résultat attendu : +20 points, sur Build & Deployment et Test & Verification.
-
Mois 10-12 : Excellence et supply chain (P2)
Cette dernière phase amène l’organisation vers l’excellence. Les pratiques de base sont maîtrisées, il est temps d’aller plus loin.
Signez tous les artefacts avec Cosign pour garantir leur intégrité. Visez SLSA Level 2 sur les projets critiques. Passez à un rythme de pentests trimestriel plutôt qu’annuel. Commencez à explorer les options de bug bounty avec un programme privé.
Résultat attendu : +15 points, sur Test & Verification et Build & Deployment.
Scénario concret : startup série A
Section intitulée « Scénario concret : startup série A »Pour illustrer comment cette méthodologie s’applique en pratique, prenons l’exemple d’une startup SaaS de 50 personnes qui vient de lever sa série A.
Le contexte
L’entreprise développe une plateforme B2B de gestion de données clients. Elle a 8 développeurs, 2 ops et un RSSI fraîchement recruté. Les investisseurs exigent une certification SOC 2 Type II dans les 18 mois. L’équipe n’a jamais fait d’audit de maturité et ne sait pas par où commencer.
L’évaluation initiale
Section intitulée « L’évaluation initiale »Le RSSI nouvellement arrivé réalise une première évaluation DSOMM. Les résultats sont sans surprise mais objectivent la situation :
| Dimension | Score | Constat |
|---|---|---|
| Build & Deployment | 12/40 | Pipeline CI/CD existe mais aucun scan de sécurité |
| Culture & Organization | 6/32 | Pas de formation, pas de champion, sécurité = le RSSI |
| Implementation | 14/32 | Lock files utilisés, quelques pre-commit hooks |
| Information Gathering | 4/32 | Aucune centralisation des logs, pas de métriques |
| Test & Verification | 10/32 | Un pentest l’année dernière, jamais de suivi |
| TOTAL | 46/168 | Niveau Managed (bas) |
Ce score de 46/168 place l’organisation au bas du niveau Managed. La dimension la plus critique est Information Gathering (4/32) : sans visibilité, impossible de piloter. Culture & Organization (6/32) est le second point faible : la sécurité repose entièrement sur une personne.
Le plan d’action SOC 2
Section intitulée « Le plan d’action SOC 2 »Le RSSI présente un plan sur 18 mois aligné avec l’objectif SOC 2 :
-
Mois 1-3 : Fondations techniques SOC 2
Score cible : passer de 46 à 76 points (+30).
Les actions prioritaires sont dictées par les exigences SOC 2 : SCA et SAST automatisés sur tous les repos (obligation de détection des vulnérabilités), centralisation des secrets dans Vault (obligation de gestion des accès), 2 Security Champions nommés parmi les développeurs seniors (obligation de responsabilités définies).
Le sponsorship du CEO est obtenu lors d’une présentation au COMEX où le RSSI montre l’écart entre la situation actuelle et les exigences SOC 2.
-
Mois 4-9 : Culture et processus
Score cible : passer de 76 à 101 points (+25).
Un programme de formation trimestriel est lancé : 2 heures par développeur, avec des cas pratiques sur les vulnérabilités de leur propre code. Les standards de sécurité sont documentés dans Notion et intégrés à l’onboarding.
Les métriques DORA sont collectées automatiquement via le plugin Four Keys. Un dashboard Grafana consolide vulnérabilités, métriques de performance et incidents.
-
Mois 10-15 : Consolidation SOC 2
Score cible : passer de 101 à 121 points (+20).
SBOM générés sur tous les artefacts et stockés. Signature des images Docker avec Cosign. Pentests trimestriels avec un partenaire externe. Processus d’exception rodé avec approbation formelle et suivi des dérogations.
L’audit SOC 2 Type I est programmé au mois 14.
-
Mois 16-18 : Audit et certification
L’audit SOC 2 Type I passe sans réserve majeure au mois 14. Les 4 mois suivants sont consacrés à la collecte des preuves pour le Type II : logs d’accès, rapports de scan, métriques de correction, procès-verbaux de revue des exceptions.
Résultat final : Score passé de 46 à 121/168 (niveau Optimized). Certification SOC 2 Type II obtenue au mois 18.
Les clés du succès
Section intitulée « Les clés du succès »Trois facteurs ont été déterminants dans la réussite de cette transformation. Premièrement, l’objectif externe clair (SOC 2) a aligné toute l’organisation. Sans cette échéance, les priorités auraient été constamment remises en question.
Deuxièmement, l’évaluation régulière (tous les 3 mois) a permis de mesurer les progrès et d’ajuster le plan. Au mois 6, le RSSI a constaté que la dimension Culture progressait moins vite que prévu et a renforcé les actions.
Troisièmement, le sponsorship de la direction a débloqué les ressources (budget formation, temps alloué aux champions) et envoyé un message fort aux équipes.
Frameworks de référence
Section intitulée « Frameworks de référence »Le DSOMM n’est pas le seul framework disponible. Selon votre contexte, d’autres modèles peuvent être pertinents :
OWASP DSOMM reste le choix par défaut pour la plupart des organisations. Il est gratuit, maintenu par une communauté active, et suffisamment détaillé pour guider l’action sans être écrasant. L’outil d’évaluation en ligne sur dsomm.owasp.org permet de démarrer en 30 minutes.
OWASP SAMM (Software Assurance Maturity Model) est plus large que le DSOMM : il couvre tout le cycle de vie du développement logiciel, pas seulement les aspects DevSecOps. Il est idéal pour les organisations qui veulent une vue encore plus complète, mais demande plus de temps à administrer.
BSIMM (Building Security In Maturity Model) est orienté benchmark : il permet de se comparer à d’autres organisations du même secteur. C’est utile pour les grandes entreprises qui veulent savoir où elles se situent par rapport à leurs pairs, mais l’évaluation nécessite généralement un consultant externe.
DORA n’est pas un modèle de maturité sécurité mais les 4 métriques de performance DevOps sont complémentaires. Une organisation mature en sécurité mais avec un Deployment Frequency de 1 par mois a un problème. Les deux approches se renforcent mutuellement.
Prérequis recommandés
Section intitulée « Prérequis recommandés »Pour aller plus loin
Section intitulée « Pour aller plus loin »À retenir
Section intitulée « À retenir »L’évaluation de maturité DevSecOps n’est pas un exercice théorique — c’est le point de départ de toute transformation efficace. Sans savoir d’où vous partez, vous ne pouvez ni choisir le bon chemin ni mesurer vos progrès.
Le modèle OWASP DSOMM structure cette évaluation en 5 dimensions (Build & Deployment, Culture & Organization, Implementation, Information Gathering, Test & Verification) et 4 niveaux de maturité (Initial, Managed, Defined, Optimized). Chaque dimension couvre un aspect différent : les outils ne suffisent pas sans la culture, la culture ne suffit pas sans l’observabilité.
Pour utiliser ce guide, scorez chaque pratique de 0 à 4 en étant honnête sur votre situation réelle. Le score global importe moins que les écarts entre dimensions : une organisation avec 80% en technique mais 20% en culture a un déséquilibre qui limite l’efficacité de tous ses investissements.
Priorisez ensuite par ROI : commencez par les quick wins (P0) qui créent une dynamique, puis construisez les fondations culturelles (P1) avant d’investir dans l’optimisation technique (P2). Sans cette séquence, les outils seront contournés ou mal utilisés.
Réévaluez tous les 6 mois pour mesurer la progression et ajuster le plan. Entre les évaluations, suivez les métriques DORA pour un feedback continu. Et n’oubliez pas : la maturité technique sans engagement culturel (Security Champions, formation, sponsorship direction) ne produit pas de résultats durables.