DevSecOps : place à la sécurité en livraison continue

Share this post:

Le DevOps est apparu en 2011, avec le développement agile, quand il s’agissait de développer le plus vite possible, en rapprochant développeurs et opérationnels. Le Secure by Design existe depuis plus longtemps, depuis la fin du siècle dernier en fait, dans l’avionique et les systèmes embarqués : impossible de programmer une carte électronique qui commande un missile sans intégrer la sécurité dans sa conception.

Avec DevSecOps, il s’agit de pousser les équipes de développement et les opérationnels à ne pas mettre la sécurité de côté. Conserver l’automatisation propre à la livraison continue est indispensable, l’objectif étant l’intégration de la sécurité tout au long du processus.

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

La stratégie DevSecOps démarre avant la moindre écriture d’une ligne de code. Dès que les métiers imaginent un projet, ils doivent penser à la sécurité. Cela nécessite la formation des métiers aux objectifs de sécurité afin de les sensibiliser à l’analyse de risques, formalisée par le standard ISO27005 et la modélisation des menaces (Threat Modeling).

L’analyse repose sur quatre critères rassemblés sous l’acronyme DICP (Disponibilité, Intégrité, Confidentialité, Preuve). Chaque critère s’évalue par exemple de un à cinq, suivant leur importance, afin de mesurer les risques associés au projet en cours de conception. Le rôle des métiers n’est pas de choisir une solution technique (en affirmant que la base de données doit être cryptée par exemple), mais de préciser leurs besoins en termes de critères de sécurité DICP.

La solution incombe à l’architecte d’entreprise (EA), qui livre son dossier d’architecture technique aux développeurs. L’architecte peut s’appuyer sur des frameworks standardisés, comme TOGAF avec SABSA pour la prise en compte de la sécurité dans l’architecture. Grâce à ce cadre, les développeurs écriront un code basé sur une architecture Secure By Design.

Un développeur formé à la sécurité des développements

La sécurité est considérée comme un frein par les développeurs, a fortiori à une époque où il leur est demandé de livrer du code rapidement. Leur formation est donc indispensable. Si tous les développeurs d’une équipe n’ont pas les compétences en matière d’écriture de code sécurisé, il est nécessaire que l’un, au moins, soit bien formé. Il sera une sorte d’ambassadeur de la sécurité qui portera la bonne parole auprès de ses collègues, à savoir le respect des standards de sécurité actuels.

Plusieurs standards existent, les plus connus étant OWASP pour les applications web, et SANS Top 25 pour le C, le C++ et d’autres applications. Au moment de l’écriture du code, le développeur dispose d’outils d’aide au Secure Coding : SAST (Static Application Security Testing) et DAST (Dynamic Application Security Testing). Ces outils peuvent être intégrés à l’environnement de développement (Eclipse, Visual Studio, NetBeans). Dans ce cas, le développeur doit en plus des tests unitaires et fonctionnels, ajouter des tests unitaires de sécurité.

Au niveau du repository, les outils SAST et DAST intégrés dans la chaîne de livraison se chargent de scanner le package complet de tous les backlogs écrits par les développeurs. Si le code n’est pas conforme à la majorité des règles de sécurité, l’outil indique au développeur ce qu’il convient de modifier en signalant les lignes de code vulnérable, le type de vulnérabilité et comment la corriger. En plus de ces tests en phase de développement, les équipes de sécurité opérationnelle peuvent faire des tests SAST/DAST, des scans de vulnérabilité ou des tests d’intrusion avant de valider la livraison en production du produit. Enfin, une fois en production, un contrôle de l’application s’impose, car une attaque inconnue ou 0-day peut toujours survenir. Des outils permettent ainsi de surveiller le comportement du code et de déceler une anormalité.

Assurer la maîtrise des coûts

Les trois piliers fondamentaux de la méthodologie DevSecOps sont donc :

• L’automatisation : tout comme DevOps tourne autour de l’automatisation lors des phases de build, le concept DevSecOps se concentre sur l’automatisation de la sécurité dans ces phases. Il s’agit d’industrialiser les vérifications de sécurité en éliminant le besoin de le faire manuellement au niveau de chaque développeur.
• Le correspondant sécurité dans l’équipe de développeurs que l’on peut appeler aussi « champion de la sécurité ».
• L’outillage : les différentes approches du DevSecOps peuvent être outillées (tests, gestion de la confidentialité, modélisation des menaces, équipe de build).

En intégrant la sécurité tout au long du développement et en conservant l’agilité propre à DevOps, cette stratégie aide à maîtriser les coûts. La sécurisation des applications, même si celles-ci sont protégées par divers outils tels que les firewalls, est d’autant plus importante que la plupart des attaques qui réussissent actuellement s’appuient sur une complicité interne (social engineering, hameçonnage…).

Une application sécurisée qui résiste aux attaques connues, c’est une application qui n’aura pas besoin d’être réécrite. DevSecOps exige certes un investissement de départ, en outillage et en formation, mais s’avère vite rentable : la réécriture d’une application est en effet très coûteuse. DevSecops rime avec sécurité continue, déploiement continu et intégration continue.

DevSecOps, l’avenir de DevOps

Lorsque l’on décide d’adopter une démarche DevOps, la dimension sécurité est absolument indispensable. En intégrant une démarche de sécurité continue à toutes les étapes du projet, DevSecOps est la suite logique de DevOps.

Loin d’être une lubie marketing pour redonner du sang neuf à la démarche DevOps, c’est une évolution naturelle et indispensable à un moment où les cyberattaques franchissent un nouveau degré d’intensité.

Article publié dans ZDNet le 9 Juillet 2019
https://www.zdnet.fr/actualites/devsecops-place-a-la-securite-en-livraison-continue-39887295.htm