Les organisations doivent développer des applications de manière rapide et agile. La sécurité est essentielle, mais les longues vérifications manuelles de la sécurité constituent un goulot d’étranglement inacceptable. Les solutions de test de sécurité des applications telles que Fortify résolvent ce problème en automatisant le processus d’examen de la sécurité.
Une fois les tests de sécurité automatisés, un deuxième goulot d’étranglement apparaît : les humains doivent toujours examiner les résultats des tests et agir en conséquence. Le code source doit être modifié pour remédier aux problèmes de sécurité. Idéalement, cette tâche devrait également être automatisée. Cette idée s’appelle correction automatique et est actuellement un sujet brûlant dans l’industrie AppSec.
Fortify dispose d’une solution de remédiation automatique. Le Plugin Fortify Security Assistant pour IntelliJ effectue une correction automatique très fiable pour 13 catégories de vulnérabilités importantes et est disponible pour tous les clients Fortify SAST. Cependant, l’auto-remédiation n’est pas une simple panacée et comporte de nombreux pièges potentiels, même avec la technologie de pointe actuelle. Dans ce blog, nous expliquons pourquoi.
Le cas spécifique de l’injection SQL
Injection SQL est sans doute la catégorie de vulnérabilité AppSec la plus célèbre et est au centre de l’attention depuis le début du siècle. Les failles d’injection SQL sont généralement causées par la création d’une instruction SQL en concaténant des parties fixes et des entrées utilisateur. La meilleure façon d’empêcher l’injection SQL est de remplacer la concaténation par une « instruction préparée ». Les entrées de l’utilisateur seront alors traitées comme des paramètres, rendant l’injection SQL impossible.
L’assistant de sécurité de Fortify peut effectuer cette réécriture, corrigeant ainsi automatiquement une vulnérabilité d’injection SQL. D’autres fournisseurs dans le domaine de la correction automatique peuvent également le faire. Si vous recherchez leurs vidéos de démonstration, il semble que tout le monde aime faire une démonstration de ce cas particulier !
Pourquoi serait-ce le cas ? Est-ce uniquement à cause de la renommée de la catégorie ? Non. Il y a quelques autres raisons pour lesquelles nous aimons tous faire une démonstration de celle-ci pour la correction automatique :
- Il existe un consensus sur la stratégie de remédiation basée sur les meilleures pratiques (déclarations préparées).
- Cette stratégie de remédiation fonctionne presque toujours.
- La correction nécessite une quantité non négligeable de modifications, montrant la valeur de la correction automatique.
- Le processus de remédiation peut facilement s’exprimer par une série d’opérations structurelles sur le code source. Il n’a pas besoin d’une véritable IA. (Bien que cela puisse être commercialisé comme ça, bien sûr.)
Il n’y a rien de mal à choisir un joli cas de démonstration pour illustrer ce qu’un outil peut faire. Cependant, cela soulève la question de savoir dans quelle mesure ce cas est représentatif des vulnérabilités en général.
Il existe certainement certaines catégories qui ressemblent à l’injection SQL dans les aspects mentionnés ci-dessus. Par exemple, Extension d’entité XML causé par un analyseur XML configuré de manière non sécurisée doit être corrigé en définissant les fonctionnalités de l’analyseur. Encore une fois, c’est un excellent argument en faveur de la remédiation automatique. Mais regardons-en quelques autres.
Quand la remédiation automatique échoue
Examinons quelques catégories de vulnérabilités qui posent problème pour la correction automatique.
Scripts intersites
La plupart des frameworks Web modernes empêchent Scripts intersites (XSS) par défaut. Le contenu est échappé pendant le rendu ; par exemple, «
Un outil AppSec peut facilement détecter que ce fichier est utilisé, et un outil de correction automatique peut facilement le rétablir en une version sécurisée. Cela fera une belle démo, mais est-ce utile ?
Probablement pas. Le développeur qui a tapé « dangerouslySetInnerHTML » avait presque certainement une raison de le faire. D'une manière ou d'une autre, la fonctionnalité de la page Web nécessite que le contenu contenant du HTML soit rendu à ce stade. Est-ce une bonne idée ? Est-ce sécuritaire? Tout dépend. Un cas comme celui-ci nécessite un examen attentif et, en cas de problème de sécurité, une solution spécifique. Changer aveuglément cela en quelque chose qu'un outil AppSec considère comme sécurisé ne fera probablement que casser l'application.
Cryptographie faible
De nombreux anciens algorithmes cryptographiques ne sont plus considérés comme sécurisés. Par exemple, les hachages MD5 ne sont pas sécurisés et devraient probablement être remplacés par des hachages SHA-2, et AES devrait remplacer le chiffrement symétrique DES.
Étant donné que l’algorithme à utiliser est généralement un paramètre d’une API cryptographique générique, il est facile de détecter les algorithmes cryptographiques faibles et de corriger automatiquement le résultat en les remplaçant par une alternative sécurisée. Mais encore une fois : est-ce que cela a de la valeur ?
Cela fonctionnerait dans de rares cas (par exemple, une application cryptant des données éphémères pour son propre usage, par exemple dans un cookie de session). Même dans ce cas, le temps gagné par rapport à la correction manuelle est bien entendu minime.
Dans la plupart des cas, cela ne sert à rien. La cryptographie est normalement utilisée sur des données persistantes et/ou partagées. Changer un algorithme de cryptographie en un seul endroit sans tenir compte de la migration des données ni des effets sur 3rd les fêtes ne marchent pas. Un outil de remédiation automatique ne fera jamais le gros du travail ici.
Secrets codés en dur
Les secrets (clés, mots de passe) stockés directement dans le code source constituent un problème de sécurité courant. Les outils AppSec peuvent les détecter. La remédiation automatique est-elle utile dans ce cas ?
Bien entendu, il n’est pas difficile pour un algorithme de correction automatique de supprimer le secret du code source. Mais cela seul ne fera que casser l’application. Il doit être remplacé par un moyen sécurisé pour obtenir les secrets.
Malheureusement, aucune approche unique ne fonctionne toujours. Obtenir un secret à partir d'une variable d'environnement (comme suggéré par le Application à douze facteurs) est idéal pour un microservice fonctionnant sur Kubernetes, mais c'est un conseil horrible si le secret est un mot de passe et que l'application s'exécute sur un PC. De nombreuses organisations disposent de politiques ou de systèmes spécifiques pour stocker les secrets ; la remédiation devrait suivre cela. Mais l’outil de correction automatique ne le saura pas.
Il y a un autre problème : même lorsque nous supprimons le secret du code source, le secret d'origine est compromis (et toujours présent dans l'historique du référentiel). Une véritable remédiation nécessite un effort supplémentaire : modifier le secret sur les systèmes concernés.
La valeur de la correction automatique des secrets codés en dur est extrêmement limitée.
Et bien d’autres…
Ci-dessus, nous avons couvert trois cas de manière assez détaillée, mais il existe de nombreuses autres catégories pour lesquelles la correction automatique a peu à offrir. Tout ce qui doit être corrigé par la validation des entrées est problématique, à la fois parce qu'il existe de nombreuses architectures différentes pour implémenter la validation et parce que la liste verte correcte ne sera pas connue par l'outil. Cela devient un problème lors de la résolution de problèmes tels que la redirection ouverte et la traversée du chemin.
En réalité, même l’injection SQL pose problème. La plupart des développeurs connaissent les instructions préparées. Mais ils ont certaines limites. Par exemple, le nom d'une table SQL ne peut pas être un paramètre d'instruction préparée. Si les développeurs créent une instruction SQL par concaténation, c'est souvent parce qu'ils sont confrontés à un cas comme celui-ci.
Comment réduire le retard en matière de sécurité
La correction automatique est une technologie importante qui aide les praticiens à agir rapidement sur les résultats des tests AppSec. Cependant, comme démontré ci-dessus, sa portée, ou le pourcentage de cas où elle fonctionnera réellement, est intrinsèquement limitée. Il ne s’agit donc pas d’une solution miracle pour éliminer le goulot d’étranglement humain et réduire le retard en matière de sécurité.
À quoi ressemblerait un outil idéal pour réduire le retard en matière de sécurité ? Décrivons quelques principes clés.
Combiner audit et remédiation
Les outils AppSec produisent toujours une certaine quantité de bruit, également appelé « faux positifs ». Ces résultats ne nécessitent pas de correction associée, nous ne devrions donc jamais corriger automatiquement tous les résultats d'un outil AppSec. Premièrement, nous devons faire audit pour déterminer si les résultats sont exacts. Si nous accélérons les mesures correctives tout en continuant l'audit tel quel, nous serons toujours confrontés à un goulot d'étranglement majeur dans notre processus, nous devrons donc également accélérer cela.
Notez que les tâches d’audit et de remédiation se chevauchent considérablement. Dans les deux cas, nous devons acquérir une compréhension approfondie de ce qui se passe dans l’application au-delà des données et des descriptions standard produites par l’outil AppSec. Si nous avons effectué ce travail pour l’audit, il devrait être intégré au processus de remédiation afin d’éviter un double travail.
Ainsi, pour de multiples raisons, il est logique d’envisager simultanément l’audit et la remédiation.
Soutenir le développeur
Nous avons vu que l’automatisation complète ne fonctionne que dans quelques cas. Dans la plupart des cas, nous avons toujours besoin du développeur. Cela signifie que notre objectif doit être de rendre le travail du développeur aussi simple que possible.
Les outils AppSec puissants fournissent de nombreuses informations utiles, notamment des descriptions de vulnérabilités et des diagrammes de flux, tous liés au code source, combinés à des conseils de remédiation (génériques). Néanmoins, comprendre cela et tirer les bonnes conclusions représente beaucoup de travail, même pour un expert.
Grâce à l’IA générative, nous facilitons grandement cette tâche. L'IA générative peut prendre en compte les preuves recueillies par un outil AppSec, ainsi que le code source réel, puis annoter les résultats de l'outil avec son analyse. Agissant en tant que compagnon du développeur, il rend les résultats de l'outil beaucoup plus faciles à digérer.
S’il existe une solution évidente pour résoudre le problème, l’IA peut l’ajouter aux résultats. Mais si nous avons affaire à l'un de ces cas où ce n'est pas évident, l'IA peut toujours fournir des suggestions sur la manière d'effectuer une remédiation – ce qui est difficile à imaginer lorsqu'on effectue une remédiation automatique directement sur le code source.
Même dans les cas où la correction automatique est une option, garder le développeur engagé est une bonne chose. La participation active et l’appropriation du changement amélioreront leurs compétences et réduiront la probabilité que ce problème se reproduise.
Entrez Fortify Aviator
Nous avons récemment lancé Fortifier l'aviateurun nouvel outil d'audit et de remédiation qui suit les principes qui viennent d'être décrits.
Alimenté par un grand modèle de langage avancé (LLM), Fortify Aviator peut véritablement raisonner sur les résultats produits par Fortify SAST. Il effectue d'abord un audit, déterminant si le problème doit être résolu ou non (en supprimant ce dernier). Il ajoute également un commentaire au problème expliquant sa décision. Si le problème doit être résolu, des conseils de remédiation sont également inclus dans ce commentaire. Il est concret et prêt à copier-coller lorsque cela est possible ; il est plus directionnel en cas de besoin.
Les informations ajoutées par Fortify Aviator augmentent considérablement la productivité des développeurs. Et comme les informations sont ajoutées au problème lui-même, elles sont disponibles partout : l'interface Web Fortify, les IDE, Audit Workbench, les tickets de suivi des problèmes générés, les rapports générés, etc. Tout flux de travail de développeur est pris en charge.
La correction automatique est utile dans certains cas et nous continuerons à la prendre en charge. Cependant, nous pensons que c'est l'approche Fortify Aviator qui permettra à nos clients de réduire l'intégralité de leur retard.
Le poste Auto-remédiation : l’avenir de l’AppSec ? est apparu en premier sur Blogues OpenText.
Source link