DevSecOps : intégrer la Sécurité à vos pratiques DevOps

Livrer des logiciels de qualité rapidement et qui puissent apporter de la valeur aux entreprises, voilà un défi auxquels sont confrontées toutes les équipes de développement. Pour y répondre, la culture Agile, puis son prolongement, la culture DevOps apparaissent comme l’approche idéale pour fournir des solutions qualitatives tout en réduisant le Time to market.
L’intérêt de cette culture DevOps dans le processus de création n’est plus à démontrer, la méthode a fait ses preuves et a su réconcilier Devs et Ops. Cependant, elle semble oublier une certaine facette du développement, celle de la sécurité des applications.
C’est pour répondre à cette problématique de sécurité qu’est en train d’émerger une évolution de cette approche, le DevSecOps. Si l’Agilité cherche à rapprocher décideurs et développeurs dans la même équipe et que DevOps y intègre les problématiques (et les équipes) d’opérations, DevSecOps rajoute un acteur essentiel à un projet : la sécurité.
Dans cet article, nous tenterons de vous présenter l’intérêt de cette démarche, son fonctionnement, ainsi que les évolutions qu’elle entraîne au sein de la DSI mais aussi du côté des équipes de développement.
La cybersécurité, un enjeu toujours plus important
Les failles de sécurité, les fuites de données, les ransongiciels, autant de sujets de plus en plus critiques pour les entreprises. Nous avons d’ailleurs pu le constater récemment avec Peyta qui a ébranlé de nombreuses sociétés.
Il est évident que le nombre de menaces augmente et qu’il est plus que nécessaire pour les entreprises de s’en protéger. Par ailleurs, la mise en application récente de la RGPD, implique des sanctions très lourdes pour les entreprises négligeant cet aspect.
Si certains investissent dans toujours plus de sécurité réseau, des pares-feux et autres défenses périmétriques, cela ne résout pas les problématiques générées par le développement logiciel. Voilà pourquoi il faut repenser la manière dont on conçoit les projets de développements, tant au point de vue organisationnel que dans le code qui est produit.
Comme nous l’avons souligné en introduction, le DevOps est venu répondre à une problématique de temps, l’idée est de pouvoir mettre en production toujours plus rapidement. Cette contrainte de Time to Market implique que les équipes de développement se concentrent sur la manière de développer rapidement, alors que côté Ops l’objectif est de pouvoir tester et déployer rapidement. Deux préoccupations, certes majeures, mais qui ont tendance à relayer l’aspect sécurité au second plan.
Sur quoi repose le concept de DevSecOps ?
La démarche DevSecOps pour “Développement-Sécurité-Opérations” est avant tout une remise en question du cycle de développement d’un projet informatique. La sécurité ne doit ainsi plus être vue comme une composante secondaire dans le projet, limitée à une implémentation périphérique, mais comme une évidence, un prérequis sans lequel on ne peut développer.
Pour repenser la façon dont on conçoit un logiciel, il est plus que nécessaire de faire éclater les silos organisationnels. Pour Fraser Scott, Cloud Security & DevSecOps à Capital One “la sécurité doit faire partie du travail de chacun”. En effet, la sécurité est souvent relayée à une équipe tierce et donc indépendante du développement direct de l’application.
L’un des principes fondateurs de la démarche DevSecOps repose donc sur l’idée que chaque intervenant dans le cycle de développement est également responsable de la sécurité. On retrouve d’ailleurs cette idée dans le concept de Security Champion de Philippe Lorieul, où toute l’équipe de développement doit être sensibilisée aux concepts d’AppSec. Ici, il est également question de rajouter une personne à l’équipe de développement afin qu’elle puisse être garante de l’aspect sécuritaire.
Mais concrètement, quelles sont les actions que l’on peut mettre en place pour appliquer cette culture DevSecOps ?
Automatiser la sécurité
L’automatisation est déjà au cœur de la culture DevOps et repose sur des concepts de déploiement et intégration et continue. Pour DevSecOps, on reprend cette notion d’automatisation de tâches mais cette fois en rapport avec la sécurité. L’objectif principal reste l’accélération de la livraison, mais cela incorpore aussi le monitoring qui permet d’effectuer une surveillance plus importante, et permet donc d’éliminer les erreurs introduites par les déploiements manuels.
L’automatisation permet aussi aux équipes de développeurs de pouvoir revenir à des versions antérieures rapidement en cas de failles de sécurité liées au code.
On cherche aussi, par l’utilisation d’outils, de tests, … (vérification de code, analyse statique de code, analyse dynamique, scan de vulnérabilité) à s’assurer qu’aucune faille n’a été introduite à la future version du produit. On assiste le développeur, on lui ajoute un filet de sécurité entre développement et déploiement : Dev -> Sec -> Ops. Cette « sécurité par rollback » n’est cependant qu’une première étape !
La Sécurité dès la conception ?
Si l’on revient sur cette notion de projet, on se rend très vite compte que DevOps permet de mettre en place de bonnes pratiques, tant dans la conception du logiciel, que dans son déploiement. C’est sur cette base que repose aussi l’approche DevSecOps. En effet, dès les premières phases de conception, il faut prendre en compte l’aspect sécurité et imposer des procédures à suivre.
Continuous Security Improvement
Le développent et l’intégration de solutions se fait en continu sur des itérations basées sur le modèle de développement et de déploiement continu ainsi que sur l’intégration continue (CI/CD). DevOps fait partie intégrante de l’ensemble du spectre CI/CD.
DevOps permet au code d’être déployé et de fonctionner de manière transparente, mais comment situer la sécurité dans cette logique CI/CD ? Il apparaît donc comme logique de mettre en place des phases de tests sécuritaires en continu.
Quels impacts sur la DSI ?
Mettre en place une démarche DevSecOps nécessite donc de profondes transformations du côté des équipes de développement. Mais comment est-ce que cela va impacter la DSI ? Voici quelques pistes et recommandations stratégiques :
- Recruter et constituer vos équipes de développement en conséquence. La sensibilisation des équipes aux principales failles de sécurité peut se faire à l’aide d’ateliers ou de formations.
- Réorganiser les équipes de développement, en y intégrant un Security Champion par exemple.
- Repenser la logique de développement de vos projets.
- Anticiper les problèmes de dette technique pour limiter certaines failles de sécurité.
- Equipez les ingénieurs DevOps pour démarrer un développement sécurisé.
- Testez votre sécurité d’application en continu
- Adoptez le contrôle de version et la gestion rigoureuse des outils d’automatisation de l’infrastructure.
- Adaptez “la sécurité continue” en tandem avec “intégration continue” et “déploiement continu”.
Quel avenir pour DevSecOps ?
Certains vont considérer que DevSecOps n’est qu’un nouveau Buzzword inventé par les marketeux pour redonner un coup de neuf à DevOps. Ou que finalement la sécurité n’a peut-être pas directement sa place dans cette démarche. Le fait est que DevSecOps est la suite d’un cheminement logique qui ne peut se mettre en place sans avoir au préalable pris en compte l’Agilité et le DevOps dans votre organisation.
DevSecOps, SecDevOps ou DevOpsSec ?
Si le terme de DevOps n’est plus vraiment sujet à discussion, celui de son évolution « DevSecOps » lui pose encore certaines questions. Lorsque l’on se renseigne on voit que le « Sec » a du mal à trouver sa place, tantôt placé au milieu, puis au début, on se retrouve vite devant ces différentes variantes : DevSecOps, SecDevOps, DevOpsSec. Ne serait-ce pas là un exemple flagrant qui démontre que l’on ne sait pas vraiment où positionner la sécurité ?
Conclusion
Lorsque l’on décide d’adopter une démarche DevOps dans un projet, il ne faut surtout pas oublier l’aspect sécurité. Il est nécessaire de réfléchir à la façon dont vous souhaitez intégrer la sécurité dans tous les aspects de votre cycle de vie et à toutes les étapes du projet. Finalement quand on y pense, n’aurions-nous pas besoin de SecDevSecOpsSec ?