Les innovations technologiques des dernières années, en particulier la possibilité de déployer très rapidement des infrastructures dans le cloud, ont mis en évidence les limites des méthodes traditionnelles de développement logiciel en cascade, basées sur une succession séquentielle d’étapes prédéfinies.
Cela a conduit à l’émergence des méthodes agiles et de la culture DevOps, marquées par des cycles de production plus courts, l’automatisation et l’atténuation du clivage historique entre équipes des développement (Devs) et administrateurs des infrastructures (Ops), résumé par la célèbre devise de Werner Vogels, CTO d’AWS, « you build it, you run it ».
Les entreprises qui ont adopté avec succès ce changement culturel ont réussi à réduire sensiblement leur « time to market », en déployant leurs produits logiciels avec une rapidité inconcevable auparavant.
Cette vitesse accrue a pourtant introduit de nouveaux challenges pour la sécurité des applications : comment éviter les vulnérabilités tout en assurant plusieurs déploiements par semaine voire par jour ?
Nous pensons que la récente approche DevSecOps est pertinente pour répondre à cette exigence.
En voici les 3 axes qui sont à notre avis les plus importants :
Shift security to the left
Il est unanimement accepté que l’effort de sécuriser une application après coup est extrêmement plus couteux que l’intégration des exigences de sécurité dès sa conception. Pas de débat donc sur la nécessité d’intégrer la sécurité dès le début (à gauche sur l’axe temporel), mais comment faire en pratique ?
Embarquer un expert sécurité dans chaque équipe de développement est couteux et pas scalable. D’un autre côté l’équipe Sécurité (quand il y en a une… !), peut se montrer trop réfractaire au risque et abuser de son pouvoir de veto, introduisant des délais indus dans les déploiements.
DevSecOps propose ces pratiques :
- Former les codeurs au développement sécurisé, par exemple en s’appuyant sur le très riche matériel mis à disposition par l’Open Web Application Security Project (OWASP) ;
- Faciliter la communication entre les Devs, les Ops et la Sécurité, par exemple à travers des sessions de partage de l’information, des conférences et des ateliers de travail collaboratif ;
- Promouvoir la sécurité comme un état d’esprit et une valeur de l’entreprise.
Automatiser les contrôles de sécurité
Les contrôles de sécurité doivent être implémentés tout au long du cycle de vie du code, autrement dit dans le pipeline d’intégration et de livraison continu. Le panel de tests automatiques doit être enrichi par des tests liés à la sécurité, en intégrant idéalement des outils d’analyse statique et dynamique de code. On a récemment vu émerger le terme Test Driven Security (TDS), inspirée du plus connu Test Driven Development (TDD).
Le risque, à ce stade, est que les faux positifs se multiplient ; il est très important d’en maîtriser le nombre à travers un travail de tuning, pour ne pas retarder à tort les livraisons… la vitesse de livraison étant le nerf de la guerre !
La génération de métriques liées à la sécurité va de pair avec cet effort d’automatisation, et permet de remonter des KPI essentielles à la communication avec les responsables métier.
Désigner des champions sécurité
Comme indiqué plus haut, il n’est pas viable de positionner des experts sécurité dans chaque équipe de développement : l’approche préconisée par DevSecOps est de promouvoir des champions sécurité parmi les membres des équipes Dev et Ops. Ces « champions » doivent devenir le relais de l’équipe Sécurité, à travers un parcours de sensibilisation et de formation.
Parmi les responsabilités qu’ils peuvent porter, il y a les suivantes :
- Décider à quel moment demander l’avis des experts sécurité
- Animer les revues de code (Dev) et les audits de configuration (Ops)
- Coordonner la modélisation des menaces
- Sensibiliser les collègues aux bonnes pratiques de sécurité
Il est important de préciser que ces nouvelles pratiques de sécurité n’éliminent pas pour autant l’importance de réaliser périodiquement des tests d’intrusion applicatifs et de se doter d’un système d’analyse et corrélation des logs (SIEM), idéalement administré par un Security Operations Center (SOC).
Par Giuliano IPPOLITI (RSSI et Directeur Grand Ouest chez Cloud Temple)