Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>

Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>
Aller à la section
Il existe de nombreuses façons et techniques pour détecter les vulnérabilités de votre logiciel. L'un des meilleurs moyens est le test de sécurité par analyse statique (SAST). Voici comment vous pouvez déployer SAST dans les tests de sécurité logicielle.
Aller à la section
Aller à la section
Il existe plusieurs techniques pour identifier les vulnérabilités des logiciels et des systèmes. Les organisations intelligentes les gardent dans leur «boîte à outils de sécurité» et utilisent une combinaison d'outils de test, notamment:
La motivation pour améliorer la sécurité grâce à des outils automatisés est de déplacer à gauche dans le cycle de vie du développement logiciel (SDLC) l'identification et la correction des vulnérabilités le plus tôt possible. Les correctifs et les corrections deviennent plus compliqués à mesure que l'application approche de la sortie. La figure 1 montre comment le coût de la correction des vulnérabilités augmente considérablement à mesure que le SDLC progresse.
Pour une couverture approfondie de l'économie de la sécurité logicielle, consultez La valeur commerciale des logiciels sécurisés papier blanc. Cet article se concentre sur l'utilisation des tests de sécurité d'analyse statique dans le cadre des pratiques de sécurité d'une organisation.
Comme son nom l'indique, les tests statiques signifient qu'ils sont appliqués de manière statique. En d'autres termes, l'analyse est effectuée sur le code source, les binaires et/ou les fichiers de configuration. Les outils statiques utilisent leur compréhension de la sémantique de la source pour en déduire les erreurs et les vulnérabilités.
Ces "détecteurs d'erreurs" sont connus sous le nom de vérificateurs ou de règles. Si une règle est violée, un avertissement est émis avec des informations sur l'endroit du code où la violation a eu lieu et généralement des informations de suivi pour rechercher la cause première.
Les tests dynamiques s'appliquent aux applications en cours d'exécution. Ces outils détectent les problèmes d'exécution des applications et effectuent des tests en ajoutant de petits morceaux de code appelés instrumentation pour aider à déterminer la couverture du code et répondre à la question, ai-je fait suffisamment de tests ?
Les erreurs sont signalées au fur et à mesure que l'application s'exécute et fournissent généralement des informations contextuelles afin que les développeurs puissent trouver et corriger les vulnérabilités détectées.
Les principales différences entre les outils de test de sécurité statiques et dynamiques sont les suivantes.
Les outils dynamiques tels que les outils DAST ne peuvent être appliqués qu'aux applications en cours d'exécution et sont donc mis en place plus tard dans le développement. Cependant, avec les pipelines CI/CD modernes, les applications en cours d'exécution sont disponibles plus tôt et plus souvent qu'auparavant, ce qui rend les outils DAST plus utiles.
Les outils dynamiques, d'autre part, peuvent incorporer des frameworks de test pour automatiser la génération de cas de test, le stub, le mocking, tirer parti de l'instrumentation et utiliser des bibliothèques d'exécution spéciales pour détecter les vulnérabilités pendant l'exécution de l'application. Ils incluent également des capacités de capture et de rapport sur ces résultats. Les informations de trace sont généralement incluses, ce qui permet une correction rapide. Étant donné que ces erreurs se produisent réellement dans une application en cours d'exécution, il n'y a généralement pas de faux positifs.
Les outils DAST, quant à eux, détectent les vulnérabilités lors de l'exécution du code. Il y a un haut degré de confiance dans ces résultats. De plus, les conditions d'exécution, telles qu'un comportement multithread compliqué, introduisent de nouveaux types d'erreurs et de vulnérabilités qui manquent aux outils SAST.
Les outils SAST doivent échanger les faux positifs avec des vulnérabilités réelles potentiellement manquantes, appelées faux négatifs, afin de fournir le meilleur retour sur investissement pour la sécurisation du code source. Les faux positifs sont toujours possibles avec l'analyse de l'outil SAST, mais le gain est la détection précoce des vulnérabilités qui pourraient être manquées lors des tests ultérieurs.
Les outils SAST et DAST peuvent manquer de vraies erreurs. Cependant, la meilleure pratique consiste à utiliser les deux outils ensemble pour réduire les erreurs.
Outils SAST ne nécessitent pas d'application en cours d'exécution et peuvent donc être utilisés au début du cycle de vie du développement lorsque les coûts de correction sont faibles. À son niveau le plus élémentaire, SAST fonctionne en analysant le code source et en le comparant à un ensemble de règles. Habituellement associés à l'identification des vulnérabilités, les outils SAST fournissent des alertes précoces aux développeurs concernant des modèles de codage médiocres qui conduisent à des exploits, des violations des politiques de codage sécurisé ou un manque de conformité aux normes d'ingénierie qui conduiront à des fonctionnalités instables ou peu fiables.
Il existe deux principaux types d'analyse utilisés pour identifier les problèmes de sécurité.
Dans l'analyse de flux, les outils analysent le code source pour comprendre le flux de contrôle sous-jacent et le flux de données du code.
Le résultat est une représentation intermédiaire, ou modèle, de l'application. Les outils exécutent des règles (ou vérificateurs) par rapport à ce modèle pour identifier les erreurs de codage qui entraînent des vulnérabilités de sécurité. Par exemple, dans une application C ou C ++, une règle peut identifier des copies de chaîne, puis parcourir le modèle pour déterminer s'il est possible que le tampon source soit plus grand que le tampon de destination. Si tel est le cas, une vulnérabilité de dépassement de mémoire tampon pourrait en résulter.
Éviter certaines constructions de code critiques pour la sécurité est la base des normes modernes d'ingénierie logicielle telles que AUTOSAR C ++ 14, MISRA C 2023 et Combattant d'attaque interarmées (JSF). Ces normes empêchent la possibilité d'une mauvaise interprétation, d'un malentendu ou d'une mise en œuvre incorrecte d'un code non fiable.
L'analyse de modèles aide les développeurs à utiliser un sous-ensemble plus sûr du langage de développement dans le contexte de la sûreté ou de la sécurité, en interdisant l'utilisation de constructions de code qui permettent en premier lieu à des vulnérabilités de se produire. Certaines règles peuvent identifier les erreurs en vérifiant la syntaxe, comme un correcteur orthographique dans un traitement de texte. Certains outils modernes peuvent détecter des modèles subtils associés à une mauvaise construction de codage.
Chaque méthodologie de test a des atouts. De nombreuses organisations se concentrent trop sur le DAST et les tests d'intrusion. Mais il y a plusieurs avantages à utiliser SAST par rapport à d'autres techniques de test.
La quantité de code testée est une métrique critique pour la sécurité logicielle. Les vulnérabilités peuvent être présentes dans n'importe quelle section de la base de code, et les parties non testées peuvent exposer une application aux attaques.
Les outils SAST, en particulier ceux qui utilisent des règles d'analyse de modèle, peuvent fournir une couverture de code beaucoup plus élevée que les techniques dynamiques ou les processus manuels. Ils ont accès au code source de l'application et aux entrées de l'application, y compris celles masquées qui ne sont pas exposées dans l'interface utilisateur.
Les outils SAST favorisent une correction efficace des vulnérabilités. Les tests de sécurité par analyse statique identifient facilement la ligne de code précise qui introduit l'erreur. Les intégrations avec l'IDE des développeurs peuvent accélérer la correction des erreurs détectées par les outils SAST.
Les développeurs reçoivent un retour immédiat sur leur code lorsqu'ils utilisent les outils SAST de l'EDI. Les données les renforcent et les éduquent sur les pratiques de codage sécurisées.
Les développeurs utilisent l'analyse statique au début du cycle de développement, y compris sur des fichiers uniques directement depuis leur IDE. La détection précoce des erreurs dans le SDLC réduit considérablement le coût de la correction. Il empêche les bogues en premier lieu, afin que les développeurs n'aient pas à les trouver et à les corriger plus tard.
SAST est une méthodologie de test complète qui nécessite un effort initial et une motivation pour l'adopter avec succès.
Tandis que les équipes peuvent utiliser les outils SAST au début du SDLC, certaines organisations choisissent de retarder l’analyse jusqu’à la phase de test. Même si l'analyse d'une application plus complète permet une analyse des flux de données inter-procédurales, « décaler vers la gauche » avec SAST et analyser le code directement depuis l'EDI peut identifier des vulnérabilités telles que des erreurs de validation d'entrée. Il permet également aux développeurs d'effectuer des corrections simples avant de soumettre le code pour les builds. Cela permet d’éviter les changements tardifs pour des raisons de sécurité.
L'analyse SAST est mal comprise. De nombreuses équipes pensent que cela prend du temps en raison de son analyse approfondie de l'ensemble du code source du projet. Cela peut amener les organisations à croire que le SAST est incompatible avec les méthodologies de développement rapide, ce qui n'est pas fondé. Les résultats quasi instantanés des tests de sécurité de l'analyse statique sont disponibles dans l'EDI du développeur, fournissant une rétroaction immédiate et garantissant l'évitement des vulnérabilités. Les outils SAST modernes effectuent une analyse incrémentielle pour afficher les résultats uniquement à partir du code qui a changé entre deux versions différentes.
Les outils de test de sécurité d'analyse statique traditionnels incluent souvent de nombreux résultats « informatifs » et des problèmes de faible gravité concernant les normes de codage appropriées. Les outils modernes, comme ceux proposés par Parasoft, permettent aux utilisateurs de sélectionner les règles/vérificateurs à utiliser et de filtrer les résultats en fonction de la gravité de l'erreur, en masquant ceux qui ne justifient pas une enquête.
De nombreuses normes de sécurité de l'OWASP, du CWE, du CERT, etc., ont des modèles de risque qui aident à identifier les vulnérabilités les plus importantes. Votre outil SAST doit utiliser ces informations pour vous aider à vous concentrer sur ce qui compte le plus. Les utilisateurs peuvent filtrer davantage les résultats en fonction d'autres informations contextuelles telles que les métadonnées sur le projet, l'âge du code et le développeur ou l'équipe responsable du code. Des outils comme Parasoft permettent d'utiliser ces informations avec l'intelligence artificielle (IA) et l'apprentissage automatique (ML) pour aider à mieux déterminer les problèmes les plus critiques.
Les déploiements réussis sont souvent axés sur les développeurs. Ils fournissent les outils et les conseils dont les développeurs ont besoin pour intégrer la sécurité dans le logiciel. Ceci est important dans les environnements Agile et DevOps / DevSecOps, où une rétroaction rapide est essentielle pour maintenir la vitesse. Les intégrations IDE permettent des tests de sécurité directement à partir de l'environnement de travail du développeur - au niveau du fichier, au niveau du projet ou simplement pour évaluer le code qui a changé.
Lors de l'analyse des logiciels pour les problèmes de sécurité, une taille unique ne convient pas à toutes les organisations. Il est essentiel que les règles / vérificateurs abordent les problèmes spécifiques critiques pour cette application spécifique. Les organisations qui commencent tout juste à tester la sécurité peuvent souhaiter limiter les règles aux problèmes de sécurité les plus courants tels que les scripts intersites et l'injection SQL. D'autres organisations ont des exigences de sécurité spécifiques basées sur des réglementations telles que PCI DSS. Recherchez des solutions qui permettent une configuration de règle / vérificateur contrôlée qui correspond à vos besoins spécifiques, et non une configuration générique.
Dans le cas des outils de sécurité logicielle, le tout vaut mieux que la somme des parties. Cela est vrai pour les tests de sécurité des applications car les différents outils ont des forces dans différents domaines et des faiblesses qui sont atténuées par la combinaison.
La combinaison de SAST et DAST est un ajustement naturel en raison de la différence fondamentale entre la technologie utilisée dans les outils statiques et les outils dynamiques. Voici quelques-uns des avantages de l'intégration des deux dans vos tests de sécurité.
L'intégration d'outils, en général, peut être difficile. Les outils de différents fournisseurs peuvent ne pas bien fonctionner ensemble et les rapports de chaque outil peuvent entrer en conflit et être dans des formats différents. Cela conduit aux défis suivants.
Il existe un excellent retour sur investissement pour l'intégration de votre boîte à outils de sécurité des applications, donc cette liste ne devrait pas décourager l'effort. Voici quelques bonnes pratiques pour faciliter l'intégration :
En plus des SAST et DAST, il existe d'autres types de tests de sécurité des applications.
Il est important de noter qu'il s'agit de techniques de test de sécurité des applications qui s'intègrent dans un écosystème de techniques de sécurité. Par exemple, les équipes utilisent couramment des outils d'orchestration de la sécurité des applications pour organiser, analyser et générer des rapports sur les informations issues de toutes ces techniques.
Les technologies d'intelligence artificielle (IA) et d'apprentissage automatique (ML) améliorent les solutions d'analyse statique de Parasoft pour identifier les points chauds et les intersections entre toutes les violations trouvées. Cela permet aux équipes de concentrer leurs efforts sur la partie de la base de code qui est à l'origine de nombreux autres problèmes. De plus, ML surveille et apprend du comportement de vos équipes de développement pour différencier ce qui est important de ce qui ne l'est pas.
La formation de votre modèle d'IA sur la base du comportement historique de l'équipe de développement fournit une analyse multidimensionnelle des résultats, tandis que le ML regroupe les données pour identifier les violations corrélées, liées ou similaires.
Combiner les deux technologies, c'est encore mieux. La combinaison apprend quels résultats faux positifs ignorer et quels vrais positifs mettre en évidence. Il réduit une montagne d'informations à quelques diamants de grande valeur.
Par exemple, l'analyse statique peut révéler des milliers de violations dans une base de code typique. Même si vous êtes en mesure d'identifier des centaines de défauts à corriger, vous ne pourrez pas tout réparer dans le laps de temps disponible. Avec l'IA et le ML qui trouvent des points chauds de violation, vous pouvez corriger plusieurs défauts en même temps en identifiant le seul morceau de code qui les cause tous.
Intégrez la sécurité à votre application. C'est beaucoup plus efficace et efficient que d'essayer de sécuriser une application en renforçant la sécurité sur une application finie à la fin du SDLC. Tout comme vous ne pouvez pas tester la qualité dans une application, il en va de même pour la sécurité. SAST est la clé de la détection précoce et empêche les failles de sécurité en écrivant du code sécurisé dès le début.
Les outils SAST permettent aux entreprises d'adopter la sécurité logicielle dès les premières étapes du développement et de fournir à leurs ingénieurs logiciels les outils et les conseils dont ils ont besoin pour créer des logiciels sécurisés.
« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Tous droits réservés.