Accélérer l’analyse SAST
trait de séparation
Temps de lecture : 8 min
Pourquoi est-il important d’équilibrer le ratio entre les résultats obtenus et les ressources nécessaires pour les Tests de Sécurité des Applications ?
Cet article explique comment accélérer l’analyse SAST (Static Application Security Testing ) et pourquoi cela est important. Comme généralement les outils SAST sont intégrés dans le flux de travail des développeurs, leurs performances ont un impact direct plus ou moins important sur le coût global du développement et donc leur ROI (Return On Investment). Les outils SAST doivent être suffisamment rapides pour ne pas dégrader sensiblement l'efficacité du flux de travail, mais ils doivent également donner des résultats exploitables.
Les exemples donnés ci-dessous proviennent de la solution GrammaTech CodeSonar, mais les conseils fournis ici sont génériques.
Les exemples donnés ci-dessous proviennent de la solution GrammaTech CodeSonar, mais les conseils fournis ici sont génériques.
Au sommaire :
- Intégration d’outils SAST dans le workflow DevSecOps
- Étapes pour accélérer l’analyse SAST :
- Analyse incrémentale
- Analyse de composants
- Analyse niveau des développeurs
- Par où commencer ?
Intégration d’outils SAST dans le workflow DevSecOps
L'accent est mis ici sur l'intégration des solutions SAST dans DevSecOps, l'intégration entre le développement, la sécurité et les opérations/déploiement au sein du SDLC (Software Development Life Cycle), en particulier sous une certaine forme de processus CI/CD (intégration continue/déploiement continu). Dans ces processus modernes et continus, un fois que du code est écrit et avant qu'il ne soit validé dans le référentiel, il doit être testé. Ces test peuvent être des tests unitaires, des tests de régression ou des tests statiques de sécurité des applications.
L'objectif de cet article est de passer en revue les techniques permettant de réduire l'impact des solutions SAST dans ce processus. Certes, l'optimisation des aspects de test va de pair. Dans ce contexte, réduire le temps d'analyse signifie réduire le temps de développement du produit.
L'avantage des outils SAST et pourquoi il s'intègre si bien avec DevSecOps est leur capacité à donner un retour (résultat) quasi-temps réel lorsque les développeurs créent et apportent des modifications au code source avant de le soumettre dans le référentiel. La durée acceptable dans ce type de flux de travail est de 15 à 30 minutes maximum, en tenant compte de l'ampleur des changements apportés au code. L’analyse Une analyse SAST exécutée dans un court laps de temps est donc un critères très important. Des résultats rapides signifient une rotation plus rapide et plus de progrès sur les fonctionnalités du produit. Et ce sont ces fonctionnalités qui donnent la valeur commerciale du produit. Les tests, quant à eux, permettent justement de s'assurer que ces fonctionnalités fonctionnent correctement.
L'objectif de cet article est de passer en revue les techniques permettant de réduire l'impact des solutions SAST dans ce processus. Certes, l'optimisation des aspects de test va de pair. Dans ce contexte, réduire le temps d'analyse signifie réduire le temps de développement du produit.
L'avantage des outils SAST et pourquoi il s'intègre si bien avec DevSecOps est leur capacité à donner un retour (résultat) quasi-temps réel lorsque les développeurs créent et apportent des modifications au code source avant de le soumettre dans le référentiel. La durée acceptable dans ce type de flux de travail est de 15 à 30 minutes maximum, en tenant compte de l'ampleur des changements apportés au code. L’analyse Une analyse SAST exécutée dans un court laps de temps est donc un critères très important. Des résultats rapides signifient une rotation plus rapide et plus de progrès sur les fonctionnalités du produit. Et ce sont ces fonctionnalités qui donnent la valeur commerciale du produit. Les tests, quant à eux, permettent justement de s'assurer que ces fonctionnalités fonctionnent correctement.
Profondeur contre largeur
Les checkers (vérificateurs) utilisés par les outils SAST ne sont pas égaux, du moins en termes de puissance de calcul nécessaire. Le temps d'analyse est directement lié à la complexité des checkers utilisés pour détecter certains types de vulnérabilités et de défauts. En règle générale, les vérifications de standards de règles de codage sont plus faciles à réaliser que, par exemple, l'analyse complexe du flux de données (Tainted data) utilisée pour détecter des injections de commandes ou SQL. Par conséquent, des compromis sont faits dans les types de bugs et de vulnérabilités à rechercher. Lorsque les développeurs sont dans la phase de codage, il est logique de vouloir optimiser le temps de calcul pour les analyses SAST afin de réduire au maximum le temps de codage. Par contre lors des Builds, plus de temps et de puissance de calcul sont disponibles, de sorte que la profondeur et l'étendue des analyses peuvent être augmentées pour détecter des vulnérabilités plus complexes.
Puissance de calcul
Le temps d'analyse des outils SAST s'adapte très bien à la puissance de calcul disponible de la machine hôte. Néanmoins, la disponibilité de davantage de ressources, telles que le processeur et la mémoire, peut avoir un impact direct sur le temps d'analyse. Dans ce cas « plus c'est gros, plus c’est performant » et investir dans des machines supplémentaires plus performantes pour exécuter les analyses SAST peut être très rentable en termes de productivité.
Taille du code
Le temps d'analyse d’un outil SAST dépend également de la quantité de code source à analyser. En fonction de votre application, votre base de code est un facteur déterminant la profondeur et l'étendue de l'analyse optimale.
Il existe une certaine corrélation entre la taille réduite d’un code et les exigences strictes qu’imposent le test de logiciels critiques sécuritaires sur les analyses SAST. Il est coûteux de développer et de tester un code critique. Cependant, ces applications critiques doivent être conformes aux normes de codage industrielles et à des niveaux rigoureux de tests et d'analyses. Les outils SAST sont donc nécessaires dans ces cas et une analyse approfondie est obligatoire pour couvrir entièrement les défauts et vulnérabilités potentielles. De plus, un large éventail d'analyses est nécessaire non seulement pour vérifier la conformité aux standards de règles de codage, mais également pour tester une large variété de défauts.
Des codes d’une taille importante voir très importante nécessitent un compromis en termes de profondeur et d'étendue de l'analyse. Il est donc essentiel de hiérarchiser les types de défauts et de vulnérabilités sur lesquels on souhaite se concentrer.
Il y a trois leviers qui influent sur les choix à faire pour réduire le temps global d'analyse : deux jouent la profondeur et l'ampleur de l’analyse, ce qui contrôle la quantité de travail ; et le troisième est la puissance de calcul disponible.
Il existe une certaine corrélation entre la taille réduite d’un code et les exigences strictes qu’imposent le test de logiciels critiques sécuritaires sur les analyses SAST. Il est coûteux de développer et de tester un code critique. Cependant, ces applications critiques doivent être conformes aux normes de codage industrielles et à des niveaux rigoureux de tests et d'analyses. Les outils SAST sont donc nécessaires dans ces cas et une analyse approfondie est obligatoire pour couvrir entièrement les défauts et vulnérabilités potentielles. De plus, un large éventail d'analyses est nécessaire non seulement pour vérifier la conformité aux standards de règles de codage, mais également pour tester une large variété de défauts.
Des codes d’une taille importante voir très importante nécessitent un compromis en termes de profondeur et d'étendue de l'analyse. Il est donc essentiel de hiérarchiser les types de défauts et de vulnérabilités sur lesquels on souhaite se concentrer.
Il y a trois leviers qui influent sur les choix à faire pour réduire le temps global d'analyse : deux jouent la profondeur et l'ampleur de l’analyse, ce qui contrôle la quantité de travail ; et le troisième est la puissance de calcul disponible.
Dans cet article, GrammaTech suppose que les ressources informatiques sont fixes et l'accent est mis sur la réduction de la quantité de travail d’analyse.
Comment puis-je réduire le travail de l'outil SAST et obtenir des résultats plus rapidement ?
Comment puis-je réduire le travail de l'outil SAST et obtenir des résultats plus rapidement ?
Étapes pour accélérer l’analyse SAST
Accélérer l’analyse SAST signifie réduire la quantité de travail effectué par l’outil. L'opération la plus intensive est une analyse complète, et par complète, cela signifie d’analyser le code source dans sa globalité après intégration de tous ces modules. Tout comme la compilation complète à partir de zéro prend beaucoup de temps, il en va de même pour l'analyse SAST. C'est le temps d'analyse maximum et le maximum à attendre de vos outils SAST.
Pour réduire ce temps, d'autres approches sont nécessaires, et elles suivent les mêmes techniques utilisées pour optimiser les compilations dans les grands projets C/C++. La première est l'analyse incrémentale. Ensuite, avec des architectures logicielles basées sur des composants bien définis et faiblement couplés, il est possible de faire une analyse de composants. Ensuite, la dernière étape pour accélérer l’analyse SAST est l'analyse au niveau du développeur.
Pour réduire ce temps, d'autres approches sont nécessaires, et elles suivent les mêmes techniques utilisées pour optimiser les compilations dans les grands projets C/C++. La première est l'analyse incrémentale. Ensuite, avec des architectures logicielles basées sur des composants bien définis et faiblement couplés, il est possible de faire une analyse de composants. Ensuite, la dernière étape pour accélérer l’analyse SAST est l'analyse au niveau du développeur.
Analyse Incrémentale
Les builds incrémentiels sont un facteur majeur dans la réduction des temps de builds des développeurs pour les projets C et C++. De petits changements ne nécessitent pas la recompilation de toute la totalité du code. C'est peu pratique et inutile. Lorsqu'un développeur modifie quelque chose, ce qui doit être recompilé l’est fait automatiquement et ce par l'infrastructure de gestion du projet.
Les outils SAST fonctionnent de manière similaire. Au fur et à mesure que le code source est compilé, l'outil SAST analyse le même code source et crée un modèle du programme. La phase suivante consiste à analyser ce modèle du programme par rapport aux vérificateurs configurés et à générer des alertes (warnings) en cas de défauts détectés. Ces warnings sont généralement stockés dans une base de données pour une analyse ultérieure et peuvent être transmis à des outils de développement supplémentaires pour examen.
Les outils SAST fonctionnent de manière similaire. Au fur et à mesure que le code source est compilé, l'outil SAST analyse le même code source et crée un modèle du programme. La phase suivante consiste à analyser ce modèle du programme par rapport aux vérificateurs configurés et à générer des alertes (warnings) en cas de défauts détectés. Ces warnings sont généralement stockés dans une base de données pour une analyse ultérieure et peuvent être transmis à des outils de développement supplémentaires pour examen.
Les outils SAST effectuent une analyse similaire à un compilateur, mais doivent effectuer une analyse supplémentaire sur le modèle de programme créé lors de la génération.
Lors de la construction du logiciel, l'outil SAST est exécuté en parallèle. Bien que similaire à un compilateur en fonctionnement, les outils SAST doivent effectuer plus de travail qu’un compilateur, donc prennent plus de temps pour terminer et fournir des résultats. La quantité de code nécessaire à recompiler pour chaque modification a un impact direct sur le temps d'analyse.
Le travail d'analyse d'une version incrémentielle représente beaucoup plus de travail que la simple analyse des modifications. Les outils SAST effectuent une analyse via une exécution abstraite du flux de code via plusieurs unités de compilation différentes. Ainsi, même si un seul fichier est modifié, les appels qu'il effectue vers d'autres fichiers doivent également être analysés. L'analyse incrémentielle n'augmente pas la charge de travail de génération et d'analyse, mais la portée de l'analyse sera beaucoup plus importante que prévu. Ainsi, chaque fois que vous effectuez une construction incrémentielle, un outil SAST devra réanalyser les dépendances et les modifications, ainsi que les éléments associés autour de ces unités modifiées.
Le travail d'analyse d'une version incrémentielle représente beaucoup plus de travail que la simple analyse des modifications. Les outils SAST effectuent une analyse via une exécution abstraite du flux de code via plusieurs unités de compilation différentes. Ainsi, même si un seul fichier est modifié, les appels qu'il effectue vers d'autres fichiers doivent également être analysés. L'analyse incrémentielle n'augmente pas la charge de travail de génération et d'analyse, mais la portée de l'analyse sera beaucoup plus importante que prévu. Ainsi, chaque fois que vous effectuez une construction incrémentielle, un outil SAST devra réanalyser les dépendances et les modifications, ainsi que les éléments associés autour de ces unités modifiées.
L'analyse incrémentielle effectue une analyse uniquement sur les unités modifiées et les dépendances associées.
L'analyse incrémentale est donc un excellent moyen de réduire la quantité de travail, mais elle peut avoir des conséquences imprévues en ce qui concerne le temps d'analyse par la suite. Cependant, cela reste une bonne option pour réduire les temps d'analyse SAST. C'est également une option facile à adopter puisque cette capacité d’analyse incrémentale est intégrée aux outils SAST comme CodeSonar.
Analyse des composants
L'analyse des composants dépend de l’architecture de l’application. Si l’architecture de votre logiciel est basée sur une approche de décomposition par composants faiblement couplés et avec des interfaces bien définies, il est possible d'isoler à la fois les tests et l'analyse SAST d’un composant où les modifications sont apportées. Tout comme ce type d'architecture simplifie de nombreux aspects du développement, il est également payant avec l’activité SAST. Il est possible d'analyser le composant de manière isolée et d'obtenir des résultats très pertinents.
Analyse niveau des développeurs
Il est toujours possible de réduire davantage la charge de travail d'analyse, même si vous développez un logiciel avec une architecture bien définie basée sur des composants. Le concept est de démarrer le build sans faire d’analyse SAST, ce qui supprime la charge du calcul supplémentaire nécessaire. L’intérêt est que le build concerné sera disponible rapidement.
Contrairement à l'analyse incrémentielle, la première génération complète de l’application est effectuée sans faire d’analyse SAST, mais les générations suivantes le sont, de sorte que le modèle du programme qui sera créé sera beaucoup plus petit et la vitesse de génération sera beaucoup plus rapide.
Cependant, il y a une augmentation des faux négatifs en raison du périmètre d'analyse réduit puisque seuls les fichiers qui ont changé sont analysés. Cette portée plus petite signifie que toutes les dépendances possibles sont en dehors du modèle de programme et ne sont pas prises en compte dans l'analyse. Cependant, cette analyse rapide fonctionne bien avec l'application des normes de codage, par exemple.
Contrairement à l'analyse incrémentielle, la première génération complète de l’application est effectuée sans faire d’analyse SAST, mais les générations suivantes le sont, de sorte que le modèle du programme qui sera créé sera beaucoup plus petit et la vitesse de génération sera beaucoup plus rapide.
Cependant, il y a une augmentation des faux négatifs en raison du périmètre d'analyse réduit puisque seuls les fichiers qui ont changé sont analysés. Cette portée plus petite signifie que toutes les dépendances possibles sont en dehors du modèle de programme et ne sont pas prises en compte dans l'analyse. Cependant, cette analyse rapide fonctionne bien avec l'application des normes de codage, par exemple.
Par où commencer ?
Après avoir décrit les concepts pour optimiser la charge de travail et le temps des analyse SAST, la question suivante est par où commencer ?
Tout d'abord, commencez par un build et une analyse complète. Cela définit à la fois une référence en termes de défauts et de vulnérabilités détectés, mais cela permet également de fixer un objectif de performances à accroitre pour réduire le temps de développement. Cette étape déterminera le nombre exact de lignes de code que comporte votre application, la durée de l'analyse et son impact sur la charge du serveur de build. Ces métriques serviront à guider l'effort d'optimisation de l'analyse.
Compte tenu des options, la première étape devrait être une analyse basée sur les composants. Si cela fonctionne bien, il est toujours possible d’optimiser davantage l'analyse avec une analyse incrémentale et l’analyse par les développeurs au niveau des composants. Cette approche peut être intégrée dans les flux de travail typiques des développeurs.
Lors de la création d'une branche de développeur pour la mise en œuvre des modifications, une analyse locale rapide par le développeur détectera les erreurs locales. Celles-ci sont souvent les plus nombreuse car elles représentent la plus grande partie des modifications de code. C’est à cette étape qu’on détecte et affiche les violations vis-à-vis de la conformité aux standards de codage. Une analyse complète est recommandée sur une demande de fusion (merge) pour détecter les défauts restants liés au comportement entre composants. Dans le cas de CodeSonar, tous les états des warnings et les annotations sont conservés dans différents périmètres d'analyse.
Tout d'abord, commencez par un build et une analyse complète. Cela définit à la fois une référence en termes de défauts et de vulnérabilités détectés, mais cela permet également de fixer un objectif de performances à accroitre pour réduire le temps de développement. Cette étape déterminera le nombre exact de lignes de code que comporte votre application, la durée de l'analyse et son impact sur la charge du serveur de build. Ces métriques serviront à guider l'effort d'optimisation de l'analyse.
Compte tenu des options, la première étape devrait être une analyse basée sur les composants. Si cela fonctionne bien, il est toujours possible d’optimiser davantage l'analyse avec une analyse incrémentale et l’analyse par les développeurs au niveau des composants. Cette approche peut être intégrée dans les flux de travail typiques des développeurs.
Lors de la création d'une branche de développeur pour la mise en œuvre des modifications, une analyse locale rapide par le développeur détectera les erreurs locales. Celles-ci sont souvent les plus nombreuse car elles représentent la plus grande partie des modifications de code. C’est à cette étape qu’on détecte et affiche les violations vis-à-vis de la conformité aux standards de codage. Une analyse complète est recommandée sur une demande de fusion (merge) pour détecter les défauts restants liés au comportement entre composants. Dans le cas de CodeSonar, tous les états des warnings et les annotations sont conservés dans différents périmètres d'analyse.
Pour conclure :
Accélérer l’intégration de l’analyse SAST équivaut soit à réduire la quantité de travail que l'outil SAST doit effectuer, soit à augmenter la puissance de calcul pour effectuer l'analyse dans un temps plus court. En supposant que les ressources informatiques restent fixes, il existe néanmoins plusieurs approches pour réduire le scope de l'analyse SAST, ce qui réduit le temps d'exécution tout en produisant d'excellents résultats.
Une analyse complète de tous les sources donne les meilleurs résultats et les plus précis et est toujours recommandée à certains moments du développement. Cependant, l'analyse au niveau des composants donne d’excellents résultats pour les logiciels qui suivent une architecture modulaire basée sur des composants bien définie. Combiner l'analyse incrémentale ou développeur (local) avec cette approche offre un bon compromis entre la précision et le temps d'analyse.
