SAST, DAST et IAST : comparaison des outils de test de sécurité

Test statique de sécurité des applications (SAST)

La méthodologie SAST englobe les outils et les technologies conçus pour vérifier la présence de failles et de vulnérabilités dans le code. Elle constitue une forme de test en boîte blanche – les outils correspondants sont parfois appelés contrôleurs de vulnérabilité – qui recherche les problèmes dans le code.

Un outil SAST peut, par exemple, détecter un code générateur de nombres aléatoires faible, trouver des dépassements de mémoire tampon, repérer des possibilités d’injection SQL, signaler des failles de scripting intersites et identifier divers points sensibles potentiels que des acteurs malveillants pourraient exploiter.

Les équipes de développement utilisent régulièrement les outils SAST pour faire respecter les formats et les normes de programmation établies. Ce processus peut inclure tout ce qui concerne l’indentation (la présence de tabulation ou d’espace dans le code), les conventions de dénomination des variables et tout autre formatage lié à la manière dont les développeurs écrivent le code.

Les outils SAST fonctionnent en analysant le code au repos (aucun humain ou logiciel n’exécute le code). L’outil recherche le code statique ligne par ligne et instruction par instruction, en le comparant à un ensemble de règles établies et d’erreurs connues rassemblées dans une bibliothèque. Des défauts supplémentaires peuvent être pris en charge selon les besoins et greffés au régime de test. Les solutions SAST sont souvent sélectionnées en tenant compte des éléments suivants :

• le ou les langages de développement supportés ;
• la liste des vulnérabilités couvertes par l’outil et la possibilité d’ajouter des critères personnalisés ;
• la précision (nombre de faux positifs) ; et
• la compatibilité de l’outil avec le reste des composants de la chaîne CI.

Des fonctionnalités SAST sont généralement incluses dans les ensembles d’outils de développement, et les éditeurs d’IDE peuvent même les intégrer à leurs plateformes. Les développeurs doivent les invoquer lorsqu’ils écrivent du code. 

Cette méthodologie contribue à l’effort de programmation de l’entreprise et des applications en plaçant les tests de sécurité plus tôt dans le cycle de développement. Les problèmes à ce stade précoce sont souvent le résultat de simples d’erreurs de syntaxe ou d’autres vulnérabilités courantes. Elles peuvent généralement être corrigées facilement et à moindre coût avant la mise en production.

L’approche SAST, cependant, ne concerne que le code statique. La méthode ne peut pas traiter toutes les faiblesses, et elle n’est pas adaptée aux vulnérabilités d’exécution (opérationnelles) ou de configuration telles que l’autorisation et l’authentification appropriées. Par conséquent, les équipes de développement utilisent souvent la méthode SAST en conjonction avec d’autres outils de test de sécurité.

En outre, les faux positifs sont fréquents. Les DevOps perdent du temps à rechercher les fausses alertes. L’outil signale les problèmes possibles ; c’est aux programmeurs de les confirmer, de les valider et de les corriger. Ce travail supplémentaire peut mettre l’équipe DevOps à rude épreuve.

Parmi les solutions SAST, l’on peut énumérer Synopsys de Coverity, HCL AppScan Source, SonarQube, Kiuwan Code Security, AttackFlow et Micro Focus Fortify Static Code Analyzer.

Test dynamique de sécurité des applications (DAST)

L’acronyme DAST représente l’ensemble des outils et des techniques utilisés pour vérifier les vulnérabilités des applications en cours d’exécution, souvent des applications Web. Cette méthode correspond à un type de test en boîte noire. Contrairement au procédé SAST, qui permet de voir la base de code, les outils DAST n’ont aucune connaissance du code sous-jacent. Au contraire, ils sont conçus pour injecter ou alimenter le logiciel en données erronées ou malveillantes.

Les tests DAST sont bien adaptés à la détection des problèmes de configuration et d’authentification des serveurs, ainsi que des failles visibles uniquement lorsqu’un utilisateur se connecte. Par exemple, l’outil peut tenter de faire du cross-site scripting ou d’introduire des données alphanumériques dans des boîtes de dialogue qui attendent des données numériques. L’objectif est d’observer comment le logiciel gère les erreurs.

