Du DevOps au DevSecOps, intégrer la sécurité dès le développement

Pour la septième année, le fournisseur de solutions d’automatisation d’infrastructure Puppet a interrogé plus de 3000 professionnels de la tech sur leur adoption des méthodes DevOps. Classant en trois catégories les réponses des sondés sur leur fréquence d’utilisation, Puppet indique que près de 11% des organismes interrogés en ont un usage faible, 80% une utilisation moyenne et un peu moins de 10% les emploient intensivement. Point saillant de cette étude: le décalage entre le regard que porte les directions d’entreprises sur leur maturité DevOps et celui des équipes IT sur l’intégration de la sécurité. Plus de la moitié des cadres dirigeants (C-suite) estiment que leurs équipes de sécurité participent à la conception et au déploiement des technologies et que l’automatisation des configurations des politiques de sécurité est un acquis, contre seulement un peu plus de deux tiers des répondants issus d'équipes IT.

Faire de la sécurité une responsabilité partagée

Des écarts de perception qui mettent en lumière la problématique de l’intégration de la gestion de la sécurité dans les opérations plutôt qu’après coup, une pratique baptisée DevSecOps, néologisme né peu après celui de DevOps et qui suscite l’intérêt des décideurs IT depuis 3 ans. Elle consiste à adjoindre les équipes de sécurité aux équipes de développement et des infrastructures unifiées dans le DevOps. Pour ce faire, Puppet conseille l’utilisation du framework CAMS (Culture, Automation, Measurement, and Sharing) http://itrevolution.com/devops-culture-part-1/ tel que défini par par Damon Edwards et John Willis en 2010. Prêchant pour sa paroisse, l’entreprise de Portland préconise aussi l’utilisation d’un outil de gestion de configuration qui permette à chacun d'apporter des modifications aux configurations du système et des applications pour «faire de l'opérabilité et de la sécurité une responsabilité partagée au sein de l'entreprise.»

Mieux vaut prévenir que guérir

Mais selon les auteurs du rapport, il faut commencer petit. Une injonction top-down à l’échelle de l’entreprise est selon eux vouée à l’échec. Insistant sur le fait que les relations humaines entre les parties prenantes sont toute aussi importantes que les outils techniques à leur disposition, Puppet recommande d’intégrer dans un projet un membre de l’équipe de sécurité dès le début du développement d’un produit et de «commencer petit à petit en automatisant de manière collaborative la réponse à un type spécifique d'incident.» Dans une étude précédente (2016), le fournisseur de logiciel avait montré qu’intégrer la sécurité dans le cycle de livraison du logiciel plutôt que de la rétrofiter a posteriori diminue de moitié le temps passé à la résolution de problèmes de sécurité. Alors, même si «les configurations de sécurité sont l'une des choses les plus difficiles à automatiser», le jeu semble en valoir la chandelle. «Il est beaucoup moins coûteux de prévenir les problèmes de sécurité dans la conception de l'application que d'y réagir en production», conclut Puppet. Voilà qui n’est pas sans rappeler un célèbre adage médical.