DevSecOps : sécurité, change management et conformité

L'une des objections les plus tenaces opposées à l'adoption du DevOps tient en une phrase : « La sécurité et la conformité ne nous laisseront jamais faire. » Or les auteurs renversent l'argument : le DevOps est peut-être le meilleur moyen d'intégrer enfin la sécurité de l'information dans le travail quotidien de toute la chaîne de valeur technologique. Ce chapitre, qui ouvre la sixième partie du livre, montre comment étendre le flux, le feedback et l'apprentissage aux objectifs de sécurité de l'information (information security) — d'abord en faisant de la sécurité l'affaire de tous, chaque jour ; ensuite en protégeant le pipeline de déploiement et en le réconciliant avec le change management et la conformité.

Pourquoi la sécurité doit changer de modèle

Quand l'équipe sécurité (Infosec) est organisée en silo, à l'écart du développement et de l'exploitation, les ennuis s'accumulent. James Wickett, créateur de l'outil de sécurité Gauntlt et organisateur du DevOpsDays Austin, résume la cause profonde : le ratio des effectifs entre développement, exploitation et sécurité dans une organisation technologique typique est de 100:10:1. Quand l'Infosec est à ce point surclassée en nombre, sans automatisation ni intégration dans le travail quotidien de Dev et Ops, elle ne peut plus faire que de la vérification de conformité (compliance checking) — soit l'exact opposé de l'ingénierie de sécurité, « et en plus ça fait que tout le monde nous déteste ».

Wickett et Josh Corman, ancien CTO de Sonatype et chercheur respecté en sécurité, ont théorisé l'intégration des objectifs de sécurité dans le DevOps sous le nom de Rugged DevOps. Des idées voisines ont été développées par le Dr Tapabrata Pal et l'équipe de Capital One, qui parlent de DevOpsSec : la sécurité intégrée à toutes les étapes du cycle de vie du logiciel (SDLC). Tout au long du livre, les auteurs ont montré comment intégrer pleinement les objectifs de la QA et de l'exploitation dans la chaîne de valeur ; il s'agit ici de faire de même pour la sécurité, afin d'accroître simultanément la productivité, la sûreté et la sécurité.

Intégrer la sécurité dans le travail quotidien

L'objectif premier est de mobiliser les équipes de fonctionnalités avec l'Infosec le plus tôt possible, plutôt qu'en toute fin de projet. Plusieurs leviers concrets y concourent.

Dans les démos d'itération

Inviter l'Infosec aux démonstrations produit de fin d'itération lui permet de comprendre les objectifs de l'équipe dans leur contexte, d'observer les implémentations à mesure qu'elles se construisent, et de donner conseils et feedback au moment où il reste le plus de temps et de liberté pour corriger. Justin Arbuckle, ancien architecte en chef de GE Capital, le confirme : « En matière de sécurité et de conformité, nous avons découvert que les blocages en fin de projet coûtaient bien plus cher qu'au début — et les blocages Infosec étaient parmi les pires. La conformité par démonstration (compliance by demonstration) est devenue l'un des rituels qui nous ont permis de déplacer toute cette complexité plus tôt dans le processus. » En associant l'Infosec dès la création de chaque nouvelle capacité, GE Capital a pu réduire drastiquement l'usage des checklists statiques au profit de l'expertise mobilisée tout au long du développement.

