Le DevSecOps : comment intégrer la sécurité au sein du cycle DevOps ?

DevOps vs DevSecOps : définitions

\nPour faire simple, le DevOps a pour but de rapprocher les développeurs de l'opérationnel. L'objectif principal du DevOps est de permettre un cycle de développement logiciel plus rapide, plus fiable et plus efficace. On parle donc, entre autres, de compilation de code, de tests unitaires, et de déploiement automatisé.\nLe DevSecOps quant à lui, en plus de faire du DevOpsEnsemble de techniques permettant l'intégration, les tests et le déploiement d'une application., a pour but d'intégrer la sécurité au sein du cycle de vie de l'application. On rajoute donc des problématiques de vérifications de vulnérabilité (que ce soit dans le code, l'infrastructure ou les dépendances du projet).

Pourquoi rajouter l'aspect sécurité dans le cycle DevOps ?

De nos jours, la sécurité devient un sujet de plus en plus important : les attaques sont toujours plus fréquentes, diverses et perfectionnées. Plus que jamais, la sécurité est un sujet primordial dans les projets informatiques et de développement web !

Les gains possibles du DevSecOps

Le fait d'inclure la sécurité tout au long de son projet a plusieurs intérêts :

• Tout d'abord, cela permet de se rendre compte très tôt des impacts au niveau sécurité d'une solution technique, et donc de réfléchir à une meilleure alternative rapidement. Sans cela, le risque est de se rendre compte des problèmes engendrés juste avant le déploiement en production. Il est toujours plus simple de corriger quelque chose au fur et à mesure qu'à la fin, alors ce serait dommage de prendre des risques inutiles !
• Le DevSecOps permet également d'inclure les développeurs dans la réflexion de la sécurité des applications, ce qui participe à leur formation !
• Le DevSecOps permet aussi de réduire les coûts des projets informatique : en étant proactif sur la résolution des failles, on se sécurise bien mieux des éventuelles attaques qui pourraient survenir en production et des coûts possibles liés à celles-ci.

Comment mettre en place du DevSecOps au sein de son entreprise ?

Formation des équipes

La première chose à faire est de former les équipes qui vont travailler sur les projets informatiques pour qu'elles comprennent la criticité de la sécurité informatique. C'est également l'occasion de leur donner les clés pour qu'elles aient en mains des solutions et/ou des méthodes de réflexion et que la sécurité soit un sujet de premier plan.\nParmi les questions que l'on peut se poser, on retrouve :

• Comment faire pour que tel projet soit sécurisé ?
• Ne devrait-on pas chercher quelque chose de maintenu par des équipes de confiance, plutôt qu'une autre qui ne l'est pas ?

L'intégration continue

De nos jours, les possibilités d'attaques sont très variées. Cela peut aller d'une dépendance du projet possédant une faille, à un mot de passe exposé dans le code source du projet, en passant par un serveur mal protégé. Et malheureusement, il en existe encore des centaines d'autres !\nIl n'est donc pas aisé de toutes les connaître et encore moins de les faire connaître par l'ensemble des équipes de développement.

C'est pourquoi, comme le DevOps, le DevSecOps implique de mettre en place de nouvelles étapes dans l'intégration continue du projet :

• Surveillance des vulnérabilités via des vérifications journalières des failles découvertes.

  Souvent, cela revient à vérifier les vulnérabilités des dépendances du projet. Les outils fournissent souvent les versions minimales de ces dépendances où la faille est corrigée, il ne reste donc plus qu'à faire la mise à jour.

• Scan de vulnérabilité. Il est possible de le faire de deux façons différentes :

  • L'analyse statique du code du projet. Cela revient à chercher des patterns qui correspondent à des failles connues (par exemple : des injections SQL ou des mots de passe non protégés).
  • L'analyse dynamique. Cela revient à lancer le projet et tester la réponse de l'application à différentes failles connues en conditions quasi réelles.

Les outils du DevSecOps

Comme pour tout bon sujet qui tourne autour du DevOps, il existe une multitude d'outils pour répondre aux différents besoins et automatiser les analyses.

Pour les analyses statiques, le plus connu est SonarQube. Il est majoritairement utilisé pour l'analyse de code source. Sonar prend en charge de nombreux langages de programmation, et possède une grande communauté.

Les analyses dynamiques sont souvent les moins faciles à analyser car elles nécessitent de pouvoir lancer l'application en conditions réelles. Pour ces dernières, l'outil le plus utilisé est ZAP (Zed Attack Proxy) d'OWASP qui peut trouver les failles les plus connues en lien avec des injections, les failles XSS ainsi que des problèmes de configuration de sécurité.

Pour la surveillance des nouvelles failles de sécurité, il existe des bases de données régulièrement mises à jour et qui listent les nouvelles failles de sécurité de différentes technologies, de bibliothèques mais aussi de systèmes d'exploitation. Parmi ces sites, on retrouve CVE (Common Vulnerabilities and Exposures) et NVD (National Vulnerability Database) qui sont les plus connus.

\nIl existe aussi des outils qui vont faire correspondre les vulnérabilités de ces données avec les différentes technologies utilisées dans vos projets. Parmi ceux qui existent, on retrouve l'outil Dependency-Track maintenu par OWASP.

DevSecOps : notre retour d'expérience !

Chez AXOPEN, la question de la sécurité applicative est primordiale. Depuis notre création en 2007, nous nous attelons à former l'ensemble de nos équipes (développeurs, chefs de projet, etc.) à la problématique de la sécurité.

Et depuis quelques années, nous avons rajouté certains outils au cycle de vie de nos projets. Nous avons par exemple mis en place des analyses statiques automatisées via SonarQube empêchant toute validation (et donc livraison) de code ne respectant pas la sécurité (et aussi la qualité de code) que nous souhaitons. Nous avons également mis en place des remontées d'informations concernant les nouvelles failles de sécurité et les projets impactés.

Pour terminer, si on avait un conseil à vous donner, ce serait de choisir des outils reconnus et maintenus ! Car dans un secteur où les choses changent très vite, il est primordial que l'outil soit au fait des nouvelles technologies, mais surtout qu'il connaisse le plus tôt possible les dernières failles de sécurité. Si vous avez besoin d'aide ou d'un conseil plus précis sur votre contexte, n'hésitez pas à nous contacter directement !