Si les outils d'AppSec sont la solution miracle, pourquoi tant d'entreprises hésitent-elles à les utiliser ?

Une version de cet article a été publiée dans SC Magazine. Il a été mis à jour et syndiqué ici.

‍

L'un des nombreux dilemmes auxquels sont confrontés les spécialistes de la sécurité aujourd'hui consiste à trouver le juste équilibre entre les solutions utilisées pour gérer les cyberrisques. Comment répartir le budget entre les outils et les ressources humaines ? Quelle suite d'outils sera la plus adaptée à la pile technologique existante ? Face à une telle profusion d'options, il n'existe pas de réponse simple, et faire les mauvais choix coûtera du temps et de l'argent par la suite.

Un rapport récent a révélé que le marché des outils de sécurité applicative est en passe de connaître une croissance « explosive » d'ici 2025, ce qui témoigne de leur rôle incontestable dans la réussite des pratiques DevSecOps et de leur pertinence croissante face à l'augmentation des volumes de code présentant des vulnérabilités potentielles.

Il existe cependant un problème assez curieux. Près de la moitié des organisations déploient sciemment du code vulnérable, malgré l'utilisation d'une gamme d'outils AppSec conçus précisément pour l'empêcher. Pour des produits qui bénéficient d'une demande réelle et d'une adoption rapide, cela semble illogique. Pourquoi tant d'entreprises investissent-elles dans des outils de sécurité sophistiqués pour ensuite ignorer leurs résultats ou ne pas les utiliser du tout ? C'est un peu comme acheter une maison en bord de mer pour finir par dormir dans une tente au milieu des bois.

Il existe plusieurs raisons pour lesquelles les outils de sécurité applicative (AppSec) ne sont pas utilisés comme nous pourrions nous y attendre. Le problème ne réside pas tant dans les outils et leurs fonctionnalités que dans la manière dont ils s'intègrent à l'ensemble du programme de sécurité.

Multiplier les outils ne signifie pas réduire les problèmes.

À mesure que les entreprises font évoluer leurs processus de développement logiciel, passant de l'Agile au DevOps, jusqu'au nirvana qu'est le DevSecOps (pour l'instant, c'est ce que nous avons de mieux), il est inévitable d'accumuler scanners, moniteurs, pare-feux et toutes sortes d'outils AppSec. Bien que l'on puisse penser que « plus on en a, mieux c'est », cela conduit très souvent à une pile technologique qui ressemble au monstre de Frankenstein, avec toute l'imprévisibilité que cela implique.

Avec des budgets et des ressources expertes de plus en plus limités par rapport à l'ampleur du travail requis, tenter de corriger le tir et de définir la meilleure stratégie d'outillage est une tâche ardue, alors que le code nécessitant analyse et remédiation continue d'affluer. Il n'est pas étonnant que de nombreuses organisations continuent de déployer du code malgré tout, bien que cela soit alarmant et constitue toujours un risque immense pour nos données et notre vie privée.

Les outils d'analyse sont lents, ce qui nuit à l'agilité des mises en production.

Atteindre la sécurité à grande vitesse est une sorte de quête impossible dans le développement logiciel. La vérité est que nous essayons encore de trouver la bonne formule, même en incitant les organisations à adopter une approche orientée DevSecOps. Une revue de code manuelle et méticuleuse pouvait servir de garde-fou dans les années 90, mais à une époque où nous produisons des centaines de milliards de lignes de code, c'est une stratégie aussi efficace que de vouloir tondre un terrain de football avec des ciseaux à ongles.

Les outils d'analyse automatisent la détection des problèmes potentiels, effectuant cette revue de code méticuleuse à notre place. Le problème est qu'ils restent lents dans le contexte d'un pipeline CI/CD tournant à plein régime, et qu'aucun outil ne détecte toutes les vulnérabilités. De plus, les résultats fournis à l'équipe de sécurité après une analyse présentent quelques problèmes flagrants :

