L'OWASP DSOMM (DevSecOps Maturity Model) est le référentiel libre qui décrit, activité par activité, ce qu'une organisation fait en sécurité dans sa chaîne DevOps, et à quel niveau de maturité. Cette leçon en tire une grille d'auto-évaluation à dérouler en une demi-journée, notée sur 168 points, puis un plan d'action priorisé. Elle s'adresse au RSSI, au tech lead ou au DevSecOps qui doit établir une baseline avant d'investir.
Les chiffres du modèle ont été relevés le 1er octobre 2026 dans ses données officielles, en version 5.1.0 : six dimensions, dont une dimension Agentic AI ajoutée en août 2026, 24 sous-dimensions, 251 activités réparties sur cinq niveaux. La grille de la leçon en retient les cinq dimensions historiques ; pour un modèle plus générique, voyez Maturité et roadmap DevSecOps.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comprendre le modèle OWASP DSOMM, ses dimensions et ses cinq niveaux
- Scorer objectivement vos pratiques DevSecOps de 0 à 4 sur chaque dimension
- Interpréter votre score global et identifier les déséquilibres entre dimensions
- Prioriser vos actions par ratio effort/impact (quick wins, fondations, optimisation)
- Construire une roadmap de transformation réaliste sur 12 à 18 mois
Prérequis
Section intitulée « Prérequis »Avant de dérouler la grille, assurez-vous de partager un vocabulaire commun avec votre équipe. Un audit de maturité perd de sa valeur si chaque participant a une définition différente du DevOps ou du DevSecOps : les scores deviennent subjectifs et incomparables d'une session à l'autre. Ces deux pages posent les bases avant de noter vos pratiques.
- Culture DevOps : les principes fondamentaux avant de parler sécurité.
- Introduction DevSecOps : le cadre global et les objectifs de la transformation.
Pourquoi évaluer sa maturité ?
Section intitulée « Pourquoi évaluer sa maturité ? »Avant de lancer une transformation DevSecOps, il faut savoir d'où l'on part. Beaucoup d'organisations achètent des outils, recrutent et forment sans avoir établi de baseline (état de référence mesuré) : impossible ensuite de mesurer le progrès, et sans mesure, impossible de justifier les investissements auprès de la direction.
L'évaluation répond à trois questions. Où en sommes-nous ? Le livrable est un score par dimension, qui montre forces et faiblesses. Par où commencer ? Le livrable est une roadmap priorisée, qui place d'abord les actions au meilleur rapport impact/effort. Progressons-nous ? Le livrable est le delta entre deux évaluations, preuve tangible du retour sur investissement.
Le modèle OWASP DSOMM
Section intitulée « Le modèle OWASP DSOMM »L'OWASP DevSecOps Maturity Model est un projet communautaire de la fondation OWASP. Ses données sont publiées dans un dépôt ouvert et servies par l'outil web dsomm.owasp.org, qui permet de cocher les activités déjà en place. Il est concret : chaque activité décrit une pratique vérifiable, comme un scan de dépendances automatisé ou une gestion centralisée des secrets.
Le modèle structure ces activités en dimensions, elles-mêmes découpées en
sous-dimensions. Le tableau donne la structure de la version 5.1.0, relevée
dans le fichier generated/model.yaml du dépôt
devsecopsmaturitymodel/DevSecOps-MaturityModel-data.
| Dimension | Sous-dimensions | Activités |
|---|---|---|
| Build and Deployment | Build, Deployment, Patch Management | 29 |
| Culture and Organization | Design, Education and Guidance, Process | 28 |
| Implementation | Application Hardening, Development and Source Control, Identity and Access Management, Infrastructure Hardening | 55 |
| Information Gathering | Logging, Monitoring, Test KPI | 31 |
| Test and Verification | Application tests, Consolidation, Dynamic et Static depth (applications, infrastructure), Test Intensity | 68 |
| Agentic AI (depuis la 5.0.0) | Data Protection, Guidance, Isolation, Verification | 40 |
Les 5 dimensions retenues par la grille
Section intitulée « Les 5 dimensions retenues par la grille »Chaque dimension couvre un aspect différent, et elles ne sont pas indépendantes : les meilleurs outils de scan (Build and Deployment) ne servent à rien si personne n'est formé à lire leurs résultats (Culture and Organization). La grille retient les cinq dimensions historiques ; la dimension Agentic AI concerne les équipes qui déploient des agents d'IA.
La première dimension, Build and 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 and 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 (l'exercice qui consiste à identifier les scénarios d'attaque possibles avant même d'écrire le code) 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 and Verification, évalue vos capacités de validation. Au-delà du SAST et SCA (couverts dans Build and 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 niveaux de maturité du DSOMM
Section intitulée « Les niveaux de maturité du DSOMM »Le DSOMM définit cinq niveaux, qui mesurent le degré d'adoption des pratiques de sécurité, et non un outillage. Passer d'un niveau à l'autre demande surtout un changement de posture : une activité de niveau 1 suppose une compréhension de base, une activité de niveau 5 une organisation qui l'applique à l'échelle.
Les intitulés officiels, en anglais dans le modèle, sont : Level 1 « Basic understanding of security practices », Level 2 « Adoption of basic security practices », Level 3 « High adoption of security practices », Level 4 « Very high adoption of security practices » et Level 5 « Advanced deployment of security practices at scale ». Sur les 211 activités des cinq dimensions historiques, la plupart se situent aux niveaux 2 et 3.
La grille de la leçon traduit ces niveaux en quatre paliers de score, une convention propre à cette page : Initial (réactif, pratiques ad hoc), Managed (pratiques documentées sur quelques projets), Defined (pratiques standardisées sur plus de 75 % des projets) et Optimized (pratiques mesurées et en amélioration continue). Ces noms rappellent ceux de modèles comme le CMMI ; ils ne sont pas ceux du DSOMM.
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 and Deployment
Section intitulée « Dimension 1 : Build and 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.
Sur le site, l'analyse statique est traitée par le guide SAST, les dépendances par SCA, l'inventaire des composants par le SBOM et la gestion centralisée des secrets par HashiCorp Vault : quatre activités DSOMM de cette dimension, chacune avec son outil de référence.
Dimension 2 : Culture and Organization
Section intitulée « Dimension 2 : Culture and 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.
Pour progresser sur cette dimension, voir le programme Security Champions, la formation des équipes et les responsabilités partagées : ce sont les leviers humains qui font monter les niveaux de la culture.
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.
Les guides Gitleaks pour les secrets dans le code, menaces et risques pour l'analyse de risque, et OWASP Top 10 CI/CD pour les menaces propres aux pipelines couvrent les activités de cette dimension.
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 métriques DORA, cinq depuis le rapport 2024 (délai de mise en production, fréquence de déploiement, temps de rétablissement, taux d'échec des changements et taux de reprise, ou rework 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. Le détail de ces indicateurs et de leur évolution récente est couvert dans notre page dédiée aux métriques DORA.
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.
Les métriques DORA et leur implémentation donnent les indicateurs de livraison, et comprendre les CVE apprend à lire CVSS et EPSS pour prioriser les vulnérabilités collectées.
Dimension 5 : Test and Verification
Section intitulée « Dimension 5 : Test and Verification »Cette dimension complète la dimension Build and 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.
Les tests de sécurité automatisés donnent la vue d'ensemble, puis DAST, Trivy et Semgrep montrent la vérification en pratique : application qui tourne, image et dépendances, code source.
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 : le schéma ci-dessous rappelle les cinq dimensions qui composent ce score, et le tableau de synthèse qui le suit les met côte à côte.
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. Le score maximum diffère selon la dimension (40 points pour Build and Deployment, 32 pour les quatre autres) parce que le nombre de pratiques évaluées n'est pas identique. C'est pourquoi la colonne pourcentage est la seule base de comparaison fiable entre dimensions : un score brut de 24 ne veut pas dire la même chose sur une échelle à 32 points que sur une échelle à 40.
| Dimension | Score obtenu | Score max | Pourcentage |
|---|---|---|---|
| Build and Deployment | ___ | 40 | ___% |
| Culture and Organization | ___ | 32 | ___% |
| Implementation | ___ | 32 | ___% |
| Information Gathering | ___ | 32 | ___% |
| Test and Verification | ___ | 32 | ___% |
| TOTAL | ___ | 168 | ___% |
Interpréter le score global
Section intitulée « Interpréter le score global »Le score total donne une indication du palier de maturité global de votre organisation. Gardez en tête qu'une moyenne peut masquer des disparités importantes : une organisation avec 80 % en Build and 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 (palier 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 : l'important est de commencer à structurer.
Un score entre 41 et 80 points (palier 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 (palier 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 la cible raisonnable pour la plupart des entreprises.
Enfin, un score entre 121 et 168 points (palier 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.
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 repérer les déséquilibres, par exemple avec une simple barre de progression par dimension :
Build and Deployment: 32/40 (80%) ████████░░Culture and Organization: 12/32 (38%) ████░░░░░░ ← PrioritéImplementation: 20/32 (63%) ██████░░░░Information Gathering: 8/32 (25%) ███░░░░░░░ ← PrioritéTest and Verification: 24/32 (75%) ████████░░Dans cet exemple, malgré un bon score technique (Build and Deployment à 80 %), l'organisation a deux points faibles majeurs : Culture and 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, le ROI (retour sur investissement) de chaque action.
Matrice de priorisation
Section intitulée « Matrice de priorisation »Chaque action se range dans l'une des quatre catégories ci-dessous, de la moins coûteuse à la plus ambitieuse. Le classement dit à la fois la séquence de lancement et l'horizon à partir duquel on peut en attendre l'effet.
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 canal de messagerie 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 Build 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, détection d'anomalies outillée, 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 pourrait structurer sa transformation sur 12 mois, en partant d'un score initial de 46/168. Le schéma donne les quatre phases et le gain de points attendu de chacune, le détail suit.
-
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 dépôts, une action qui prend une journée et évite immédiatement les fuites de secrets. Activez une SCA automatisée avec Trivy sur tous les pipelines pour obtenir une visibilité immédiate sur les CVE de vos dépendances.
Centralisez les secrets dans HashiCorp Vault ou au minimum dans les gestionnaires de secrets de vos plateformes CI/CD. Enfin, créez un tableau de bord des vulnérabilités simple dans Grafana ou Kibana.
Résultat attendu : +15 points, principalement sur Build and 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 un Security Champion par équipe de développement. Ce n'est pas une charge à temps plein : quelques heures par semaine suffisent. Formez-les ensemble pour créer une communauté. Obtenez un sponsorship explicite de la direction : un message du CTO ou du CEO sur l'importance de la sécurité fait une différence nette.
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 and 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 un SAST automatisé sur toutes les merge requests 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 un DAST avec ZAP ou Nuclei sur les environnements de test.
Résultat attendu : +20 points, sur Build and Deployment et Test and Verification.
-
Mois 10-12 : Excellence et supply chain (P2)
Cette dernière phase amène l'organisation plus loin, une fois les pratiques de base maîtrisées.
Signez tous les artefacts avec Cosign pour garantir leur intégrité. Visez SLSA Build Level 2 sur les projets critiques, première marche vers le niveau 3 de la priorité P2. Passez à un rythme de pentests trimestriel plutôt qu'annuel. Commencez à explorer un programme de bug bounty privé.
Résultat attendu : +15 points, sur Test and Verification et Build and Deployment.
Scénario concret : startup série A
Section intitulée « Scénario concret : startup série A »Pour illustrer la méthode, prenons un scénario fictif, construit pour l'exemple : une startup SaaS de 50 personnes qui vient de lever sa série A. Ses chiffres servent à montrer le raisonnement, pas à promettre un résultat.
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 un rapport 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.
Le SOC 2 n'est pas une certification : c'est un rapport d'attestation émis par un auditeur indépendant selon les Trust Services Criteria de l'AICPA. Le Type I décrit les contrôles à une date donnée, le Type II vérifie qu'ils ont fonctionné sur une période d'observation, de plusieurs mois.
L'évaluation initiale
Section intitulée « L'évaluation initiale »Le RSSI réalise une première évaluation avec la grille. Les résultats sont sans surprise, mais ils objectivent la situation et donnent une baseline chiffrée à présenter au comité de direction.
| Dimension | Score | Constat |
|---|---|---|
| Build and Deployment | 12/40 | Pipeline CI/CD existant mais aucun scan de sécurité |
| Culture and 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 and Verification | 10/32 | Un pentest l'année dernière, jamais de suivi |
| TOTAL | 46/168 | Palier Managed (bas) |
Ce score de 46/168 place l'organisation au bas du palier Managed. La dimension la plus critique est Information Gathering (4/32) : sans visibilité, impossible de piloter. Culture and 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. Chaque phase vise un score et des critères du référentiel : le critère CC7.1 demande par exemple des procédures de détection pour identifier les vulnérabilités nouvellement découvertes.
-
Mois 1-3 : Fondations techniques
Score cible : passer de 46 à 76 points (+30).
Les actions prioritaires répondent aux critères SOC 2 : SCA et SAST automatisés sur tous les dépôts (détection des vulnérabilités, CC7.1), centralisation des secrets dans Vault (gestion des accès logiques, famille CC6), deux Security Champions nommés parmi les développeurs seniors (responsabilités définies).
Le sponsorship du CEO est obtenu lors d'une présentation au comité de direction où le RSSI montre l'écart entre la situation actuelle et les attentes de l'auditeur.
-
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 et intégrés à l'onboarding.
Les métriques DORA sont collectées automatiquement avec Apache DevLake, le projet Four Keys de Google étant archivé depuis 2024. Un tableau de bord Grafana consolide vulnérabilités, métriques de performance et incidents.
-
Mois 10-14 : Consolidation et audit Type I
Score cible : passer de 101 à 121 points (+20).
SBOM générés et stockés pour tous les artefacts. Signature des images 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 a lieu au mois 14 et ne relève pas de réserve majeure.
-
Mois 15-18 : Période d'observation et rapport Type II
Les mois qui suivent forment la période d'observation du Type II : l'équipe collecte les preuves que l'auditeur examinera (journaux d'accès, rapports de scan, délais de correction, revues des exceptions).
Résultat du scénario : score passé de 46 à 121/168 (palier Optimized) et rapport SOC 2 Type II remis au mois 18.
Les clés du succès
Section intitulée « Les clés du succès »Trois facteurs font la réussite de ce scénario. Premièrement, l'objectif externe clair (SOC 2) aligne 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 dans ce scénario, permet de mesurer les progrès et d'ajuster le plan : si la dimension Culture progresse moins vite que prévu, on renforce les actions au lieu de le découvrir à la fin.
Troisièmement, le sponsorship de la direction débloque les ressources (budget de formation, temps alloué aux champions) et envoie 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 sont pertinents ; ces repères ont été vérifiés le 1er octobre 2026 à leur source.
OWASP DSOMM reste le choix par défaut pour une évaluation centrée sur la chaîne DevOps. Il est gratuit, maintenu par une communauté active (version 5.1.0 du modèle publiée le 21 septembre 2026), et son outil en ligne, dsomm.owasp.org, permet de cocher les activités déjà en place.
OWASP SAMM (Software Assurance Maturity Model), en version 2.2.0 publiée en juillet 2026, est plus large que le DSOMM : il couvre tout le cycle de vie du développement logiciel, organisé en cinq fonctions métier et quinze pratiques de sécurité. Il convient aux organisations qui veulent une vue 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. Sa seizième édition, BSIMM16, publiée en février 2026, s'appuie sur les pratiques observées dans 111 organisations. Il sert surtout aux grandes entreprises qui veulent se situer par rapport à leurs pairs, et l'évaluation passe généralement par un consultant.
DORA n'est pas un modèle de maturité sécurité, mais ses métriques de performance sont complémentaires. Le rapport annuel, intitulé « State of AI-assisted Software Development » depuis 2025, suit cinq métriques depuis l'édition 2024 : délai de mise en production, fréquence de déploiement, temps de rétablissement après un déploiement raté, taux d'échec des changements et taux de reprise (rework rate). Une organisation mature en sécurité qui ne déploie qu'une fois par mois a un problème : les deux approches se renforcent.
À retenir
Section intitulée « À retenir »- L'OWASP DSOMM 5.1.0 compte six dimensions, dont Agentic AI depuis août 2026, 24 sous-dimensions et 251 activités.
- Le DSOMM classe ses activités sur cinq niveaux, de « Basic understanding » à « Advanced deployment at scale ».
- La grille de la leçon note 0 à 4 des pratiques des cinq dimensions historiques, sur 168 points, avec quatre paliers propres à la page (Initial, Managed, Defined, Optimized).
- Le score global importe moins que les écarts entre dimensions : on compare des pourcentages, pas des points bruts.
- On priorise par ROI : quick wins (P0), fondations culturelles (P1), puis optimisation (P2) et excellence (P3).
- SOC 2 est un rapport d'attestation, pas une certification ; le Type II porte sur une période d'observation.
- DORA suit cinq métriques depuis 2024 ; Four Keys est archivé, Apache DevLake prend la collecte en charge.
- Audit complet tous les 6 mois, note rapide chaque trimestre, et la maturité technique ne tient pas sans engagement culturel.
Contrôle de connaissances
Section intitulée « Contrôle de connaissances »Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Continuer le cours : Maturité et feuille de route DevSecOps
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Les questions ci-dessous reprennent les doutes les plus courants sur l'audit de maturité : ce qu'est le DSOMM, sa différence avec SAMM, la durée de l'exercice et le score à viser.