DevSecOps : une philosophie de dev au service des organisations

Pour inaugurer nos tutoriaux consacrés aux grandes tendances IT d’aujourd’hui (et de demain), focus ce mois-ci sur le DevSecOps.
Au-delà d’un mot d’ordre – instaurer les enjeux de sécurité à chaque étape clé d’une stratégie DevOps – cette philosophie implique 
de vrais bouleversements technologiques pour les développeurs. 

Le DevSecOps : pour qui et pourquoi ?

Depuis une dizaine d’années, la philosophie du DevOps ne cesse d’infuser dans les services IT de différentes structures – que l’on parle de grands groupes ou de PME. Dans son principe même, le DevOps se base sur un pipeline étape par étape (Plan/Create/Verify/Package/Release/Configure/Monitor) où seront implantés à la fois des automates d’intégration continue et de livraison continue.

L’intérêt de DevOps ? Sa fluidité, sa fiabilité, sa philosophie, qui permettent une livraison rapide et continue d’applis et logiciels pouvant être maintenus de manière directe rapidement. Seul un inconvénient du modèle originel amène l’environnement à être repensé : la sécurité. En effet, cet aspect fondamental est parfois négligé au profit de la vitesse de développement et de déploiement, si bien que les étapes de sécurité sont placées à la toute fin de la production.

Pour répondre à cet enjeu, la philosophie DevSecOps est apparue. Elle se propose de mettre en place des tests de sécurité dès le début du développement d’un logiciel, d’une mise à jour, et de réitérer ces tests à chaque étape. Dans le code, dans le build, le critère de la sûreté devient aussi important que les autres aspects, puis se propage tout au long de l’intégration continue et de la livraison continue. La chaîne DevSecOps se découpe en huit étapes : (Plan/Code/Build/Test/Release/Deploy/Monitor/Respond).

Avec le DevSecOps, on touche à l’efficacité et à la pérennité des systèmes informatiques développés en interne. L’implication de la problématique de sécurité dès les premières étapes permet de fédérer les équipes autour de cet axe, de réduire les incidents techniques (en étant davantage proactif sur les vulnérabilités) et de limiter les pertes de temps et d’argent que peut générer la correction d’une faille a posteriori.

En quelques étapes, voici les principales manières d’introduire DevSecOps dans la chaîne d’outils DevOps.

TUTORIAL

étape 1 : DevSecOps dans le code

En résumé, DevSecOps repose sur le bon vieux dicton « le plus tôt sera le mieux ». Les études montrent qu’une vulnérabilité décelée au cours du développement coûte à un service dix fois moins cher qu’en phase de test, et cent fois moins qu’en mise en production. C’est pourquoi dans toute démarche intégrant la sécurité dès le départ, l’utilisation d’outils SAST s’avère essentielle. Les suites de « Static Application Security Testing » cherchent directement dans le code, avant son exécution, toutes les potentielles vulnérabilités, et proposent aux développeurs une revue de code pointue.

En général, les grandes applications SAST comme Fortify ou Veracode reposent sur des mises à jour précises des vulnérabilités détectées par les spécialistes de la cybersécurité. Dans le domaine des applications web en particulier, les outils proposés par OWASP, qu’il s’agisse des données sur les vulnérabilités ou de leurs solutions, sont à coupler avec les SAST. Outre la possibilité d’éviter des erreurs courantes (une fonction appelée bypassant un accès utilisateur protégé, par exemple), les solutions SAST les plus avancées assistent les codeurs en proposant des degrés d’analyse adaptés à leur besoin – priorité sur la vitesse d’exécution de la vérification ou sur la profondeur, par exemple – et s’implémentent parfaitement dans un processus CI/CD. De telle façon que chaque mise à jour du code demandée en aval sera à nouveau analysée en amont.

étape 2 : DevSecOps dans le build

En dehors du SAST, qui continue d’être appliqué lors du build lorsque certains bugs techniques induisent des corrections nécessitant une nouvelle analyse, les pratiquants du DevSecOps intègrent en général à l’occasion des compilations une analyse des dépendances, ou Software Composition Analysis (SCA). Une bibliothèque Python non encore patchée, une faille dans un backend Node.js autorisant l’exécution de code en remote ? Grâce à des outils SCA comme Black Duck ou Veracode, là encore il est simple de paramétrer une analyse qui sera répliquée dans l’ensemble de la chaîne CI/CD du projet. Il est par ailleurs recommandé, toujours dans l’optique de respecter la démarche DevSecOps, d’assortir le logiciel d’outils de conteneurisation, notamment Docker, afin de disposer d’environnements de développement et de build fidèles au résultat final côté exploitation.

étape 3 : DevSecOps côté test

Dans la phase de test, inhérente à chaque projet, on fait appel à une autre technologie : le Dynamic Application Security Testing (DAST). Ce processus se place non pas « à l’intérieur » de l’application ou du logiciel, mais en dehors. Faciles à paramétrer, des outils comme Invicti ou InsightAppSec testent toutes les attaques possibles et se mettent à jour afin d’étudier de nouvelles vulnérabilités. Ainsi, durant une phase de test de logiciel, en fin d’intégration continue, la batterie d’essais concoctés par les outils DAST (et qui peuvent prendre plusieurs jours) vient découvrir les éventuelles failles non détectées dans l’écriture du code.

Certaines équipes DevSecOps font aussi le choix de cumuler DAST et SAST par le biais d’une solution dite IAST, pour Interactive Application Security Testing, c’est-à-dire une solution intégrée directement à l’application, via des « agents » installés sur le serveur web. Ces agents font remonter les informations de vulnérabilité potentielle en temps réel tout au long du cycle de vie du développement logiciel, ce qui peut être une solution plus simple et automatisée que les tests DAST et SAST exécutés séparément.

étape 4 : DevSecOps côté déploiement continu

L’intérêt de DevSecOps dans un environnement en « pipeline CI/CD » demeure la continuité de la sécurité dans l’intégralité des phases. Lorsqu’un projet parvient du côté « Ops », de nombreux outils sont disponibles pour améliorer le déploiement continu, à travers des surveillances automatiques par exemple : détection des anomalies, journalisation et monitoring des logs logiciels. Cela se manifeste également par la configuration de systèmes d’alerte en temps réel, ou encore la veille et la surveillance des vulnérabilités à tous les échelons du déploiement.

La démarche DevSecOps s’appuie enfin sur une collaboration humaine : sa philosophie implique d’utiliser des référents sécurité côté Dev et côté Ops pour affiner la réponse en matière de sécurité tout au long du cycle de vie du projet. Un aspect qui ajoute donc le volet sûreté à la bonne intelligence entre Dev et Ops, au cœur des bonnes pratiques rencontrées aujourd’hui dans nombre de structures.

DevSecOps : concrétisation en entreprise

agap2IT se positionne très largement sur les approches DevOps et DevSecOps. Nos consultantes et consultants, s’acculturent à ces philosophies et proposent à nos clients leurs compétences pour sécuriser l’ensemble des processus de production et d’exploitation des solutions logicielles internes. Finance, industrie, IT… l’esprit DevSecOps se propage ainsi à l’ensemble des secteurs où nos agapiens interviennent !