Qu’est-ce que DevSecOps ?
DevSecOps consiste à intégrer les contrôles de sécurité directement dans la chaîne de développement et de livraison du logiciel, plutôt qu’à les reporter à un audit de fin de projet. Le nom condense développement (Dev), sécurité (Sec) et opérations (Ops).
Concrètement, chaque commit et chaque image de conteneur passent par des tests de sécurité automatisés, et le développeur voit le résultat en quelques minutes au lieu de le découvrir plusieurs semaines plus tard.
L’intérêt est double : une faille repérée pendant l’écriture du code coûte moins cher à corriger qu’une faille trouvée en production, et les traces laissées par le pipeline servent de preuve lors des audits de conformité.
DevSecOps n’est pas un produit qu’on achète. C’est une façon d’organiser le travail, outillée par une chaîne d’automatisation.
DevSecOps ou DevOps : quelle différence ?
DevOps rapproche les développeurs et les équipes d’exploitation pour raccourcir le délai entre l’écriture du code et sa mise en production. La sécurité n’en fait pas partie par construction.
DevSecOps ajoute cette dimension : les équipes sécurité entrent dans la boucle dès la conception, et leurs contrôles deviennent des étapes automatisées du pipeline au lieu d’une validation manuelle avant la mise en ligne.
Le terme « shift left » décrit ce déplacement des tests vers l’amont du cycle. Le « shift right » désigne le mouvement complémentaire : surveiller le comportement de l’application une fois qu’elle tourne en production.
À ne pas confondre avec le SecOps, qui porte sur l’exploitation de la sécurité au quotidien (supervision, détection, réponse à incident) et non sur la fabrication du logiciel.
Comment fonctionne DevSecOps ?
Les contrôles de sécurité s’insèrent dans le pipeline CI/CD sous forme d’étapes déclenchées à chaque modification du code. Une étape qui remonte une vulnérabilité critique peut bloquer la fusion de la branche.
Les familles de tests les plus courantes :
- SAST, l’analyse statique : lecture du code source à la recherche de motifs dangereux, avec des outils comme SonarQube, Semgrep ou Checkmarx.
- SCA, l’analyse de composition : inventaire des dépendances open source et de leurs vulnérabilités connues, via Snyk, Dependabot ou Trivy.
- DAST, l’analyse dynamique : l’application en fonctionnement est attaquée depuis l’extérieur, souvent avec OWASP ZAP ou Burp Suite.
- Le scan des images de conteneurs et des fichiers d’infrastructure Terraform ou Kubernetes, avec Trivy, Checkov ou tfsec.
- La détection de secrets : clés d’API et mots de passe commités par erreur, repérés par gitleaks ou TruffleHog.
S’y ajoutent la gestion des secrets à l’exécution (HashiCorp Vault, AWS Secrets Manager), la signature des artefacts livrés et la production d’un SBOM, l’inventaire des composants embarqués dans une version.
Le point difficile n’est pas de brancher ces outils, mais de régler leur bruit. Un pipeline qui remonte quatre cents alertes par build finit ignoré. Le tri des faux positifs et la définition de seuils réellement bloquants occupent une bonne part du travail.
Exemples ou cas d’usage concrets
Un éditeur SaaS déclenche une analyse statique et un scan de dépendances sur chaque pull request. Une vulnérabilité critique dans une bibliothèque bloque la fusion tant qu’aucune version corrigée n’est disponible.
Une banque doit démontrer à son régulateur que chaque mise en production a été contrôlée. Les rapports générés par le pipeline tiennent lieu de preuve d’audit, ce qui évite de reconstituer les dossiers a posteriori.
Une équipe plateforme publie des modules Terraform déjà conformes, avec chiffrement activé et ports d’administration fermés. Les équipes produit les réutilisent sans connaître le détail des règles internes.
Après la publication de la faille Log4Shell en décembre 2021, les organisations qui disposaient d’un inventaire de dépendances à jour ont identifié en quelques heures les applications touchées. Les autres ont cherché pendant des semaines.
Quels profils recrute-t-on en DevSecOps ?
L’intitulé « ingénieur DevSecOps » recouvre des réalités assez différentes selon l’entreprise. Les configurations qui reviennent le plus souvent :
- Ingénieur DevSecOps : construit et maintient le pipeline sécurisé, choisit les outils, calibre les seuils. Il s’agit plus souvent d’un profil DevOps monté en compétence sur la sécurité applicative que d’un expert sécurité venu à l’automatisation.
- Application security engineer : accompagne les développeurs, fait de la revue de code, de la modélisation de menaces, et pilote le suivi des correctifs.
- Platform engineer : fournit des socles Kubernetes et des chaînes de déploiement où les règles de sécurité s’appliquent par défaut.
Les compétences demandées se recoupent largement : une chaîne CI/CD (GitLab CI, GitHub Actions, Jenkins), les conteneurs et Kubernetes, l’infrastructure as code, un langage de script comme Python ou Go, et une connaissance concrète des vulnérabilités décrites dans l’OWASP Top 10.
Ces postes restent difficiles à pourvoir parce qu’ils demandent deux cultures rarement réunies chez la même personne, celle de l’automatisation et celle de la sécurité offensive. Beaucoup d’entreprises recrutent un profil solide sur l’une des deux et financent la montée en compétence sur l’autre.