En fin de compte, la méthode DAST permet de scanner les applications de l’extérieur vers l’intérieur, en examinant un programme en cours d’exécution de la même manière qu’un pirate informatique pourrait chercher des failles exploitables. Bien que le mot « dynamique » dans le nom indique que l’application est en cours d’exécution, cette vérification a lieu dans un environnement de test, et non en production.

Les outils DAST sont essentiellement des simulateurs d’entrée. Ils fournissent des entrées prédéterminées au logiciel contrôlé. Les entrées prédéterminées correspondent à des scénarios de test qu’une organisation conçoit généralement pour émuler des attaques malveillantes sur l’application et comparer le résultat attendu au résultat réel. S’il y a une différence entre ces deux éléments (ou si l’application répond à une entrée alors qu’elle ne devrait pas le faire), le logiciel peut présenter une faille qui nécessite un examen plus approfondi.

Les outils DAST sont extrêmement populaires dans les tests d’applications Web, et les équipes emploient régulièrement la méthode pour injecter des données malveillantes afin de découvrir d’éventuelles failles d’injection. En outre, ils simulent des comportements aléatoires d’utilisateurs pour vérifier des vulnérabilités inattendues. Les équipes choisissent généralement les outils DAST en tenant compte de ce qui suit :

• le niveau d’automatisation de l’outil DAST (sa capacité à automatiser, programmer et exécuter des analyses manuelles à volonté) ;
• l’étendue des vulnérabilités couvertes par l’outil (comme la prise en charge des 10 principales vulnérabilités de l’OWASP) ;
• le degré de personnalisation (configuration de l’outil pour des tests spécifiques ou complexes) ; et
• la compatibilité de l’outil avec les outils existants de CI/CD ou d’autres outils de développement.

Les outils DAST peuvent demander plus de temps et d’expertise en sécurité que les solutions SAST. Étant donné que DAST n’effectue pas de scan au sens classique du terme, ses performances ne peuvent pas être mesurées en ligne par seconde ou autres mesures objectives. Au contraire, l’outil ne peut fournir qu’une entrée ou tenter une action à des moments précis du fonctionnement de l’application. Il faut du temps aux applications pour se charger, s’exécuter et atteindre ces points spécifiques où la pénétration peut avoir lieu.

Les tests DAST peuvent donc prendre plus de temps. Et comme le test DAST nécessite une solide connaissance de l’application et de ses mécanismes (pour configurer et administrer les conditions de test), une utilisation efficace du test DAST repose souvent sur des développeurs ayant une expertise approfondie en la matière.

Investir dans des outils DAST paraît pertinent. Comme ils ne se préoccupent pas du code sous-jacent, ils sont potentiellement agnostiques de la plateforme de développement et peuvent en principe fonctionner avec toutes les applications. Cette méthode de test externe est idéale pour trouver les erreurs de configuration et les oublis faciles à manquer. Alors que les outils SAST peuvent produire un grand nombre de faux positifs, les solutions DAST sont beaucoup moins sensibles à ce phénomène.

En effet, les tests et les critères de test sont conçus pour se concentrer sur des vulnérabilités réelles et identifiables. Par exemple, si une application connecte un utilisateur avec des informations d’identification vierges ou incorrectes, il ne fait aucun doute qu’il s’agit d’une faille de sécurité.

Mais ces instruments DAST souffrent également de quelques limitations notables. Ils demandent un effort manuel important pour écrire et gérer les conditions de test. Cela implique un investissement humain, et donc financier, pour maintenir à jour le niveau d’efficacité des tests. Le temps est encore un problème avec cette approche ; le nombre de cas de test et la vitesse à laquelle une application peut s’exécuter signifient que des analyses complètes peuvent prendre des jours. Enfin, les résultats ne sont pas liés au code, mais plutôt aux conditions et aux procédures de comparaisons. Par conséquent, les développeurs doivent examiner et identifier les causes sous-jacentes des défauts signalés.

