DevSecOps : définition, outils et sécurité dans la CI/CD
La démarche qui intègre la sécurité à chaque étape du cycle de vie logiciel au lieu de la reléguer en fin de projet : shift left, analyses automatisées, secrets, SBOM et exemple de pipeline.
Par Équipe Blent· Mis à jour le · 14 min de lecture· Niveau intermédiaire
DevSecOps en bref
- Principe directeur
- Shift left : sécuriser au plus tôt
- Contrôles typiques
- SAST, DAST, SCA, scan d'images, secrets
- Livrable clé
- SBOM (formats SPDX ou CycloneDX)
- Référentiels
- OWASP, SLSA, NIST SSDF
- Outils emblématiques
- Trivy, Semgrep, Vault, Open Policy Agent
- Responsabilité
- Partagée entre Dev, Ops et sécurité
Définition : DevSecOps
Le DevSecOps est une démarche qui intègre la sécurité à chaque étape du cycle de vie d'un logiciel, de la conception à l'exploitation, au lieu d'en faire un contrôle final réalisé juste avant la mise en production. Il prolonge le DevOps en rendant développeurs, opérationnels et équipes de sécurité conjointement responsables de la protection des applications. En pratique, il se traduit par des contrôles automatisés dans les pipelines CI/CD : analyse statique du code, audit des dépendances, scan des images de conteneurs, détection de secrets, politiques de sécurité exprimées en code et surveillance en production.
En une phrase : le DevSecOps fait de la sécurité une étape automatisée de chaque pipeline, et non un audit de dernière minute.
Dans cette définition
Qu'est-ce que le DevSecOps ?
Le DevSecOps est l'application des principes du DevOps à la sécurité : collaboration, automatisation et boucles de retour courtes, cette fois au service de la protection des applications et de l'infrastructure.
Dans un cycle de développement traditionnel, la sécurité intervient à la fin : une équipe spécialisée audite l'application quelques jours avant sa mise en production, dresse une liste de failles et bloque la livraison. Ce modèle fonctionnait avec deux versions par an. Il devient intenable quand une équipe déploie plusieurs fois par jour : soit l'audit freine la livraison, soit il est contourné. Le DevSecOps résout ce dilemme en transformant la sécurité en une série de contrôles automatisés, exécutés à chaque modification dans la chaîne CI/CD.
Le terme s'est diffusé au milieu des années 2010, à mesure que les organisations adoptaient le DevOps et que les attaques visant la chaîne d'approvisionnement logicielle se multipliaient. La compromission de dépendances open source populaires et d'outils de build a montré qu'une application est aussi vulnérable que le plus fragile de ses composants. Des référentiels comme le NIST SSDF ou le framework SLSA formalisent aujourd'hui ces bonnes pratiques.
Le DevSecOps ne remplace pas les experts en sécurité. Il change leur rôle : moins d'audits manuels en bout de chaîne, davantage de règles, d'outils et d'accompagnement pour que les équipes produit détectent et corrigent elles-mêmes la majorité des problèmes.
À retenir : le DevSecOps ne rajoute pas une étape de sécurité au pipeline, il en ajoute une à chaque étape, et partage la responsabilité entre tous ceux qui construisent et exploitent le logiciel.
SAST, DAST, SCA, SBOM : les briques techniques
Le vocabulaire du DevSecOps est dense. Chaque sigle correspond à un type de contrôle, à un moment précis du cycle.
| Contrôle | Ce qui est analysé | Moment | Exemples d'outils |
|---|---|---|---|
| SAST (analyse statique) | Le code source, sans l'exécuter | Commit, merge request | Semgrep, SonarQube, CodeQL |
| SCA (analyse de composition) | Les dépendances et leurs vulnérabilités connues | Build | Trivy, Dependabot, OWASP Dependency-Check |
| Scan d'images | Le système de base et les paquets d'une image de conteneur | Build, registre | Trivy, Grype, Harbor |
| Scan d'IaC | Les fichiers Terraform, Kubernetes ou Helm | Merge request | Checkov, Trivy |
| Détection de secrets | Les clés et mots de passe dans le code et l'historique Git | Pré-commit, CI | Gitleaks, TruffleHog |
| DAST (analyse dynamique) | L'application en fonctionnement, via ses points d'entrée | Environnement de test | ZAP |
| SBOM | L'inventaire des composants livrés | Build, livraison | Trivy, Syft |
La SBOM mérite une attention particulière. Générée à chaque build et conservée avec l'artefact, elle permet de répondre immédiatement à la question qui suit chaque vulnérabilité médiatisée : « sommes-nous concernés, et où ? ». Les exigences réglementaires et contractuelles sur ce point se renforcent, en Europe comme aux États-Unis.
Exemple concret : scanner une image avec Trivy dans un pipeline
Voici un job GitLab CI/CD qui analyse l'image construite à l'étape précédente. Il échoue si une vulnérabilité critique ou élevée disposant d'un correctif est détectée, et produit dans tous les cas une SBOM au format CycloneDX.
container_scanning:
stage: test
image:
name: aquasec/trivy:latest
entrypoint: [""]
variables:
IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
TRIVY_USERNAME: "$CI_REGISTRY_USER"
TRIVY_PASSWORD: "$CI_REGISTRY_PASSWORD"
script:
# Inventaire des composants, conservé avec l'artefact
- trivy image --format cyclonedx --output sbom.cdx.json "$IMAGE"
# Échec du job si une faille critique ou élevée corrigeable est présente
- trivy image --exit-code 1 --severity HIGH,CRITICAL --ignore-unfixed "$IMAGE"
artifacts:
when: always
paths:
- sbom.cdx.json
Trois choix méritent d'être expliqués. L'option --ignore-unfixed évite de bloquer l'équipe sur des failles qu'elle ne peut pas encore corriger. Le seuil HIGH,CRITICAL limite le bruit tout en arrêtant les risques sérieux. Enfin, la SBOM est archivée même en cas d'échec, pour garder la trace de ce qui a été analysé. Une commande trivy fs --scanners vuln,secret,misconfig . exécutée plus tôt dans le pipeline couvre en outre les dépendances, les secrets et les fichiers d'infrastructure du dépôt.
Dans quels cas le DevSecOps s'impose-t-il ?
Toute équipe qui déploie souvent a intérêt à automatiser sa sécurité, mais certains contextes en font une nécessité.
Secteurs régulés
Banque, santé, assurance ou secteur public, où chaque mise en production doit être traçable.
Applications exposées sur Internet
Sites, API et applications mobiles soumis en permanence à des tentatives d'attaque.
Chaîne d'approvisionnement logicielle
Maîtriser les centaines de dépendances open source embarquées dans chaque application.
Plateformes de conteneurs
Contrôler les images déployées et les configurations d'un cluster Kubernetes partagé.
Infrastructure Cloud en code
Détecter un stockage public ou un port ouvert avant que l'infrastructure ne soit créée.
Éditeurs de logiciels
Fournir à leurs clients une SBOM et des preuves de sécurité sur ce qu'ils livrent.
Quels sont les avantages du DevSecOps ?
En déplaçant la sécurité vers l'amont, le DevSecOps la rend à la fois moins coûteuse et compatible avec un rythme de livraison élevé.
- Failles détectées tôt, quand leur correction coûte quelques minutes et non une semaine de refonte.
- Sécurité compatible avec des déploiements fréquents, sans audit manuel bloquant à chaque version.
- Visibilité complète sur les dépendances et les composants embarqués grâce aux SBOM.
- Règles de sécurité versionnées, appliquées de façon identique à toutes les équipes.
- Traçabilité facilitée pour les audits et les exigences réglementaires.
- Culture de la sécurité diffusée chez les développeurs plutôt que concentrée dans une équipe.
Quelles sont les limites du DevSecOps ?
Mal calibrés, les contrôles automatisés deviennent du bruit, et le bruit finit toujours par être ignoré.
- Faux positifs nombreux si les outils ne sont pas réglés, au risque de lasser les équipes.
- Allongement des pipelines lorsque toutes les analyses s'exécutent à chaque commit.
- Gestion des vulnérabilités sans correctif disponible, qui exige des exceptions documentées.
- Compétences de sécurité encore rares chez les développeurs et les opérationnels.
- Les outils ne détectent pas les failles de logique métier ni les erreurs de conception.
- Prolifération d'outils et de tableaux de bord difficiles à consolider.
DevOps vs DevSecOps : quelles différences ?
Le DevSecOps n'est pas une alternative au DevOps, mais son extension naturelle. Les différences portent sur le périmètre et les responsabilités.
| Critère | DevOps | DevSecOps |
|---|---|---|
| Objectif | Livrer vite et de manière fiable | Livrer vite, de manière fiable et sûre |
| Place de la sécurité | Souvent un contrôle externe en fin de cycle | Un contrôle automatisé à chaque étape |
| Acteurs | Développement et exploitation | Développement, exploitation et sécurité |
| Contenu du pipeline | Build, tests, déploiement | Idem, plus SAST, SCA, scans, signature et politiques |
| Livrables | Artefact déployable | Artefact signé, accompagné de sa SBOM |
| Indicateurs | Métriques DORA | Métriques DORA, délai de correction des vulnérabilités |
Secrets et policy as code : sécuriser au-delà du code
Deux pratiques complètent les analyses automatisées.
La gestion des secrets. Un mot de passe commité dans Git reste dans l'historique, même après suppression. Les secrets doivent donc vivre dans un coffre-fort comme HashiCorp Vault, qui les chiffre, trace chaque accès et peut générer des identifiants temporaires à la demande. Les applications les récupèrent au démarrage, et les pipelines s'authentifient de préférence par fédération d'identité plutôt qu'avec des clés longue durée.
Le policy as code. Les règles de sécurité de l'organisation (aucune image exécutée en root, aucun stockage public, uniquement des images issues du registre interne) sont écrites dans des fichiers versionnés et évaluées automatiquement. Sur Kubernetes, un contrôleur d'admission comme Kyverno ou OPA Gatekeeper refuse tout déploiement qui les enfreint. La même logique s'applique aux plans Terraform avant leur exécution.
En production, la sécurité continue : un outil comme Falco détecte les comportements anormaux d'un conteneur, par exemple l'ouverture d'un shell ou l'écriture dans un répertoire système.
Faut-il passer au DevSecOps ?
La plupart des équipes ont intérêt à démarrer petit : quelques contrôles bien réglés valent mieux qu'une batterie d'outils ignorés.
Le DevSecOps est prioritaire
- Vous déployez plusieurs fois par semaine et l'audit manuel ne suit plus.
- Vos applications manipulent des données personnelles ou sensibles.
- Vos clients ou régulateurs exigent des preuves de sécurité.
- Vos images et dépendances ne sont aujourd'hui jamais analysées.
D'autres chantiers passent avant
- Vous n'avez pas encore de pipeline CI/CD : commencez par là.
- Le projet est un prototype jetable, sans données réelles.
- Personne n'est en mesure de traiter les alertes produites.
- Les bases (correctifs, comptes, sauvegardes) ne sont pas maîtrisées.
Quels outils pour une démarche DevSecOps ?
Chaque famille de contrôle a ses outils de référence, souvent open source et faciles à intégrer à un pipeline.
- Scan d'images et SCA
Trivy
Scanner open source d'Aqua Security : images, dépendances, IaC, secrets et génération de SBOM.
- SAST
Semgrep
Analyse statique rapide, à base de règles lisibles et personnalisables.
- Qualité et SAST
SonarQube
Plateforme d'analyse de la qualité et de la sécurité du code, intégrée aux merge requests.
- DAST
ZAP
Scanner dynamique open source issu de l'OWASP, qui attaque l'application en fonctionnement.
- Gestion des secrets
HashiCorp Vault
Coffre-fort centralisé pour stocker, distribuer et faire tourner les secrets.
- Policy as code
Open Policy Agent
Moteur de politiques de la CNCF, écrites en langage Rego et évaluées partout.
- Policy as code
Kyverno
Contrôleur d'admission Kubernetes dont les politiques s'écrivent en YAML.
- Détection runtime
Falco
Détection des comportements suspects des conteneurs en cours d'exécution.
- Registre
Harbor
Registre d'images open source avec scan de vulnérabilités et signature intégrés.
Les concepts à connaître autour du DevSecOps
Le DevSecOps se situe au croisement de la culture DevOps, de l'automatisation et de la sécurité applicative.
- DevOpsLa culture de collaboration et d'automatisation que le DevSecOps étend à la sécurité.
- CI/CDLa chaîne d'automatisation dans laquelle s'insèrent les contrôles de sécurité.
- ContainerL'image à analyser, avec son système de base et ses dépendances.
- SBOML'inventaire des composants logiciels embarqués dans un artefact.
- Policy as codeDes règles de sécurité écrites, versionnées et testées comme du code.
- IAMLa gestion des identités et des droits d'accès, humains comme machines.
Ressources pour approfondir le DevSecOps
Trois articles du blog Blent pour outiller la sécurité d'une chaîne DevOps.
- Outil
HashiCorp Vault : gérer les secrets
Centraliser, chiffrer et faire tourner les secrets des applications et des pipelines.
Lire l'article - Outil
Falco : détection d'intrusions runtime
Surveiller le comportement des conteneurs en production et alerter en temps réel.
Lire l'article - Outil
Harbor : registre Docker Cloud-native
Héberger ses images avec scan de vulnérabilités, signature et contrôle d'accès.
Lire l'article
Questions fréquentes
Questions fréquentes
Expertise
À propos de l'auteur
Équipe Blent
Les ingénieurs et mentors Blent conçoivent, automatisent et mettent en production des infrastructures Cloud, et forment chaque année des centaines de professionnels au Cloud et au DevOps.
Sources et méthodologie
- OWASP, Top 10 et DevSecOps Guideline
- NIST SP 800-218, Secure Software Development Framework (SSDF)
- Documentation Trivy, Open Policy Agent et Kyverno
- Retours d'expérience des projets et formations Blent
Comment intégrer la sécurité à chaque étape du cycle ?
Le DevSecOps reprend la boucle DevOps et associe à chaque étape un ou plusieurs contrôles, automatisés autant que possible. L'idée : détecter chaque problème à l'endroit où il coûte le moins cher à corriger.
Concevoir
L'équipe identifie les menaces dès la conception (threat modeling), définit les exigences de sécurité et classe les données manipulées selon leur sensibilité.
Coder
Des extensions d'IDE et des hooks de pré-commit signalent les failles courantes et bloquent l'ajout d'un mot de passe ou d'une clé d'API dans le code.
Construire
Le pipeline lance l'analyse statique du code (SAST), l'audit des dépendances (SCA), le scan de l'image de conteneur et génère la nomenclature logicielle (SBOM).
Tester
L'application déployée en environnement de test subit des analyses dynamiques (DAST) qui simulent des attaques sur ses points d'entrée HTTP.
Livrer
L'artefact validé est signé, et des politiques automatisées vérifient qu'il respecte les règles de l'organisation avant toute mise en production.
Déployer et exploiter
Un contrôleur d'admission refuse les déploiements non conformes, les secrets sont injectés à l'exécution et des outils de détection surveillent les comportements anormaux.
Surveiller et corriger
Les nouvelles vulnérabilités publiées sont confrontées en continu aux SBOM des applications en production, et les correctifs repartent dans la boucle.