Découvrez GoogleTest certifié TÜV avec Agentic AI pour les tests C/C++ !
Plus de détails »
Aller à la section
Blog Parasoft
Cessez de traquer les vulnérabilités en aval. Découvrez pourquoi la prévention est préférable à la détection et pourquoi l'analyse statique des vulnérabilités logicielles (SAST) améliore l'analyse statique des vulnérabilités intégrées (IAST).
Aller à la section
Si vous participez à des discussions sur les outils de sécurité, vous finirez par entendre parler de l'IAST (tests de sécurité interactifs des applications). L'argument est le suivant : les outils SAST génèrent trop de bruit, les développeurs ignorent les résultats et, lorsqu'ils sont finalement détectés, il est déjà trop coûteux de les corriger. Il est donc préférable d'instrumenter l'application en cours d'exécution et de détecter les vulnérabilités réelles au moment même où elles se produisent, avec moins de bruit et un contexte plus pertinent.
Cette critique n'est pas totalement infondée. J'ai vu des SAST déployés exactement de cette manière, tardivement dans le cycle de développement, comme outil de détection de failles de sécurité plutôt que comme outil de renforcement du code. Et, effectivement, ils échouent dans ce cas. Mais c'est la conclusion selon laquelle l'IAST contourne les problèmes fondamentaux du SAST que je conteste fermement.
Voilà le problème : le mode de défaillance décrit est un problème de flux de travail, et non un problème d’outil. De plus, IAST présente ses propres problèmes structurels.
Il faut un élément déclencheur : une suite de tests, un scanner DAST générant du trafic d'attaque, ou de vrais utilisateurs en production. L'application doit être instrumentée. L'analyse ne porte que sur le code effectivement exécuté, quelle que soit la source du trafic. Lorsqu'elle détecte une vulnérabilité, le code est déjà compilé, intégré et déployé.
Et plus fondamentalement, Vous ne pouvez pas détecter votre chemin vers un logiciel sécuriséLa détection est importante, mais pas suffisante.
La célèbre directive de W. Edwards Deming, « cessez de vous fier au contrôle pour atteindre la qualité », n'était pas une suggestion d'arrêter les tests. C'était un défi lancé aux organisations qui avaient substitué le contrôle en fin de chaîne à une véritable ingénierie de la qualité. Si l'on détecte des défauts à la fin, c'est qu'on a déjà failli en amont. Le contrôle ne fait que rendre ce défaut visible.
L'approche traditionnelle de l'assurance qualité logicielle
Chaque discipline qui produit des objets fonctionnels a intégré ce principe. On ne contrôle pas la qualité d'un pont après avoir coulé le béton. On utilise les bons matériaux, on suit les bonnes procédures et on vérifie à chaque étape avant de passer à la suivante. La sécurité logicielle ne fait pas exception. Du moins, elle ne devrait pas.
L'intégration de la sécurité dès la conception est une discipline. Découvrir du code vulnérable a posteriori n'en est pas une. Ce sont deux activités d'ingénierie fondamentalement différentes, et l'analyse statique de la sécurité des applications (SAST) facilite la première. Les considérer comme interchangeables conduit à un programme de sécurité constamment en mode réactif, passant son temps à éteindre des incendies sans jamais s'attaquer à leurs causes profondes.
Un outil d'analyse statique de code (IAST) instrumente une application en cours d'exécution et signale les vulnérabilités au fur et à mesure que le code est testé ou exécuté en production. Son intérêt est indéniable : il confirme qu'une vulnérabilité est effectivement exploitable, grâce à un contexte d'exécution que les outils statiques ne peuvent pas reproduire. Cependant, sa limitation structurelle est tout aussi réelle : l'IAST ne voit que le code qui s'exécute.
La plupart des applications bénéficient d'une couverture de code par leurs tests unitaires comprise entre 40 % et 70 %. Cela concerne les portions de code gérant les cas limites, les erreurs, les fonctionnalités héritées et les interfaces d'administration rarement utilisées. Ces zones, que les attaquants sondent systématiquement, risquent de ne jamais être testées.
Il y a un problème plus profond sous-jacent. Les personnes qui écrivent les suites de tests ne sont généralement pas des testeurs de sécurité, et les testeurs de sécurité n'écrivent généralement pas de tests unitaires.
L'assurance qualité standard ne modélise pas le comportement des attaquants. Et les personnes qui modélisent ce comportement ne sont généralement pas impliquées dans la conception du cadre de test dont dépend l'IAST.
L'IAST vous donne une image précise des vulnérabilités du code qu'elle teste. En revanche, elle ne vous donne aucune information sur le code qu'elle ne teste pas. Vous réduisez les faux positifs, mais vous augmentez les faux négatifs. L'avantage des faux négatifs est qu'ils sont discrets. L'inconvénient est que vous ne savez pas quand ils se produisent.
Il y a aussi une charge pratique souvent négligée. Tous les outils IAST ont besoin d'un moteur d'exécution :
Certains outils peuvent utiliser n'importe lequel de ces éléments. Aucun ne peut analyser un code qui n'est pas exécuté.
Il est indispensable d'instrumenter l'application, de maintenir cette instrumentation malgré les modifications du code et de s'assurer que l'élément déclencheur de l'analyse couvre une surface d'attaque suffisante pour que les résultats soient pertinents. Plus cet élément est sophistiqué, plus l'investissement opérationnel nécessaire est important. La couverture est toujours proportionnelle à son déclencheur.
Et il y a aussi la question du coût. Au moment où IAST est lancé, le code est déjà écrit, intégré et déployé au moins dans un environnement de test, et souvent aussi en préproduction ou en production.
La plupart des déploiements IAST ont lieu en environnement de test ou de préproduction, ce qui correspond à notre graphique. Certains fournisseurs commercialisent explicitement le déploiement en production. Quel que soit l'environnement d'exécution, le code existe déjà et le contexte de développement qui l'a créé est en train de disparaître. Le rapport IBM/Ponemon Institute 2024 sur le coût d'une violation de données estime le coût moyen mondial d'une violation à 4.88 millions de dollars, un record.
Mais les coûts s'accumulent bien avant la production. Corriger un même défaut coûte beaucoup plus cher en assurance qualité qu'en environnement de développement intégré, et beaucoup plus cher en préproduction ou en production qu'en assurance qualité.
Le coût relatif de la correction d'une faille de sécurité augmente fortement à chaque étape du cycle de vie du développement logiciel (SDLC). L'IAST intervient généralement lors de la phase de test, où les coûts sont déjà nettement supérieurs au coût de référence au stade du codage.
Certains déploiements IAST ne se limitent pas à l'environnement de test. Certains fournisseurs commercialisent explicitement des solutions IAST prêtes pour la production, avec des agents fonctionnant en continu dans les systèmes en production et signalant les vulnérabilités à mesure que le trafic réel met le code à l'épreuve.
L'attrait est évident : surface d'attaque réelle, schémas d'utilisation réels, environnement réel.
Mais il faut considérer ce que la découverte en production implique concrètement pour la correction. Le code est déployé et les utilisateurs en dépendent. Un correctif nécessite de remonter le fil du processus à travers le développement, les tests, la préproduction et le redéploiement dans un logiciel qui a pu subir des modifications importantes depuis la mise en production de la version vulnérable.
Le développeur qui a écrit le code a peut-être changé de projet, de sprint ou même d'entreprise. Reconstituer le contexte nécessaire pour corriger le problème est coûteux et, en pratique, cela n'arrive souvent pas.
Il est malheureusement fréquent qu'une vulnérabilité découverte tardivement soit classée sans suite avec un commentaire du type « le code a considérablement évolué depuis le signalement » ou « impossible de reproduire le problème dans mon environnement ». Ce ne sont pas des correctifs, mais des reports déguisés en résolutions. Pendant tout ce temps, le temps presse face à l'exploitation de la faille.
Le Violation de données Uber en 2022 Cela illustre un problème similaire. Des attaquants ayant obtenu un accès réseau ont découvert un script PowerShell contenant des identifiants d'administrateur codés en dur pour le système de gestion des accès privilégiés d'Uber. Ces identifiants leur ont permis d'accéder à AWS, GCP, Google Drive, Slack et SentinelOne.
La cause profonde résidait dans une pratique de codage erronée : des secrets codés en dur dans le code source, qu’aucun outil d’exécution ne pouvait détecter. IAST analyse les applications en cours d’exécution. Une authentification présente dans un script n’est pas exécutée lors d’un test. SAST, en analysant le code source, la signalerait dès son écriture.
L'IAST en production est un filet de sécurité. C'est un filet utile. Mais l'objectif est d'y avoir recours le moins souvent possible, et le meilleur moyen d'y parvenir est d'empêcher l'apparition de la vulnérabilité.
Pour une part importante des logiciels développés aujourd'hui, il ne s'agit pas seulement de trouver des vulnérabilités, mais aussi de démontrer la conformité aux normes qui imposent des pratiques de codage spécifiques.
Tous ces éléments nécessitent le respect des règles de codage qui régissent le code source lui-même.
L'IAST ne peut pas vous indiquer si votre code C évite les constructions de langage interdites par MISRA. Il ne peut pas faire respecter les normes de codage CERT. Il ne peut pas produire les éléments de preuve exigés par les auditeurs et les organismes de certification. Ces propriétés existent dans le code source ou n'y existent pas. Seule une analyse statique du code source peut les vérifier. Ce n'est pas une lacune que de meilleures instrumentations peuvent combler.
Il existe également une barrière linguistique plus fondamentale.
IAST fonctionne en intégrant des agents dans des environnements d'exécution gérés : la JVM pour Java, le CLR pour .NET et des plateformes similaires.
C, C++, Rust et Ada, les langages qui dominent le développement embarqué critique en matière de sécurité, ne disposent pas de ce type de modèle d'instrumentation.
Il n'existe pas d'agent IAST pour le C bare-metal exécuté sur un calculateur automobile, pas d'environnement d'exécution instrumenté pour Ada dans un système avionique, et aucune couverture IAST significative pour les bases de code Rust que les agences gouvernementales américaines encouragent désormais activement pour le développement de systèmes à sécurité mémoire.
Pour ces langages et domaines, IAST n'est pas un choix sous-optimal. C'est simplement un choix irréalisable.
Il convient également de prendre en compte l'impact pratique sur les performances. L'instrumentation IAST induit une surcharge mesurable en termes de ressources CPU, de mémoire et de latence. L'ampleur de cette surcharge varie considérablement selon l'outil, l'application, la charge de travail et les éléments surveillés.
Les résultats peuvent varier, parfois considérablement. Pour les systèmes temps réel ou les environnements embarqués aux performances limitées, cette variabilité à elle seule disqualifie l'instrumentation d'exécution comme stratégie de sécurité principale, indépendamment de tout argument de couverture.
Dans les systèmes critiques pour la sécurité, le problème des faux négatifs n'est pas un inconvénient. C'est une exigence de conception.
Lorsqu'une défaillance logicielle a des conséquences matérielles, la question n'est pas seulement de savoir si votre outil de sécurité détecte les vulnérabilités, mais aussi si vous pouvez démontrer avec certitude qu'il n'en a manqué aucune.
L'IAST, de par sa structure, ne peut offrir cette garantie. Elle ne couvre que le code exécuté par des testeurs qui ne simulaient pas le comportement d'un attaquant lors d'une exécution de test n'ayant pas atteint les cas limites où les défaillances se dissimulent.
Il ne s'agit pas d'un problème de configuration d'outil, mais d'une limitation architecturale. Seule une analyse statique du code source permet une couverture systématique de l'intégralité du code source, avec des règles documentées et des preuves vérifiables.
Les logiciels critiques pour la sécurité ne sont pas testés pour garantir leur exactitude. Ils sont conçus en fonction de cette exactitude, l'analyse étant effectuée dès la première ligne de code. Les outils d'analyse statique de Parasoft, Test C / C ++Jtest et dotTEST couvrent les normes importantes pour C, C++, Java, C# et VB.NET, notamment MISRA, AUTOSAR, CERT, CWE, OWASP Top 10, OWASP API Top 10 et DISA ASD STIG.
Pour les équipes travaillant dans des secteurs réglementés, « utiliser IAST à la place » n'est pas une solution. C'est une fausse réponse.
Approfondissez
Explorez notre guide d'analyse statique du code »
Rien de tout cela ne remet en cause l'IAST. Si vous développez des applications où les tests d'exécution sont pertinents, il s'agit d'une couche d'abstraction réellement utile. Elle confirme les prédictions de l'analyse statique et détecte les problèmes que cette dernière ne repère pas, notamment les vulnérabilités qui ne se manifestent que lors d'interactions spécifiques avec les serveurs, les bases de données ou les services tiers.
La bonne réaction face à une anomalie détectée par IAST ne consiste pas seulement à corriger l'instance concernée. Corriger l'instance ? Oui. Mais il faut ensuite remonter à la source du problème et l'éliminer. Ce sont deux étapes distinctes.
Le correctif résout le problème immédiat. L'analyse des causes profondes et les normes de codage, les modèles de validation ou les contrôles d'analyse statique qui en découlent permettent de résoudre définitivement toute cette catégorie de problèmes.
C’est à cette deuxième étape que réside le véritable levier. Lorsqu’une vulnérabilité apparaît, la question technique pertinente n’est pas « comment corriger ce problème ? » mais plutôt « où ailleurs dans le code source cette même vulnérabilité se cache-t-elle ? »
Cette question nous est fréquemment posée par les développeurs et les équipes de sécurité qui appréhendent correctement le problème. Une seule détection IAST, bien gérée, justifie l'activation d'un outil de vérification non utilisé auparavant, ou la création d'un outil personnalisé ciblant spécifiquement le modèle que vous venez de découvrir.
Parasoft prend en charge les deux :
Les résultats obtenus lors de l'exécution servent de base pour affiner la configuration de l'analyse statique. C'est cette boucle de rétroaction qui permet d'obtenir des résultats concrets.
Lorsque le SAST fonctionne correctement, moins de vulnérabilités sont intégrées aux versions, moins de vulnérabilités atteignent les environnements d'intégration et moins de vulnérabilités atteignent les environnements où l'IAST est exécuté.
Les résultats de l'IAST deviennent plus significatifs et moins bruités.
L'équipe consacre moins de temps au tri et plus de temps à l'expédition. Les outils ne sont pas concurrents ; ils sont complémentaires : prévention en amont, confirmation en aval.
Voilà une question qui mérite d'être soulevée et qui ne reçoit pas encore suffisamment d'attention.
Que deviennent les défis structurels de l'IAST lorsque les agents de codage IA commencent à générer des portions importantes des bases de code ?
Les agents d'IA produisent du code rapidement et en grande quantité. Ils présentent également des modes de défaillance caractéristiques :
Ce ne sont pas des fautes de frappe. Ce sont des problèmes structurels qui proviennent d'un agent ayant appris à produire du code compilable et réussissant des tests de base sans avoir intégré le raisonnement derrière les contraintes de sécurité.
IAST a besoin que le code soit déployé, instrumenté et testé avant de pouvoir détecter quoi que ce soit.
À mesure que le volume de code généré par l'IA augmente, les limitations structurelles déjà existantes deviennent plus importantes.
L'analyse statique, en revanche, peut être intégrée directement dans la boucle de codage de l'IA, en analysant chaque fichier généré au moment de sa création avant son enregistrement.
À mesure que les agents de programmation d'IA se généralisent, l'intérêt de l'analyse statique comme étape de validation dans ce processus se renforce. Le principe sous-jacent est simple : l'analyse statique est indépendante de l'auteur du code.
Dans un monde idéal, le code généré par l'IA serait propre, bien structuré et exempt de failles de sécurité. Nous n'en sommes pas encore là. Les agents de codage IA actuels produisent de véritables violations de sécurité.
Parfois, il s'agit des mêmes types de violations que celles produites par les développeurs humains. Parfois, il en existe de nouvelles, caractéristiques de la façon dont les modèles génèrent du code.
La réponse est la même quelle que soit la source : effectuez une analyse statique sur tout, chaque commit, qu’il provienne d’un humain ou d’une machine.
Ce qui rend cette approche particulièrement puissante dans le contexte de Parasoft, c'est que la correction peut être axée sur la conformité, et non pas simplement correcte de manière générique. Il ne suffit pas de corriger une violation de façon à ce que le code compile.
Pour les bases de code fonctionnant sous MISRA, AUTOSAR ou d'autres normes, une correction qui introduit une nouvelle violation de la même norme, ou qui remplace un problème par un autre, n'est pas une correction du tout. L'agent de correction de code de Parasoft résout directement ce problème. Il corrige les anomalies détectées dans le contexte de la norme spécifique appliquée, puis relance l'analyse pour vérifier que la correction garantit effectivement la conformité et ne se contente pas de supprimer la ligne signalée. L'objectif est d'obtenir un code non seulement modifié, mais aussi manifestement conforme.
Parasoft a publié des recherches à ce sujet. Un livre blanc technique comparant Parasoft C/C++test à GitHub Copilot a évalué les correctifs automatisés pour les violations CWE sur 1 856 projets C/C++ open source.
Les invites de Parasoft prenant en compte la conformité, qui incluent la documentation des règles et le raisonnement par chaîne de pensée, ont surpassé la commande Fix générique de GitHub Copilot dans 64 % des cas lorsque le raisonnement était appliqué et dans 57 % des cas sans.
L'examen manuel a confirmé que les correctifs de Parasoft étaient plus complets, plus robustes et plus conformes aux normes de codage. La différence ne réside pas seulement dans le nombre d'erreurs détectées par l'outil, mais aussi dans sa capacité à identifier un correctif approprié dans un contexte de conformité précis.
L'industrie du logiciel a passé des décennies à essayer de tester la qualité à la fin. liste des bogues logiciels importants est suffisamment long pour se suffire à lui-même. La sécurité suit le même schéma :
Ce n'est pas un programme de sécurité. C'est un tapis roulant.
Les équipes qui améliorent réellement leur sécurité ne sont pas celles qui possèdent les meilleurs outils de détection. Ce sont celles qui investissent dès le départ dans un code de meilleure qualité, intégrant le respect des normes et l'analyse statique de manière à influencer le code pendant que le développeur dispose encore du contexte nécessaire pour le corriger efficacement. Deming ne disait pas que l'inspection est inutile, mais que si elle constitue votre principale stratégie qualité, vous avez déjà perdu.
L'IAST est un outil utile sur le tapis roulant. L'objectif est de pouvoir descendre du tapis roulant.
Intégrez la qualité dès la conception. Vérifiez-la en cours d'exécution. Et ne laissez personne vous dire que détecter les problèmes à la fin remplace leur prévention au départ.
Les tests statiques de sécurité des applications (SAST) analysent le code source sans l'exécuter, détectant les vulnérabilités dès sa conception. Les tests interactifs de sécurité des applications (IAST) instrumentent une application en cours d'exécution et détectent les vulnérabilités pendant l'exécution du code, que ce soit en phase de test ou en production. Les SAST repèrent les problèmes avant leur déploiement. Les IAST les détectent dans le code déjà en cours d'exécution. Les deux méthodes permettent de déceler les failles réelles. Seuls les SAST permettent d'empêcher leur développement.
Non. L'IAST n'analyse que le code exécuté, laissant ainsi de larges portions de la plupart des bases de code inexplorées. Elle nécessite une suite de tests pour l'analyse et un effort opérationnel pour l'instrumentation et la maintenance. Elle ne peut pas vérifier la conformité aux normes de codage telles que MISRA, CERT ou OWASP. Enfin, elle ne peut détecter une vulnérabilité qu'une fois le code écrit, compilé et déployé, moment où la correction est nettement plus coûteuse.
L'IAST est particulièrement utile en tant que couche complémentaire à la SAST dans les programmes de sécurité applicative où les tests d'exécution sont réalisables et où une suite de tests éprouvée existe déjà. Elle confirme l'exploitabilité réelle des vulnérabilités et détecte celles qui ne se manifestent que lors des interactions avec le serveur d'exécution. Elle ne convient pas comme stratégie principale ou unique et n'apporte aucune valeur ajoutée aux bases de code soumises à des exigences de conformité qui requièrent la preuve de la conformité du code source à des normes telles que MISRA ou CERT.
Parasoft se concentre sur les tests SAST, et non sur les tests IAST. Les outils d'analyse statique de Parasoft Couvrir les langages C, C++, Java, C# et VB.NET avec des ensembles de règles détaillés pour les normes de sécurité et de conformité.
Quelle solution SAST convient le mieux à votre équipe ?
