La place des outils dans l'intégration de la sécurité dans les projets
Lorsque le sujet de l’intégration de la sécurité dans les projets (aka DevSecOps) est abordé, la mise en place d’outils de scan (statique, dynamique, dépendances, etc.) au sein du cycle de développement logiciel (SDLC) apparait très souvent comme la réponse la plus simple.
Les outils, une solution magique ?
Intégrer un outil de sécurité est une opération qui peut sembler rapide, peu couteuse (modulo les éventuels coûts de licence) et et utile pour automatiser une partie de la sécurité des applications sans trop impacter la vélocité des équipes de développement.
L’intégration, de plus en plus fréquente, de l’intelligence artificielle propose également de réduire les taux de faux positifs, prioriser les actions et éventuellement de proposer directement des correctifs aux équipes.
La réalité est-elle aussi simple ?
Choix de l’outil
Avant d’intégrer un outil dans le SDLC, il faut déterminer quel outil est le plus pertinent dans le contexte à adresser. Cette évaluation doit se faire en définissant des critères d’évaluation techniques (technologies, intégration, etc.) et non techniques (coût de licence, support, etc.) en impliquant différentes parties prenantes pouvant avoir des objectifs différents. Une fois cette liste établie, il convient d’évaluer chaque outil candidat en fonction de ces critères afin d’avoir une comparaison la plus objective et pertinente possible.
Pour les outils open source, l’accessibilité des données facilite l’évaluation des critères ainsi que le test de l’outil sur une application de test. Pour les outils commerciaux, il est rare que les sites des éditeurs mettent à disposition de la documentation technique, des informations de prix ou encore une version d’essai permettant d’effectuer des tests. Pour obtenir ces informations il faut prendre contact avec l’équipe commerciale, faire plusieurs réunions, mettre en place un PoC (qui peut être payant), etc. rendant la tâche plus complexe.
Mise en place
Si l’outil n’est pas utilisé en SaaS, une infrastructure doit être provisionnée et durçie avant que l’outil ne soit installé.
Pour garantir un bon fonctionnement, une gouvernance doit être établie pour définir les rôles et responsabilités (RACI) de chaque partie prenante dans le cycle de vie de l’outil. Il faut par exemple définir quelles permissions sont associées à chaque rôle, quelles informations sont accessibles, qui est responsable des mises à jour de l’outil, etc.
Formation
Trouver un outil pertinent pour le périmètre à adresser est une première étape. Il faut maintenant s’assurer que les utilisateurs de cet outil sont prêts. Pour demander aux équipes de développement d’intégrer la sécurité dans les projets il faut valider qu’ils ont les clés nécessaires pour le faire.
Si les collaborateurs amenés à utiliser l’outil au quotidien ne comprennent pas l’intérêt de prendre en compte la sécurité dans les projets, quels sont les potentiels impacts d’un manquement de sécurité ou qu’ils n’ont pas les bases requises pour comprendre la teneur des rapports émis par l’outil, alors l’adoption de ce dernier, aussi performant soit-il, sera un échec (même avec l’aide de l’IA).
Pour favoriser cette intégration, des campagnes de sensibilisation peuvent être mises en place pour expliquer pourquoi il faut prendre en compte la sécurité et démontrer quels peuvent être les impacts de l’exploitation d’une vulnérabilité. Une fois les collaborateurs sensibilisés, des formations spécifiques (développement sécurisé, cloud, etc.) peuvent être mises en place pour fournir les connaissances de base pour intégrer la sécurité au quotien et être en capacité de comprendre les résultats fournis par l’outil.
Configuration et intégration
Au sein d’une même entreprise, chaque projet dispose de spécificités (configuration, périmètre, technologie, version, etc.). Ces éléments peuvent avoir un impact sur la pertinence des résultats remontés (faux positifs par exemple). Une phase d’onboarding sur l’outil permet d’affiner sa configuration puis de réaliser un test sur le projet avant que l’outil soit utilisé au quotidien.
Prise en compte des résultats
La dernière étape consiste à mettre en place des processus nécessaires à la prise en compte des résultats. Si l’outil remonte des problèmes de sécurité pertinents mais qu’ils s’accumulent dans le backlog parce que personne n’a le temps de les traiter, alors l’outil n’a pas d’impact sur l’amélioration du niveau de sécurité de l’application. Pour éviter ces écueils, il convient de définir quand et comment ces tâches doivent être traitées. En complément des points de contrôle de sécurité peuvent être mis en place dans le SDLC pour obliger les équipes à traiter les vulnérabilités avant de continuer à dérouler le processus de livraison.
Conclusion
Derrière la facilité apparente de mise en place d’un outil de sécurité dans le SDLC se cachent une complexité et un coût souvent sous-estimés mais nécessaires pour mener à une plus-value de sécurité.
En intégrant la sécurité dans le SDLC, la mise en place d’outils est un passage obligatoire pour automatiser, industrialiser et passer à l’échelle. Cependant, avant de valider ce choix souvent par défaut, il est conseillé de vérifier que d’autres activités moins lourdes ne sont pas plus pertinentes à prioriser. Cette vision peut être apportée par une analyse de maturité via les modèles DSOMM ou SAMM.
Enfin, la détection des vulnérabilités par les outils reste une forme de réaction à la sécurité ; une vulnérabilité a été introduite puis détectée avant la mise en production. Le principe de Security by Design prône plutôt l’anticipation de la sécurité ; éviter qu’une vulnérabilité soit introduite dans le système.