Snehal Antani, ancien CIO de l'architecture d'entreprise chez GE Capital Americas, mesurait ce progrès par trois indicateurs métier : la vélocité de développement (vitesse de mise sur le marché), les interactions client échouées (pannes, erreurs) et le temps de réponse à la conformité (le délai entre une demande d'audit et la livraison de toutes les informations requises).

Dans le suivi des défauts et les post-mortems

On veut suivre tous les problèmes de sécurité ouverts dans le même système de suivi du travail que Dev et Ops, afin qu'ils soient visibles et priorisables au même titre que le reste. C'est l'inverse de la tradition Infosec, qui rangeait toutes les vulnérabilités dans un outil de gouvernance, risque et conformité (GRC) accessible à la seule Infosec. Nick Galbreath, longtemps responsable de la sécurité chez Etsy, raconte : « Nous mettions tous les problèmes de sécurité dans JIRA, que tous les ingénieurs utilisent au quotidien, et ils étaient soit P1 soit P2 — à corriger immédiatement ou avant la fin de la semaine, même pour une application interne. » Et chaque incident de sécurité donnait lieu à un post-mortem, formidable mécanisme pour mieux former les ingénieurs et leur transférer la connaissance sécurité.

Dans les dépôts de code et les services partagés

On enrichit le dépôt de code partagé de tout ce qui aide à sécuriser applications et environnements : bibliothèques pré-validées par la sécurité (authentification, chiffrement), configurations recommandées, images de base durcies. Parce que tout le monde dans la chaîne DevOps utilise la gestion de version (version control), y placer les artefacts de sécurité les rend disponibles, recherchables et réutilisables — et fait de la gestion de version un canal de communication omnidirectionnel sur les changements. Quand un ingénieur emploie l'une de ces bibliothèques pré-validées, il n'a plus besoin de planifier une revue de conception sécurité séparée : il bénéficie déjà des choix faits sur le durcissement de configuration, les paramètres de base de données, les longueurs de clé, etc.

Catégorie	Exemples fournis dans le dépôt partagé
Bibliothèques de code et configurations	Authentification à deux facteurs (2FA), hachage de mot de passe bcrypt, journalisation
Gestion des secrets	Paramètres de connexion, clés de chiffrement via Vault, sneaker, Keywhiz, credstash, Trousseau, Red October
Paquets et images d'OS	NTP pour la synchronisation horaire, versions sûres d'OpenSSL, OSSEC ou Tripwire pour l'intégrité des fichiers, syslog vers une pile ELK centralisée

Intégrer la sécurité dans le pipeline de déploiement

Autrefois, la revue de sécurité commençait une fois le développement terminé, et produisait des centaines de pages de vulnérabilités dans un PDF — remis à Dev et Ops, puis ignorées sous la pression des délais ou parce que les problèmes étaient découverts trop tard pour être corrigés simplement. Le DevOps inverse ce schéma : on automatise le maximum de tests de sécurité pour qu'ils tournent aux côtés des autres tests automatisés, idéalement à chaque commit, et dès les premières étapes du projet. L'enjeu est de donner à Dev et Ops un feedback rapide dès qu'ils introduisent un changement potentiellement non sûr.

L'outil Gauntlt a justement été conçu pour s'intégrer au pipeline. Fait notable, il exprime ses tests de sécurité en syntaxe Gherkin, déjà familière aux développeurs pour les tests unitaires et fonctionnels — ce qui place la sécurité dans un cadre qu'ils maîtrisent et la rend exécutable à chaque changement.

Assurer la sécurité de l'application

Le test de développement vise souvent la justesse des fonctionnalités, en suivant les chemins heureux (happy paths). La QA, l'Infosec et les spécialistes de la fraude, eux, se concentrent sur les chemins tristes (sad paths) — ce qui arrive quand les choses tournent mal, surtout dans les conditions d'erreur liées à la sécurité (parfois appelées par dérision les bad paths). Plutôt que de les tester manuellement, on les génère comme tests unitaires ou fonctionnels automatisés exécutés en continu dans le pipeline.

Type de test	Principe	Outils cités
Analyse statique (SAST)	Inspecter le code hors exécution pour traquer failles, portes dérobées et code malveillant (« de l'intérieur vers l'extérieur »)	Brakeman, Code Climate, recherche de fonctions bannies
Analyse dynamique (DAST)	Tester pendant l'exécution, comme le ferait un attaquant (« de l'extérieur vers l'intérieur »)	Arachni, OWASP ZAP, Nmap, Metasploit
Analyse des dépendances	Inventorier binaires et exécutables au build et vérifier l'absence de vulnérabilités	Gemnasium, bundler-audit, Maven, OWASP Dependency-Check
Intégrité des sources et signature	Clé PGP par développeur, commits signés (gpg + git), paquets CI signés et empreintes journalisées	keybase.io, gpg, git

On définit aussi des patrons de conception aidant à écrire du code résistant aux abus — limitation de débit (rate limiting) sur les services, désactivation visuelle des boutons de soumission après un clic. L'OWASP publie à cet effet ses Cheat Sheets : comment stocker les mots de passe, gérer les oublis de mot de passe, journaliser, prévenir les failles de script intersites (XSS).

Assurer la sécurité de la chaîne d'approvisionnement logicielle

Comme l'observe Josh Corman, « nous n'écrivons plus de logiciel sur mesure — nous assemblons ce dont nous avons besoin à partir de pièces open source, qui forment la chaîne d'approvisionnement logicielle (software supply chain) dont nous dépendons ». Or en utilisant un composant, on hérite non seulement de sa fonctionnalité mais aussi de ses vulnérabilités. Le rapport Verizon PCI DBIR 2014 a montré que dix vulnérabilités (CVE) représentaient près de 97 % des exploits utilisés dans les fuites de données de cartes bancaires étudiées — et huit de ces dix avaient plus de dix ans. Le Sonatype State of the Software Supply Chain Report 2015 a complété ce tableau : une organisation typique s'appuyait sur 7 601 composants et 18 614 versions, dont 7,5 % comportaient des vulnérabilités connues, plus des deux tiers non résolues depuis plus de deux ans. On détecte donc les composants vulnérables et on privilégie les projets ayant un historique démontré de corrections rapides.

Assurer la sécurité de l'environnement

Il faut tout faire pour que les environnements restent dans un état durci, à risque réduit. On génère des tests automatisés vérifiant que tous les paramètres de durcissement, de sécurité des bases et de longueur de clé sont correctement appliqués, et on scanne les environnements pour les vulnérabilités connues. Nmap aide à s'assurer que seuls les ports attendus sont ouverts ; Metasploit, à vérifier le durcissement face aux attaques connues (injections SQL, par exemple). La sortie de ces outils est versée au dépôt d'artefacts et comparée à la version précédente lors des tests fonctionnels, afin de détecter tout changement indésirable dès qu'il survient.

Intégrer la sécurité dans la télémétrie de production

Marcus Sachs, chercheur du Verizon Data Breach, l'a constaté dès 2010 : année après année, dans la grande majorité des fuites de données de cartes, l'organisation détectait la brèche des mois ou des trimestres après les faits — et le plus souvent par un tiers (partenaire ou client constatant des transactions frauduleuses), parce que personne n'examinait les fichiers de log. Les contrôles de sécurité internes échouent donc souvent à détecter les brèches à temps, faute d'angles morts comblés ou faute d'examen quotidien de la télémétrie pertinente.

Le remède : déployer la surveillance, la journalisation et l'alerte de sécurité à travers applications et environnements, dans les mêmes outils que Dev, QA et Ops. En diffusant publiquement la manière dont les services sont attaqués en production, on rappelle à chacun de penser sécurité et de concevoir des contre-mesures dans son travail quotidien.

Télémétrie de sécurité dans les applications

Pour repérer un comportement utilisateur susceptible d'indiquer une fraude ou un accès non autorisé, on instrumente l'application : connexions réussies et échouées, réinitialisations de mot de passe, changements d'adresse e-mail, modifications de carte bancaire. Afficher le ratio de tentatives de connexion échouées sur réussies est par exemple un indicateur précoce d'attaque par force brute, à assortir d'alertes.

Télémétrie de sécurité dans l'environnement

On instrumente aussi l'environnement pour détecter les indices précoces d'accès non autorisé, surtout sur l'infrastructure qu'on ne maîtrise pas : changements d'OS, de groupes de sécurité, de configurations (OSSEC, Puppet, Chef, Tripwire), changements d'infrastructure cloud (VPC, utilisateurs et privilèges), tentatives de XSS et d'injection SQL (SQLi), erreurs serveur (4XX et 5XX).

Protéger le pipeline de déploiement lui-même

L'infrastructure qui soutient l'intégration et le déploiement continus constitue une nouvelle surface d'attaque. Si quelqu'un compromet les serveurs du pipeline détenant les identifiants de la gestion de version, il peut voler le code source — pire, s'il dispose d'un accès en écriture, injecter des changements malveillants dans le dépôt, donc dans l'application. Jonathan Claudius, ancien testeur senior chez TrustWave SpiderLabs, désigne la cachette idéale pour du code malveillant : « les tests unitaires. Personne ne les regarde vraiment, et ils tournent à chaque commit. »

Les stratégies d'atténuation incluent : durcir les serveurs de build et d'intégration et savoir les reproduire automatiquement ; revoir tout changement introduit en gestion de version (programmation en binôme ou revue entre commit et fusion dans le tronc) ; instrumenter le dépôt pour détecter des appels d'API suspects dans le code de test (un test accédant au système de fichiers ou au réseau), avec mise en quarantaine et revue immédiate ; faire tourner chaque processus CI dans son propre conteneur ou VM isolé ; et n'accorder au système CI que des identifiants de gestion de version en lecture seule.

Intégrer sécurité et conformité au change management

Presque toute organisation d'une certaine taille possède un processus de gestion des changements (change management), contrôle principal de réduction des risques d'exploitation et de sécurité — les responsables conformité et sécurité exigent la preuve que tout changement a été dûment autorisé. Si le pipeline est bien construit et les déploiements à faible risque, la majorité des changements n'aura pas besoin de passer par une approbation manuelle, car la confiance repose sur les tests automatisés et la surveillance proactive de production. Encore faut-il s'intégrer aux processus existants, qu'ITIL répartit en trois catégories.

Catégorie de changement	Risque	Approbation	Exemples
Standard	Faible	Pré-approuvé, pas d'approbation préalable, déploiement automatisable et journalisé	Mise à jour de tables de taxes, contenu et styles du site, patchs à impact bien compris
Normal	Plus élevé	Revue/approbation de l'autorité de changement (souvent le CAB) via un formulaire RFC	Gros déploiements de code, changements à impact incertain
Urgent	Potentiellement élevé	Approbation de la direction, documentation après coup autorisée	Patch de sécurité urgent, restauration de service

Un objectif clé du DevOps est de rationaliser le processus de changement normal au point de le rendre adapté même aux changements urgents. Le piège des changements normaux est de confier l'approbation à un comité consultatif des changements (change advisory board, CAB) ou à sa variante d'urgence (ECAB), souvent dépourvu de l'expertise nécessaire pour saisir l'impact réel — d'où des délais inacceptables, surtout pour de gros déploiements totalisant des centaines de milliers de lignes.

Reclasser le maximum de changements en « standards »

Avec un pipeline fiable, on gagne une réputation de déploiements rapides, fiables et sans drame. On cherche alors l'accord d'Ops et des autorités de changement pour faire reconnaître nos changements comme standards, pré-approuvés par le CAB. Pour étayer cette assertion, on montre l'historique des changements sur plusieurs mois et la liste complète des incidents de production sur la même période : un fort taux de succès des changements et un faible temps de restauration (MTTR) prouvent un environnement de contrôle efficace. Même standards, ces changements restent enregistrés (Remedy, ServiceNow) et idéalement déployés et tracés automatiquement, en les reliant aux tickets des outils de planification (JIRA, Rally) — sans imposer une friction inutile comme un ticket par commit.

Pour les changements qui restent normaux, on automatise la création de RFC complets et exacts : ticket ServiceNow pré-rempli avec lien vers la user story JIRA, manifestes de build, sorties de tests du pipeline et liens vers les scripts Puppet/Chef. On partage ainsi les preuves donnant confiance que le changement se comportera comme prévu, en privilégiant des données lisibles par la machine (liens vers des fichiers JSON).

Réduire la dépendance à la séparation des tâches

Pendant des décennies, la séparation des tâches (separation of duties) a été un contrôle majeur contre la fraude et l'erreur : un développeur soumettait son changement à un bibliothécaire de code, qui le revoyait et l'approuvait avant que l'exploitation ne le promeuve en production. Mais quand on déployait rarement (annuellement) et que le travail était moins complexe, ces cloisonnements et passations de relais étaient tenables. À mesure que la complexité et la fréquence de déploiement augmentent, la séparation des tâches ralentit et appauvrit le feedback que reçoivent les ingénieurs, les empêche d'assumer pleinement la qualité de leur travail et freine l'apprentissage organisationnel.

Contrôle	Logique	Effet sur le flux et l'apprentissage
Séparation des tâches	Cloisonner les rôles pour prévenir fraude et erreur	Ralentit le feedback, dilue la responsabilité, fragmente la connaissance
Revue par les pairs + automatisation	Programmation en binôme, inspection continue des check-ins, revue de code	Feedback rapide, responsabilité assumée, apprentissage continu — résultats équivalents prouvables

Partout où c'est possible, on évite donc la séparation des tâches au profit de la programmation en binôme, de l'inspection continue des commits et de la revue de code — contrôles qui rassurent autant sur la qualité, et permettent, si la séparation reste exigée, de démontrer des résultats équivalents.

Prouver la conformité aux auditeurs

L'adoption du DevOps crée une tension inédite avec l'audit, car ses patterns bousculent la pensée traditionnelle sur les contrôles et le risque. Bill Shinn, architecte principal chez AWS, pose le problème : « Combien d'auditeurs savent lire du code, et combien de développeurs ont lu le NIST 800-37 ? » Les méthodes d'audit classiques — échantillonner mille serveurs sur dix mille, collecter captures d'écran et fichiers CSV — n'ont plus de sens face à une infrastructure « as code » où l'auto-scaling fait apparaître et disparaître les serveurs en permanence.

Shinn fait travailler les auditeurs dans la conception des contrôles, un contrôle par sprint, et envoie toutes les données dans les systèmes de télémétrie (Splunk, Kibana) : l'auditeur n'a plus à demander un échantillon, il se connecte et cherche lui-même la preuve sur une plage de temps donnée, en libre-service. La démarche consiste à dériver les exigences d'ingénierie des réglementations elles-mêmes (HIPAA, par exemple), puis à les satisfaire par un paramètre en gestion de version ou un contrôle de surveillance — et à montrer où vont les logs, pour relier la preuve d'audit à l'exigence de contrôle.

Pour outiller ce dialogue, le DevOps Audit Defense Toolkit déroule le récit de bout en bout du processus de conformité et d'audit pour une organisation fictive (Parts Unlimited, de The Phoenix Project) : objectifs, processus, risques majeurs, environnement de contrôle, attestations et artefacts de contrôle, et objections d'audit avec leurs réponses. Il vise tous les objectifs de contrôle — reporting financier (SEC SOX-404), conformité réglementaire (HIPAA, FedRAMP), obligations contractuelles (PCI DSS, DOD DISA).

À retenir

• Le DevOps n'est pas l'ennemi de la sécurité : c'est le meilleur moyen d'intégrer la sécurité dans le travail quotidien de tous, là où le ratio Dev:Ops:Infosec de 100:10:1 rend l'automatisation indispensable (Rugged DevOps, DevOpsSec).
• La sécurité se déplace « vers la gauche » : présence de l'Infosec aux démos d'itération, suivi des failles dans le même outil que Dev et Ops, post-mortems systématiques, et bibliothèques pré-validées dans le dépôt partagé.
• On automatise les contrôles dans le pipeline — analyse statique (SAST), dynamique (DAST), des dépendances, intégrité et signature des sources — pour un feedback rapide à chaque commit ; Twitter a ainsi réduit ses vulnérabilités de 60 % avec Brakeman.
• On intègre la sécurité à la télémétrie de production : instrumenter applications et environnements pour voir les attaques en temps réel, comme Etsy affichant les tentatives d'injection SQL à tous ses développeurs.
• Le pipeline lui-même est une surface d'attaque : durcir les serveurs CI, revoir tout changement (y compris les tests unitaires), isoler chaque build et limiter les identifiants à la lecture seule.
• On réconcilie vitesse et change management en reclassant les changements à faible risque en standards (façon ITIL) sur preuve d'un historique fiable (fort taux de succès, faible MTTR), comme Salesforce avec Puppet.
• On préfère la revue par les pairs et l'automatisation à la séparation des tâches (dont la conformité PCI d'Etsy a montré le coût humain), et on prouve la conformité automatiquement via la télémétrie en libre-service et le DevOps Audit Defense Toolkit.