Comprendre la séparation entre la sécurité CI/CD, le DevSecOps et la sécurité applicative
La sécurité logicielle moderne est souvent décrite au moyen de termes qui se recoupent, comme le DevSecOps, la sécurité CI/CD et la sécurité applicative.
Bien qu’étroitement liés, ces domaines répondent à des risques, des contrôles et des attentes d’audit différents — en particulier dans les environnements réglementés et les grandes entreprises.
Cette page clarifie pourquoi ces domaines sont séparés, ce que chacun couvre et comment ils fonctionnent ensemble sans ambiguïté.
Pourquoi les domaines de sécurité doivent être clairement séparés
Dans les environnements réglementés, la sécurité n’est pas évaluée comme un concept abstrait unique.
Les auditeurs, les régulateurs et les équipes des risques évaluent des systèmes, des responsabilités et des preuves précis.
Confondre les domaines de sécurité conduit à :
- Une responsabilité floue des contrôles
- Des preuves d’audit faibles
- Des écarts entre la politique et son application technique
- Un désalignement entre les équipes d’ingénierie et de conformité
Séparer les domaines de sécurité permet aux organisations de :
- Attribuer une responsabilité claire
- Appliquer des contrôles adaptés à chaque domaine
- Produire des preuves prêtes pour l’audit
- Faire monter la sécurité en charge sans créer de goulets d’étranglement
Sécurité CI/CD
Sécuriser le système de livraison logicielle
La sécurité CI/CD se concentre sur le pipeline lui-même en tant que système réglementé.
Ce que couvre la sécurité CI/CD
- Le contrôle des accès et la séparation des tâches dans les pipelines
- Les circuits d’approbation et les points de contrôle liés aux politiques
- L’intégrité des builds, la signature des artefacts et la traçabilité de leur provenance
- La protection des déploiements et l’isolation des environnements
- La génération et la conservation centralisées des preuves
Ce que la sécurité CI/CD n’est pas
- Elle n’analyse pas en profondeur la logique applicative
- Elle ne définit pas la culture d’équipe ni les processus organisationnels
- Elle ne remplace pas les contrôles de sécurité au niveau applicatif
Pourquoi la sécurité CI/CD est importante
Dans de nombreuses réglementations (DORA, NIS2, ISO 27001, SOC 2), le pipeline CI/CD est considéré comme un système TIC critique.
Les auditeurs attendent de lui qu’il :
- Applique les contrôles automatiquement
- Empêche les modifications non autorisées
- Génère des preuves inviolables
La sécurité CI/CD répond à la question :
« Peut-on faire confiance à ce système de livraison ? »
DevSecOps
La sécurité comme modèle opérationnel
Le DevSecOps n’est ni un système ni un ensemble d’outils.
C’est un modèle opérationnel qui intègre la sécurité dans les flux de travail de développement et d’exploitation.
Ce que couvre le DevSecOps
- L’automatisation de la sécurité intégrée aux flux de travail des développeurs
- La responsabilité partagée entre les équipes Dev, Sec et Ops
- Des boucles de rétroaction rapides sur les constats de sécurité
- L’amélioration continue par les métriques et l’apprentissage
Ce que le DevSecOps n’est pas
- Il ne remplace pas l’application des contrôles par le pipeline
- Il ne suffit pas à lui seul à assurer la conformité réglementaire
- Il ne garantit pas les preuves d’audit
Pourquoi le DevSecOps est important
Le DevSecOps permet à la sécurité de monter en charge sans ralentir la livraison.
Toutefois, dans les environnements réglementés, la culture seule n’est pas auditable.
Le DevSecOps répond à la question :
« Comment les équipes travaillent-elles en sécurité, au quotidien ? »
Sécurité applicative
Sécuriser le produit logiciel lui-même
La sécurité applicative se concentre sur l’application, et non sur le pipeline ou l’organisation.
Ce que couvre la sécurité applicative
- La conception sécurisée et la modélisation des menaces
- Les pratiques de codage sécurisé
- Le SAST, le DAST, l’IAST et la sécurité des dépendances
- Les protections à l’exécution (WAF, RASP)
- La remédiation des risques propres à l’application
Ce que la sécurité applicative n’est pas
- Elle ne contrôle pas qui peut déployer en production
- Elle n’impose pas les approbations ni la gouvernance des mises en production
- Elle ne gère pas à elle seule les preuves d’audit
Pourquoi la sécurité applicative est importante
Même un pipeline parfaitement gouverné peut déployer un logiciel vulnérable.
La sécurité applicative garantit que ce qui est construit est réellement sécurisé.
La sécurité applicative répond à la question :
« Cette application peut-elle être exécutée en toute sécurité ? »
Comment ces domaines fonctionnent ensemble
Ces domaines sont complémentaires, et non interchangeables.
| Domaine | Objet | Question principale |
|---|---|---|
| Sécurité CI/CD | Système de livraison | Peut-on faire confiance au pipeline ? |
| DevSecOps | Modèle opérationnel | Les équipes travaillent-elles en sécurité ? |
| Sécurité applicative | Produit logiciel | L’application est-elle sécurisée ? |
Dans les environnements réglementés :
- La sécurité CI/CD applique les contrôles et génère les preuves
- La sécurité applicative réduit le risque technique
- Le DevSecOps assure l’adoption et la pérennité
Pourquoi cette séparation est essentielle pour la conformité
Les auditeurs n’acceptent pas les affirmations de sécurité génériques.
Ils demandent :
- Où ce contrôle est-il appliqué ?
- Qui en est responsable ?
- Quelle preuve l’atteste ?
En séparant les domaines de sécurité :
- Les contrôles correspondent clairement aux réglementations
- Les preuves sont plus faciles à produire et à défendre
- Les équipes d’ingénierie et d’audit parlent le même langage
Correspondance des trois domaines avec les cadres réglementaires
Chaque domaine correspond à un ensemble d’obligations différent, ce qui explique pourquoi les régulateurs et les auditeurs les traitent séparément. Comprendre cette correspondance aide les équipes de conformité à adresser les demandes de preuves au bon responsable plutôt qu’à une fonction « sécurité » générique.
| Domaine | Obligations représentatives des cadres |
|---|---|
| Sécurité CI/CD | Gestion des changements TIC et résilience opérationnelle DORA ; NIS2 article 21(2)(e) ; ISO 27001 A.8.32 ; SOC 2 CC8.1 |
| DevSecOps | NIS2 article 21(2)(g) cyberhygiène et formation ; ISO 27001 A.6.3 ; environnement de contrôle SOC 2 CC1.x |
| Sécurité applicative | PCI DSS exigence 6 ; ISO 27001 A.8.25–A.8.28 ; NIS2 article 21(2)(e) développement sécurisé |
Là où les jonctions engendrent des constats d’audit
La plupart des défaillances de sécurité applicative observées lors des audits ne se situent pas à l’intérieur d’un seul domaine : elles apparaissent dans les jonctions entre domaines, là où chaque équipe suppose qu’une autre est responsable. Les schémas récurrents sont les suivants :
- Une vulnérabilité détectée par les tests de sécurité applicative que le pipeline ne bloque pas, si bien qu’elle atteint tout de même la production
- Une solide culture DevSecOps sans point de contrôle appliqué, qui fait reposer les contrôles sur la bonne volonté plutôt que sur le système de livraison
- Des contrôles de pipeline qui supposent qu’une analyse applicative a lieu, sans vérifier que ses résultats donnent réellement suite à des actions
- Des différends de responsabilité où chaque domaine suppose qu’un autre répond d’un contrôle, qui se retrouve de fait sans propriétaire
- Des preuves propres à un domaine qui ne peuvent être corrélées avec les autres lors d’un même passage en revue d’audit
Les preuves demandées par les auditeurs pour chaque domaine
Parce que les domaines répondent à des questions différentes, ils produisent aussi des preuves différentes. Un évaluateur qui prépare ses travaux demandera généralement des éléments issus des trois :
- Sécurité CI/CD — la configuration du pipeline montrant des points de contrôle obligatoires et non contournables ; les journaux d’approbation démontrant la séparation des tâches ; les signatures d’artefacts et les paramètres de conservation des preuves
- DevSecOps — les relevés de formations suivies ; la preuve que les constats de sécurité sont triés dans des délais définis ; des métriques montrant que les contrôles sont utilisés plutôt que systématiquement contournés
- Sécurité applicative — les modèles de menaces des applications critiques ; les résultats SAST, DAST et SCA avec leur statut de remédiation ; les enregistrements de gouvernance pour les vulnérabilités acceptées ou écartées
Attribuer la responsabilité entre les domaines
Une séparation claire ne fonctionne que lorsque chaque domaine a un responsable désigné. Dans la plupart des organisations réglementées, la fonction plateforme ou DevOps détient les contrôles de sécurité CI/CD, l’ingénierie de sécurité et les référents sécurité pilotent l’adoption du DevSecOps, et les équipes produit et développement détiennent la sécurité applicative. La structure précise importe moins que le principe : chaque contrôle doit avoir un propriétaire unique et nommé.
Pour tout contrôle donné, les auditeurs demandent régulièrement : qui en est le propriétaire ? Une réponse assurée et sans ambiguïté — étayée par une matrice RACI ou une cartographie des responsabilités équivalente — est en soi un signe de maturité. Une réponse hésitante ou partagée est souvent le point de départ d’un constat.
Une vérification rapide avant un audit
Un court exercice peut révéler si les trois domaines sont réellement séparés dans la pratique ou seulement sur le papier. Pour une mise en production récente, essayez de répondre à chacune des questions suivantes sans demander à un collègue de la reconstituer :
- Quels points de contrôle du pipeline a-t-elle franchis, et l’un d’eux aurait-il pu être contourné ?
- Quels tests de sécurité applicative ont été exécutés contre elle, et qu’a-t-on fait de leurs résultats ?
- Qui a approuvé la mise en production, et cette personne était-elle indépendante de l’auteur de la modification ?
- Pour tout contrôle concerné, pouvez-vous nommer un propriétaire responsable unique ?
Si l’une des réponses est floue, l’écart se situe presque toujours à la frontière entre deux domaines — et c’est exactement là qu’un auditeur regardera en premier. Réaliser cette vérification sur une poignée de mises en production représentatives, bien avant le début d’une évaluation, transforme des définitions de domaines abstraites en preuves concrètes et fait apparaître les lacunes de responsabilité alors qu’il est encore temps de les combler.
Conclusion
La maturité en sécurité dans les grandes entreprises vient de la clarté, et non de la consolidation.
La sécurité CI/CD, le DevSecOps et la sécurité applicative résolvent chacun des problèmes différents :
- La confiance dans la livraison
- Des façons de travailler sécurisées
- Des produits logiciels sécurisés
Comprendre et maintenir cette séparation est essentiel pour bâtir des systèmes logiciels évolutifs, auditables et réglementés.
