Comment réussir sa transformation DevSecOps ?

Pour ne pas risquer de perdre ainsi tous les bénéfices de l’accélération des mises en production à travers le DevOps, l’enjeu est donc de faire en sorte que les versions applicatives intègrent le plus en amont possible les exigences de l’équipe RSSI. Autrement dit, intégrer les aspects sécurité dans le cycle de vie applicatif. C’est la définition même de DevSecOps.

Lorsqu’une démarche DevOps est mise en place, un certain nombre de tests qui expriment les préoccupations des métiers (tests de non-régression, de performance…) et de la production (exploitabilité, opérabilité,) sont positionnés tout au long du pipeline de développement. Avec DevSecOps, il s’agit de prendre en compte et d’intégrer l’équipe Sécurité en amont et tout au long du projet.

Pour cela, deux axes forts sont à retenir :

L’approche Security By Design

Dans une démarche DevSecOps, le développement, la production et la sécurité sont amenés à collaborer de façon rapprochée. Pour que chacun apporte de la valeur à travers sa spécialité et sache prendre en compte les préoccupations et les efforts des autres, il faut faire évoluer la culture, la maturité et les compétences de chacun. Il ne s’agit pas seulement d’inculquer les bonnes pratiques, mais de convaincre du bien-fondé de la démarche pour qu’elles soient appliquées. De plus, l’objectif d’une méthodologie de mise en œuvre de la sécurité dans les productions applicatives est de rendre les développeurs et les Ops autonomes dans l’identification des anomalies sécurité et les actions de remédiation. Il n’existe pas assez de spécialistes sécurité des environnements applicatifs pour couvrir toutes les équipes de développement du monde, il faut donc miser sur le transfert de connaissances et l’acculturation. D’autant que cela contribuera également à valoriser les efforts des développeurs et des Ops qui vont vers le DevSecOps.

…vec le DevOps, les développeurs sont désormais accoutumés à intégrer dans leur backlog des éléments venant des Ops. Dans le contexte actuel, ils sont aussi de plus en plus sensibilisés aux enjeux de sécurité. En revanche, ils doivent développer les réflexes et les pratiques de « secure coders ». Pour accompagner cette montée en compétence, on mettra donc en place un coaching, qui peut être individuel et/ou collectif. On peut aussi utiliser des serious games, ou encore désigner et former des relais au sein de l’équipe. L’approche doit être conçue sur mesure en fonction de la maturité de l’équipe, de sa taille, de la criticité des enjeux… C’est la même chose côté production, avec ici l’avantage que les équipes sont d’autant plus sensibles à la prévention des cyber-incidents qu’elles en gèrent régulièrement les impacts. Ils doivent également intégrer dans leurs produits d’infrastructure les contraintes de sécurité associées.

Enfin, il ne faut pas négliger l’acculturation des équipes sécurité elles-mêmes, qui jusqu’à présent n’était pas obligatoirement intégrées dans les processus de livraison des applications. Elles doivent intégrer pleinement les cérémonies ou meeting permettant d’influer sur le backlog de développement et ainsi intégrer dès les phases de Design les contraintes de sécurités dans les roadmap applicatives. Il leur faudra aussi faire évoluer leurs pratiques pour pouvoir faire entrer sans délai les dernières évolutions en matière de cybersécurité dans le cycle de vie applicatifs : ajout ou suppression de points de vigilance, sessions de sensibilisation à de nouveaux risque, mise à jour des outils, création de task forces pour les failles majeures…

La mise en place des Security Gates

Et le deuxième axe de la mise en œuvre de DevSecOps, c’est le contrôle, avec la mise en place des Security Gates au sein du pipeline DevOps de manière à réaliser au plus tôt les tests appropriés, et donc à avoir un minimum d’efforts de correction à réaliser. Rappelons qu’il coûte jusqu’à 30 fois moins cher de corriger une faille de sécurité avant la mise en production qu’après ! Ces tests interviennent aussi bien sur la partie Dev (code et artefacts) que sur la partie Ops (socle applicatif, middleware, conteneurs…). Automatisés, ils renvoient les anomalies à traiter dans le backlog. Pour ce faire, il existe sur le marché de nombreux outils qui s’intègrent aisément aux pipelines. Bien souvent, les entreprises ont déjà la possibilité de réaliser certains de ces contrôles avec les outils dont elles disposent, qu’il suffira éventuellement de compléter.

Basée sur ces axes complémentaires d’acculturation et de contrôle, la transformation DevSecOps est moins profonde et plus simple à mettre en œuvre lorsqu’une transformation DevOps a déjà été opérée. Le pipeline existe et il est plus facile de l’enrichir qu’il n’a été de le créer. Et le décloisonnement requis par DevOps a créé un précédent culturel et opérationnel qui facilite la mise en place de nouvelles collaborations.

Le principal défi est de positionner correctement le curseur des exigences. Si la sécurité décidait seule, la moindre faille serait rédhibitoire ! Dev, Sec et Ops doivent réussir à se mettre d’accord sur le niveau d’urgence et de gravité des anomalies à régler. Le mieux pour cela est de procéder pas à pas, en commençant, par exemple, par s’accorder sur un Top 10 des failles qu’on ne peut pas laisser passer. Une fois ces priorités traitées, on pourra élargir la liste. On voit ici aussi toute l’importance de mettre en place des indicateurs communs et explicites afin de faciliter le dialogue et de mesurer les progrès.

De plus, il faut aussi miser sur les préoccupations d’une équipe de développement et en particulier sur la mesure du risque de régression fonctionnelle sur correction. Classer les vulnérabilités et leur correction et en ressortir des « quick win » sur celles qui sont critiques et qui ne présentent peu voire pas de risque concernant la régression fonctionnelle, est un argument supplémentaire pour convaincre les Scrums et Product Owners d’ajouter les corrections dans le prochain backlog.

DevSecOps consiste en définitive à casser un silo supplémentaire et à remplacer la barrière qui séparait la sécurité du développement applicatif par une collaboration harmonieuse. Mais qui dit décloisonnement, dit aussi remise en cause de prés carrés, interrogations sur les affectations de ressources et âpres discussions budgétaires. La force du collectif et la mobilisation des sponsors dans le projet sont fondamentales pour aplanir ces inévitables difficultés et permettre la réussite de la transformation. Avec la bonne impulsion, on peut dès lors obtenir en quelques mois des progrès significatifs en matière de sécurité applicative.