Les technologies de l’information ont tant investi la sphère professionnelle depuis plusieurs décennies maintenant, à tel point que rares sont les entreprises dont le modèle ne repose pas sur un Système d’Information.
Naturellement, de cet essor des applications, sont nés les domaines du développement et du déploiement applicatifs. Cycle en V, Agile ou DevOps, les méthodes foisonnent pour produire de nouvelles fonctionnalités tout en renforçant les précédentes, avec un time-to-market minimisé. C’est à la dernière méthode citée, plus précisément à sa sécurisation, que sont dédiées les lignes qui suivent.
Le DevOps a pour vocation de fluidifier les échanges entre les équipes de développement (Dev – Development) et d’exploitation (Ops – Operations) pour optimiser la production logicielle : un BUILD moins cher et moins long, un RUN plus stable. Pour atteindre son objectif, il se fonde sur un pipeline d’intégration et de distribution continues (CI/CD – Continuous Integration/Continuous Delivery) dans lequel les tests sont automatisés au maximum, exécutés au plus tôt dans le cycle de vie logiciel (on parle de « décalage vers la gauche » – shift left) et intégrés à des boucles de rétroaction les plus courtes possible.
Pour autant, la promptitude ne peut pas être le seul attribut de la production logicielle. Presser les développements et accélérer la distribution, n’est-ce pas finalement prendre le risque d’introduire des failles dans ses applications ? Trop d’erreurs pour ne pas être fataliste ! Exploitez une librairie vulnérable et votre système de journalisation devient bancal. Introduisez une entrée utilisateur non-assainie et le contenu de votre base de données se fera écraser. Proposez une API permissive, et toutes vos données seront exfiltrées…
D’un autre côté, les tests de sécurité complets sont suffisamment chronophages pour dissuader quiconque d’augmenter leur fréquence. A l’évidence, un compromis s’impose pour produire un logiciel sécurisé et conserver la célérité du DevOps. Ce compromis, c’est l’intégration de la sécurité dans le cycle de vie logiciel.
Cela débute avec le cycle de développement (Dev) et ses quatre phases : conception, développements, compilation et tests. Les analyses de sécurité sont diluées dans ces phases et pour la plupart, automatisées. Elles produisent des alertes immédiatement exploitables par les parties prenantes concernées et ainsi, les vulnérabilités sont identifiées et corrigées à l’instant même où elles ont été introduites. Si les corrections, bien qu’immédiates, ralentissent irréfutablement le cycle de développement, elles contribuent à construire un logiciel à la structure robuste, moins impacté par des incidents de sécurité futurs dont les temps de traitement sont aléatoires.
A titre d’exemple, une analyse de risques pourra précéder toute évolution fonctionnelle substantielle. Les lignes de code développées pourront être soumises aux scanners de code source (SAST – Static Application Security Testing) et les librairies appelées aux scanners de dépendances (SCA – Software Composition Analysis). Les options de sécurité de la forge logicielle pourront être activées. Enfin, des tests d’intrusion pourront être commandités pour attester de l’étanchéité de l’applicatif avant sa mise en production.
L’intégration de la sécurité dans le cycle de vie logiciel se poursuit dans le cycle d’exploitation (Ops), lui aussi constitué de quatre phases : versionnage, déploiement, exploitation et surveillance. Les contrôles de sécurité y sont répartis pour garantir un suivi précis des briques logicielles déployées, une intégration aboutie dans l’environnement d’accueil, un raccordement intégral aux systèmes de surveillance et un traitement systématique des alertes produites. Les incidents de sécurité éventuels sont identifiés au plus tôt, avant qu’ils ne puissent prendre de l’ampleur, faisant gagner un temps précieux dans leur résolution.
En guise d’illustrations, les binaires produits pourront être signés et un inventaire pourra répertorier les artefacts déployés. Une politique de sauvegarde garantira la continuité d’activité et l’interconnexion du système de journalisation à un Centre Opérationnel de Sécurité (SOC – Security Operation Center) et rassurera les exploitants.
En résumé, la démarche DevSecOps (fusion des démarches DevSec et SecOps) possède, d’une part, la capacité d’améliorer la sécurité logicielle tout en concédant une meilleure maîtrise des temps dédiés à la gestion des vulnérabilités et des incidents de sécurité, et, d’autre part, celle de responsabiliser l’ensemble des acteurs du cycle de vie logiciel. En les impliquants dans la détection et la correction des événements de sécurité au fil de l’eau, la démarche DevSecOps se double d’un précepte : la sécurité devient l’affaire de tous.
Toutefois, il ne suffit pas de vouloir pour pouvoir. La mise en œuvre d’une démarche DevSecOps peut mener vers quelques écueils, qu’il est bon de savoir localiser au préalable si l’on souhaite bénéficier pleinement de ses bienfaits.
Tout d’abord, disposer d’un nouvel outil de sécurité ne veut pas dire qu’il pourra s’intégrer efficacement à votre projet. Plusieurs raisons peuvent l'expliquer : déploiement chronophage, inefficacité contextuelle, incompatibilité technologique, impossibilité d'automatiser ses contrôles… Chaque projet possédera un outillage qui lui est propre.
Ensuite, certains outils de sécurité s'avèrent complexes. Complexes à déployer ; une implémentation ardue peut déboucher sur un mauvais paramétrage. Complexes à intégrer ; des branchements compliqués peuvent empêcher d’atteindre leur plein potentiel. Et complexes à exploiter ; un usage fastidieux peut appeler de la résistance au changement.
Ensuite, certains outils de sécurité s'avèrent complexes :
Cela étant, les résultats produits par ces outils doivent être analysés et traités. Certains rapports sont denses, d’autres riches mais parsemés de faux positifs et faux négatifs. Dès lors, faut-il bloquer la mise en production lorsqu’apparaît une vulnérabilité ? A l’opposé, permet-on aux collaborateurs de les ignorer quelle que soit leur criticité ? Un mauvais processus de décision aura alors un impact sur la sécurité de votre logiciel ou sur la durée de son cycle de production.
Pour finir, si le nombre fait bien souvent la force, en cybersécurité le risque zéro n’existe pas. Les failles 0-day – desquelles Microsoft Teams est une récente victime (septembre 2023) – l’illustrent parfaitement, tout comme la notoriété générale des cyber-rescapés de 2023 (Ubisoft, X, TikTok, Toyota…). Ainsi, une profusion d’outils vous protégera mais n’apportera jamais une pleine quiétude.
C’est avertis et conscients des embûches que nous pouvons maintenant bâtir les piliers de la réussite du déploiement d’une démarche DevSecOps.
En premier lieu, face à la nouveauté doit se dresser une conduite du changement assurée, qui accompagnera les équipes de développement et d’exploitation dans leurs nouvelles prérogatives. Elle débute par une sensibilisation globale au DevSecOps, se poursuit par une acculturation progressive au travers de newsletters et café talk cyber par exemple et se termine par la formation des futurs protagonistes de la démarche.
Contre intuitivement, ces protagonistes ne peuvent pas être membres de l’équipe sécurité. En effet, la deuxième clé pour réussir l’intégration de la sécurité dans les projets DevOps est de se baser sur des relais locaux au sein des équipes de développement et d’exploitation, qu’on nommera Security Champions. Ils sont sélectionnés en fonction de leur appétence pour les questions de sécurité, et leur nombre varie avec l’envergure du projet. Forts d’une connaissance intrinsèque du cycle de vie logiciel, ils constituent de précieux atouts pour intégrer au plus juste les outils de sécurité dans les processus existants. Ils assurent enfin l’interface avec l’équipe sécurité qui pilote l’implémentation et apporte son expertise autant que de besoin.
Débute ensuite la sélection des premiers outils de sécurité. Il est recommandé de la baser sur des études de marché (benchmarks) pour identifier les logiciels les mieux adaptés aux spécificités de votre projet. Elle est suivie de phases d’implémentation, pour lesquelles le modèle le plus efficace est celui de l’intégration progressive, qui s’assure d’avoir la visibilité suffisante sur les ressources consommées par un outil avant d’en introduire un nouveau. La démarche DevSecOps s’accompagne donc d’une inertie au déploiement, qui fait à terme sa robustesse.
Enfin, la dernière clé du succès de votre démarche DevSecOps réside dans l’établissement d’indicateurs de performance fiables, indispensables non seulement pour piloter l’avancement de votre programme mais aussi pour offrir de la visibilité aux comités exécutifs et aux éventuels sponsors internes de votre organisation.
En définitif, si la démarche DevSecOps offre, en régime établi, de fortes garanties de sécurité à vos logiciels, s’entourer d’experts est essentiel pour réussir son déploiement, éviter les écueils et échapper au « semblant de sécurité ».
