Qu'est-ce que le DevSecOps ?

Le DevSecOps est un modèle opérationnel où la sécurité est intégrée en continu — et automatisée — à chaque étape du cycle de développement logiciel, de la conception à la production.

La différence clé avec les approches historiques : la sécurité n'est plus un gate bloquant en fin de cycle (audit, pentest, validation RSSI avant mise en prod). Elle devient une propriété continue du produit, mesurée en temps réel, partagée entre les équipes Dev, Ops et Sec.

L'acronyme lui-même porte le message : « Sec » au milieu de « Dev » et « Ops ». Ce n'est pas un troisième silo. C'est une responsabilité qui se diffuse dans les deux autres.

Les trois termes sont utilisés de manière interchangeable dans beaucoup d'organisations. C'est une erreur : ils décrivent des modèles opérationnels distincts, avec des objectifs différents.

DevOps — vélocité et fiabilité

DevOps vise à fluidifier la chaîne entre développement et production. Les métriques de référence : fréquence de déploiement, lead time for changes, MTTR, change failure rate (les 4 DORA metrics).

DevSecOps — sécurité continue intégrée

DevSecOps étend DevOps en y intégrant les pratiques de sécurité : scan automatique du code (SAST), des dépendances (SCA), de l'infrastructure-as-code, des secrets, des images conteneurs. L'objectif : que la sécurité n'ajoute pas de friction au flux dev/ops.

SecOps — réponse opérationnelle aux menaces

SecOps, c'est le SOC : détection d'incidents, réponse, threat hunting. C'est une posture runtime sur des systèmes en production, pas une intégration au pipeline de développement.

Une démarche DevSecOps mature repose sur trois principes non négociables. L'absence de l'un des trois disqualifie le modèle.

1. 1Shift-left : la sécurité est intégrée le plus tôt possible dans le cycle — à la conception, dans l'IDE, dans la pull request — pas en fin de chaîne.
2. 2Automatisation : les contrôles de sécurité sont exécutés automatiquement par la CI/CD, sans intervention manuelle systématique. Ce qui ne peut pas être automatisé est clairement identifié et priorisé.
3. 3Responsabilité partagée : la sécurité n'est plus le problème exclusif du RSSI. Les développeurs, les ops, les architectes et le produit ont chacun une part de responsabilité claire et mesurable.

Au-delà des principes, un programme DevSecOps mature s'articule autour de 5 piliers opérationnels. C'est exactement le modèle que Cyber Coach instrumente bout en bout.

1. 1Connecter — ingérer les données depuis les outils de sécurité existants (SAST, SCA, DAST, IaC, secrets, cloud, container). Normaliser les formats, dédupliquer les doublons cross-outils.
2. 2Prioriser — scorer les vulnérabilités dans leur contexte réel (exploitabilité, exposition, criticité métier), pas seulement par CVSS brut. Distinguer le signal du bruit.
3. 3Actionner — transformer une vulnérabilité priorisée en ticket contextualisé dans l'outil utilisé par l'équipe (Jira, Linear, ServiceNow, GitHub/GitLab Issues), avec synchronisation bidirectionnelle.
4. 4Mesurer la maturité — quantifier objectivement où en est chaque équipe sur les dimensions SAMM / DSOMM, à partir de données réelles plutôt que de questionnaires déclaratifs.
5. 5Remédier — accélérer la fermeture du ticket avec du contexte enrichi, des recommandations de fix, et, quand c'est pertinent, un agent IA qui ouvre une merge request que l'humain review et merge.

Côté outillage, un programme DevSecOps moderne s'appuie sur plusieurs familles d'outils, chacune couvrant un angle d'attaque différent.

• SAST (Static Application Security Testing) — analyse du code source à la recherche de vulnérabilités applicatives.
• SCA (Software Composition Analysis) — analyse des dépendances open-source et de leurs CVEs connues.
• DAST (Dynamic Application Security Testing) — tests d'attaque automatisés contre l'application en cours d'exécution.
• IaC scanning — analyse des fichiers Terraform, CloudFormation, Kubernetes pour détecter les mauvaises configurations.
• Secrets scanning — détection de clés API, mots de passe et tokens accidentellement commités.
• Container & image scanning — analyse des images Docker pour détecter les CVEs dans les couches de base.
• ASPM (Application Security Posture Management) — couche de consolidation, priorisation et pilotage au-dessus de tous les outils ci-dessus.

Deux frameworks font référence pour mesurer la maturité d'un programme DevSecOps : OWASP SAMM et DSOMM. Tous deux définissent des niveaux progressifs, de l'ad-hoc à l'optimisé.

1. 1Niveau 0 — Ad-hoc : aucune pratique formalisée. La sécurité est traitée au cas par cas, en fonction des audits et des incidents.
2. 2Niveau 1 — Initial : des contrôles automatiques existent sur certains projets pilotes. Les résultats ne sont pas consolidés.
3. 3Niveau 2 — Défini : les pratiques sont documentées et appliquées sur l'ensemble du périmètre. Les métriques existent mais sont collectées manuellement.
4. 4Niveau 3 — Mesuré : les métriques sont collectées automatiquement, suivies en temps réel, utilisées pour piloter les décisions.
5. 5Niveau 4 — Optimisé : l'organisation utilise ses métriques pour améliorer en continu ses pratiques et son outillage, et benchmarker ses équipes.

D'après OWASP, moins de 15% des programmes DevSecOps dépassent le niveau 2. La majorité des organisations croient être au niveau 3 parce qu'elles ont des dashboards — mais ces dashboards sont alimentés par des questionnaires déclaratifs, pas par de la donnée réelle.

La plupart des guides recommandent « commencer par définir une politique de sécurité ». En pratique, ce conseil est inutile pour une ETI qui a déjà 10 outils en place et aucune visibilité dessus.

Notre recommandation pragmatique : commencez par faire un état des lieux mesuré, pas déclaratif. Connectez vos outils existants à une plateforme de consolidation, obtenez un score de maturité objectif par équipe, identifiez les 3 écarts les plus critiques, et corrigez-les en priorité.

1. 1Faire l'inventaire des outils déjà en place (vous en avez probablement plus que vous ne pensez).
2. 2Consolider leurs résultats dans une vue unique.
3. 3Obtenir un score de maturité DSOMM / SAMM automatisé, par équipe.
4. 4Identifier les 3 écarts les plus critiques (souvent : priorisation, sync ticketing, mesure du MTTR).
5. 5Corriger ces 3 écarts avant de penser à acheter de nouveaux outils.