DevSecOps : intégrer la sécurité à l'approche DevOps

Quand on découvre l’expression DevSecOps, on se dit qu’on se serait bien passé de ces trois lettres ajoutées à l’abréviation DevOps. Elle se situe pourtant dans le prolongement logique de l’approche DevOps. Cette dernière est définie dans ses grandes lignes comme le processus visant à déconstruire les silos au sein des organisations de façon à ce que les développeurs et les équipes IT opérationnelles travaillent côte à côte, en automatisant tout ce qui peut l’être, pour atteindre des objectifs communs : livrer de meilleures applications, plus stables, de façon plus rapide. Ajouter la sécurité dans ces processus depuis le départ apparaît pour le moins sensé.

Les questions de sécurité exigent souvent des intervenants extrêmement spécialisés. Le risque, avec une stratégie DevOps qui les exclut, c’est de laisser ces profils talentueux en dehors de l’équation jusqu’à la phase de pré-release de l’application ou, pire, au-delà de la phase de livraison. Avec les conséquences inhérentes qui peuvent se décliner du « passablement irritant » au « potentiellement catastrophique ».

Concevoir la sécurité au cœur des cycles devops

DevSecOps, c’est engager DevOps sur les bons rails dès le début, pointe Mike Bursell, l’architecte sécurité en chef de Red Hat. « Si vous faites du devops mais que vous ne mettez pas la sécurité au centre de votre processus, vous ne faites pas correctement du devops », a-t-il expliqué à nos confrères de Computerworld UK. « Cela ne veut pas dire que la sécurité doit prendre le pas sur tout ce que vous faites, parce que s'il en est ainsi, vous allez vers la paralysie. Mais cela signifie que vous devez concevoir la sécurité au cœur de vos cycles devops. C’est ça, le devsecops ». Une telle approche, si elle est bien menée, combine des outils, des processus et une culture. « Enrôler vos experts en sécurité, les intégrer à l’équipe et les amener à embarquer leurs différents domaines de connaissance dans le processus vous permet d’automatiser la sécurité dans votre modèle devops, de telle façon que chacun bénéficiera de leur expertise », expose Mike Bursell.

Consultante senior chez Synopsys, Meera Rao le confirme. Elle ajoute que de nombreuses organisations envisagent d’acquérir un outil, ou un ensemble d’outils, comme une première étape pour aller vers l’agile ou vers le devops. « Les outils ne sont pas des solutions fourre-tout », précise-t-elle. « Le devsecops ne peut pas être simplifié seulement en automatisant avec un jeu d’outils. Cependant, quand l’outil d’automatisation est mis en œuvre correctement, ses mérites sont irréfutables. A l’inverse, lorsque c’est mal fait, les équipes de développement, opérationnelles et de sécurité vont perdre leur temps, leurs efforts et leur argent ».

Ne pas introduire la sécurité dès le début multiplie les risques

Si certains développeurs de haut niveau peuvent maîtriser différents aspects de sécurité, ils préféreront se concentrer sur l’écriture et le test des logiciels. C’est très bien s’ils sont au fait des questions de sécurité et soucieux de ces sujets dans le cadre de leurs tâches habituelles, mais tous ne pourront ou ne voudront pas l’être. « La sécurité est un domaine qui m’intéresse, mais ce n’est pas le cas de tout le monde et personne n’a envie d’intimer aux développeurs d’être désormais des experts en sécurité parce qu’il y a beaucoup de choses à assimiler et que, de toutes façons, ça n’arrivera jamais », avait précédemment expliqué Mike Bursell à Computerworld UK. « Mais à l’inverse, si vous dites qu’il y a des personnes dont la responsabilité est d’assurer que nos politiques de sécurité sont automatisées dans les processus, eh bien, on peut tout simplement s’assurer que tout le monde suit ces processus et que l’on peut gérer par exception. Alors, cela commence à avoir du sens ».