1. Il y a un grand nombre de faux positifs (et de faux négatifs).
2. Un expert en sécurité doit encore consacrer du temps à une revue manuelle pour distinguer les vrais bugs des bugs fantômes.
3. Bien trop souvent, des vulnérabilités courantes qui auraient dû être détectées avant le déploiement du code sont révélées. Voulez-vous vraiment que vos experts en sécurité, dont le temps est précieux, soient distraits par des détails au lieu de se concentrer sur les problèmes de sécurité majeurs ?
4. Les scanners détectent, ils ne corrigent pas.

Même dans une organisation qui fait tout son possible pour respecter les meilleures pratiques de cybersécurité et intégrer la sécurité à chaque étape du processus, le scénario ci-dessus reste un obstacle majeur si les scanners constituent la principale mesure de protection. Trop de bugs courants finissent par entraver le déploiement de code sécurisé. Il est logique que des raccourcis soient pris, ce qui se traduit généralement par l'utilisation du strict minimum d'outils, incapables de couvrir tous les risques potentiels, même si une suite complète de solutions a été achetée.

Une automatisation trop poussée peut nuire à la qualité du code

L'analyse et les tests constituent le socle des processus automatisés dans l'outillage AppSec, aux côtés d'éléments essentiels comme les pare-feux et la surveillance, mais d'autres outils courants peuvent involontairement éroder les fondements de la sécurité manuelle au fil du temps.

Par exemple, la technologie RASP (Runtime Application Self-Protection) est souvent utilisée pour renforcer la posture de sécurité sans sacrifier la vitesse de développement. Elle opère dans l'environnement d'exécution d'une application, protégeant contre les entrées de code malveillant, les attaques en temps réel, et signalant tout comportement d'exécution inhabituel.

Il s'agit certes d'une couche de protection supplémentaire, mais si elle est perçue comme un garde-fou contre toute faiblesse potentielle du code, les développeurs peuvent devenir complaisants, surtout face à des délais de mise sur le marché de plus en plus intenables pour le lancement de nouvelles fonctionnalités. Les pratiques de codage sécurisé peuvent être délaissées, sous prétexte que l'autoprotection à l'exécution détectera les erreurs. Les développeurs ne cherchent pas à créer des modèles de code non sécurisés, mais la sécurité est souvent reléguée au second plan au profit de la livraison de fonctionnalités, surtout lorsqu'on suppose qu'une protection automatisée est en place.

Les outils peuvent faillir (le RASP, par exemple, fonctionne souvent en mode surveillance pour éviter les faux positifs, ce qui n'offre qu'une visibilité sans protection réelle). Face à cela, seul un code sécurisé de haute qualité est fiable. La sensibilisation à la sécurité pour tous ceux qui manipulent du code est fondamentale au DevSecOps ; laisser les développeurs produire du code non sécurisé par manque de formation est une erreur. Écrire du code sécurisé ne demande pas plus d'efforts que d'en écrire un vulnérable ; c'est l'acquisition des compétences qui demande de l'énergie. Le temps consacré à implémenter et optimiser le RASP serait bien mieux investi dans la montée en compétences des développeurs pour éviter ces erreurs dès le départ.

Équilibrer outils et humains : ce n'est pas une solution miracle, mais c'est ce qui s'en rapproche le plus (pour l'instant).

L'éthique du DevSecOps repose sur une responsabilité partagée en matière de sécurité. Pour les organisations qui conçoivent les logiciels régissant notre quotidien — du réseau électrique aux sonnettes connectées — il est crucial d'impliquer chacun dans cette démarche pour garantir un niveau de sécurité supérieur.

Les outils ne suffisent pas, et ce n'est même pas l'approche la plus économique. Les meilleurs résultats sont obtenus en privilégiant une formation pertinente pour tous ceux qui touchent au code, en maintenant la sécurité au cœur des préoccupations de l'équipe de développement et en instaurant une culture positive axée sur l'humain, où les outils ne jouent qu'un rôle de soutien.

Même face aux contraintes de temps, aux raccourcis et aux autres facteurs qui empêchent les experts en sécurité de dormir, si les développeurs évitent d'introduire des failles courantes dès le départ, ces outils (qu'ils soient utilisés ou non) deviennent un facteur de risque bien moindre.

‍