Quelques solutions DAST populaires : le logiciel libre ZAP, qui est construit sur ZAP et est bien adapté aux flux de travail CI/CD ; Detectify ; Netsparker ; InsightAppSec de Rapid7 ; et une plateforme de sécurité des applications d’entreprise de Veracode.

Test interactif de sécurité des applications

Les tests IAST combinent certaines des meilleures caractéristiques des tests SAST et DAST. Leur objectif est de permettre des vérifications à partir de l’application elle-même, souvent pendant son développement. Lorsqu’il est correctement configuré, un outil IAST peut :

• accéder à l’ensemble du code de l’application ;
• recueillir des informations sur le contrôle et le flux de données au moment de l’exécution ;
• accéder aux informations de configuration
• surveiller le trafic Web (HTTP) ; et
• accéder aux composants de l’application, y compris les bibliothèques, les frameworks et les données dans les dépendances back-end.

En fait, la méthode IAST offre une vue complète d’une application et de son environnement, ce qui permet de traiter davantage de code, d’offrir des résultats plus fiables et d’identifier plus de failles de sécurité que les méthodes SAST ou DAST.

Les agents logiciels IAST analysent le fonctionnement d’une application, recherchent les vulnérabilités, contrôlent les exécutions et transmettent les problèmes détectés directement à un outil de suivi. Comme une équipe peut employer ces agents à n’importe quel moment, les tests interactifs sont utilisables tout au long du développement.

Cela peut commencer dans l’IDE au cours de la programmation pour vérifier la base de code, se poursuivre dans les tests et la validation du logiciel pour rendre compte des performances et des failles et se prolonger une fois que la build est déployée en production pour une surveillance continue de la sécurité. L’équipe de développement doit choisir les outils IAST après avoir soigneusement étudié :

• les langages de programmation utilisés par l’équipe (si le logiciel IAST analyse le code, il doit comprendre le langage) ;
• l’étendue des vulnérabilités de code et opérationnelles que l’outil couvre (et la possibilité d’ajouter des critères personnalisés) ;
• son impact sur les performances (il fonctionne souvent en arrière-plan) et le faible taux de faux positifs ;
• prise en charge des principales normes de conformité et de sécurité (telles que PCI DSS, RGPD, SANS/CWE, etc.) ; et
• la facilité de déploiement et d’intégration avec les flux de développement existants et les ensembles d’outils CI/CD.

Les outils IAST peuvent être profitables aux développeurs qui écrivent le code, aux testeurs qui valident les builds et même au personnel des opérations qui déploie le build. Les fournisseurs mettent l’accent sur la facilité d’installation et d’utilisation. Malgré cela, il est essentiel d’avoir quelques connaissances en matière de sécurité, que ce soit pour comprendre les résultats ou pour suivre les tickets d’incident qui en découlent, afin d’apporter des corrections rapides et efficaces.

Comme les offres SAST, les outils IAST peuvent analyser le code. Cela permet aux technologies IAST de prendre en charge la découverte et la correction précoces des problèmes de programmation, dont la plupart peuvent être rectifiés par les développeurs à moindre coût et dans les meilleurs délais.

Ce qui est peut-être encore plus convaincant, c’est que les solutions IAST peuvent identifier les soucis opérationnels de manière plus précise que les outils DAST puisqu’ils ont à la fois une vue sur le code et les processus du logiciel. Dès lors, les rapports corrèlent failles et opérations spécifiques au niveau du code. Cela doit accélérer la localisation et la correction des problèmes.

Toutefois, l’utilisation d’agents et l’instrumentation qu’elle implique peuvent provoquer des conflits entre les équipes SecOps et DevOps. Bien que généralement petits et souvent inoffensifs, ces segments de code liés au IAST peuvent potentiellement affecter le fonctionnement d’une application et réduire les performances. Ce problème est bien connu.

Parmi les outils IAST, l’on peut citer Acunetix, Checkmarx CxSAST, Veracode et Seeker de Synopsys.