Exclure la sécurité au départ met les entreprises en danger d’une multitude de façons différentes. Il suffit d'énumérer quelques scénarios. Premièrement, l’équipe de sécurité s’aperçoit qu’une livraison logicielle est pleine de failles et la renvoie pour qu’elle soit corrigée. Deuxièmement, une version non sécurisée se retrouve dans la nature, l’équipe de sécurité s’aperçoit qu’elle est truffée de failles et la renvoie pour test. Troisièmement, une version non sécurisée est diffusée, des attaquants compromettent votre réseau ou les réseaux de vos clients, des intrusions ont lieu, les systèmes informatiques en sont affectés, l’entreprise tout entière subit d’irréparables dommages de réputation, des amendes importantes, tout le monde est viré et, finalement, c’est la faillite. Bon, le dernier scénario est bien sûr exagéré, mais par comparaison, cela demande peu d’efforts de restructurer sa façon de travailler pour introduire la sécurité dans le processus dès le début. Et cela vaut mieux que de s’exposer au risque.

Un voyage sans fin

A quoi ressemble une organisation qui fait du devsecops de la bonne manière ? C’est un voyage sans fin. Vous n’en avez jamais fini. Si cela semble kafkaïen, eh bien, désolé, mais c’est exactement cela. Voici deux ou trois choses à prendre en considération. Premièrement, il faudra ouvrir des canaux de communication entre toutes les parties concernées. Il faut que chacun soit informé à travers des outils de collaboration qui montrent l’état d’avancement de chaque projet. Tout cela aidera à réduire les frictions entre les équipes. « En procédant ainsi, les équipes de sécurité sur les applications devraient choisir les outils, technologies et processus les plus appropriés pour supporter une collaboration étroite », estime Meera Rao, de Synopsys. Elle ajoute que mettre en place ces étapes, aider à casser ces traditionnels silos entre les développeurs, les opérationnels et les équipes de sécurité.

De solides outils d’audit et processus doivent également être mis en place avec la liste de toutes les modifications effectuées et l’endroit où les changements ont été effectués pour pouvoir y revenir rapidement s’il le faut. « Il est important de créer un process reproductible et auditable sur lequel l’équipe devsecops peut s’appuyer et sur lequel elle peut établir un budget », explique Meera Rao. « Permettre aux activités de sécurité de s’adapter rapidement pour répondre à des objectifs qui évoluent et faire face à des menaces qui se transforment facilite le changement collaboratif dans le cadre d’un programme devsecops.

Des défauts résolus très en amont du cycle

Directeur de recherche sur la sécurité des informations pour le cabinet d’études 451 Research, Daniel Kennedy explique que si un programme de sécurité applicative fonctionne, les malfaçons sont résolues très en amont dans le cycle de développement des logiciels. « Si les capacités de type SAST - Static application security testing* - sont mises entre les mains des développeurs, de même que des outils d’apprentissage pour identifier les problèmes sur le code, on devrait trouver moins de code vulnérable dans les builds », pointe-t-il. « Et les tests de régression ou audits de sécurité effectués ensuite devraient détecter moins de problèmes de sécurité ». Selon lui, il y a plusieurs façons de le mesurer. « La plus évidente, c’est la réduction des défauts identifiés avec un outil de sécurité. Mais les capacités d’amélioration continues interviennent quand on peut commencer à exposer les défauts à un niveau inférieur et que l’on peut les corriger plus tôt dans le cycle de développement du logiciel. Le nombre de personnes intervenant sur ces problèmes est ainsi moins important, cela se fait plus tôt dans le cycle et on limite le coût de correction ».

Il y a quelques métriques standards auxquelles les organisations peuvent recourir pour mesurer le succès d’un programme de changement. Des analyses trimestrielles peuvent aider à s’assurer que l’on est sur la bonne voie en se posant quelques questions clés. Meera Rao en suggère quelques-unes : « Où en sommes-nous de la mise en œuvre devsecops ? Quels sont les défis que nous rencontrons et comment y faire face ? Qu’est-ce qui fonctionne et comment résoudre les difficultés ? Cela peut être considéré à la fois en termes de progrès à court et long termes. Evidemment, rien ne peut être à 100% sécurisé, mais être capable d’impliquer chacun sur les questions de sécurité signifie que les problèmes critiques ont des chances d’être aplanis au plus tôt pour nous épargner plus tard de sérieux maux de tête.

() SAST (Static application security testing) : Le cabinet Gartner les définit comme un ensemble de technologies conçues pour analyser le code source des applications, le byte code et les fichiers binaires et les conditions de conception pour se placer dans des conditions d’écriture de code et de conception susceptibles de révéler des failles de sécurité. En d’autres mots, il s’agit de passer au peigne fin le design d’une application pour y trouver les bugs potentiels, les trous ou vulnérabilités.*