Le Problème de l'Analyse Traditionnelle de Sécurité du Code
Les Tests de Sécurité Statique des Applications, universellement connus sous le nom SAST, ont été le paradigme dominant pour l'analyse automatisée de la sécurité du code pendant plus de deux décennies. L'approche est conceptuellement simple : analyser le code source sans l'exécuter, à la recherche de modèles qui correspondent aux signatures de vulnérabilités connues. Les requêtes SQL assemblées à partir de l'entrée utilisateur, les allocations de mémoire sans vérification des limites, les fonctions cryptographiques utilisées avec des paramètres faibles—les outils SAST peuvent signaler ces modèles rapidement dans les bases de code de n'importe quelle taille.
Le problème est le taux de faux positifs. Les bases de code d'entreprise matures reçoivent régulièrement des rapports SAST contenant des milliers d'éléments marqués, dont la majorité représente soit des modèles de code non exploitables, des vulnérabilités atténuées, soit des utilisations légitimes d'API marquées. Les ingénieurs de sécurité passent énormément de temps à trier ces rapports. Le rapport signal-bruit est suffisamment mauvais que de nombreuses organisations exécutent les outils SAST selon le calendrier mais ont développé une tolérance institutionnelle pour ignorer de grandes portions de leur résultat.
C'est le problème que OpenAI dit avoir voulu résoudre avec Codex Security—et la raison pour laquelle elle a choisi de ne pas inclure un rapport SAST comme partie du produit.
Le Raisonnement par Contraintes comme Alternative
Codex Security utilise une méthodologie différente que OpenAI décrit comme le raisonnement par contraintes alimenté par l'IA et la validation. Plutôt que de mettre en correspondance les modèles par rapport aux signatures de vulnérabilités, le système tente de raisonner sur la question de savoir si une vulnérabilité est réellement exploitable compte tenu du contexte spécifique dans lequel elle apparaît.
Cette distinction a une immense importance en pratique. Un outil SAST pourrait signaler chaque instance d'une fonction de formatage de chaîne particulière comme une vulnérabilité potentielle de formatage de chaîne, que les entrées à cette fonction puissent réellement être influencées par un attaquant ou non. Codex Security tente de retracer les flux de données, de comprendre les limites de confiance et d'évaluer si un attaquant ayant un accès réaliste pourrait réellement déclencher le chemin de code problématique.
Cette approche emprunte à la vérification formelle et aux méthodes de satisfaction des contraintes utilisées dans la recherche en sécurité universitaire, mais applique le raisonnement IA pour gérer l'ambiguïté et la complexité des bases de code du monde réel que les méthodes formelles ont historiquement eu du mal à mettre à l'échelle.
Moins de Résultats, Plus de Confiance
Le compromis inhérent à cette approche est que Codex Security pourrait manquer des vulnérabilités que SAST détecterait. OpenAI est transparente sur cette limitation. Le système est conçu pour prioriser la précision par rapport au rappel : les vulnérabilités qu'il signale sont censées être réelles et exploitables, même s'il y a des vulnérabilités authentiques dans la base de code que le système n'identifie pas.
Pour les équipes de sécurité noyées dans les résultats SAST de faible qualité, ce compromis pourrait être attrayant. Un ensemble plus petit de résultats hautement fiables et exploitables peut être remédié de manière cohérente, produisant des améliorations mesurables de la posture de sécurité. Un grand ensemble de résultats où la majorité sont des faux positifs produit une paralysie analytique et, en pratique, aboutit souvent à ce que rien ne soit corrigé.
OpenAI affirme que l'expérience développeur est également nettement meilleure lorsque les résultats sont fiables. Un développeur qui a appris que 80 pour cent des résultats de l'outil de sécurité dans sa base de code sont du bruit devient habitué à ignorer les avertissements de sécurité. Un outil qui a presque toujours raison entraîne un comportement différent : prendre chaque résultat au sérieux et le corriger.
Pipeline de Validation
Codex Security combine le raisonnement initial par contraintes avec une étape de validation qui utilise l'IA pour générer des cas de test de preuve de concept tentant de déclencher réellement la vulnérabilité dans un environnement isolé. Si le modèle du système concernant la façon dont une vulnérabilité pourrait être exploitée peut être transformé en un exploit fonctionnel—même un inoffensif qui démontre simplement que le chemin de code s'exécute—la confiance dans le résultat augmente considérablement.
Cette étape de validation est coûteuse en termes de calcul par rapport à l'appariement de modèles statiques, ce qui est l'une des raisons pour lesquelles l'approche n'est pas universelle parmi les outils de sécurité. Mais elle représente une porte de contrôle de qualité importante. Les vulnérabilités qui survivent à la fois à la phase de raisonnement par contraintes et à la phase de validation d'exploit sont nettement plus susceptibles de représenter des risques de sécurité authentiques que les résultats SAST qui n'ont pas été soumis à aucune vérification basée sur l'exécution.
Positionnement dans le Paysage des Outils de Sécurité
Codex Security n'est pas positionnée comme un remplacement pour tous les outils de sécurité. OpenAI la décrit comme complémentaire aux tests de fuzzing, aux tests de pénétration et à l'examen manuel du code. La proposition est que pour le travail spécifique de l'analyse automatisée du code, les approches basées sur le raisonnement peuvent fournir de meilleurs résultats que les approches basées sur les signatures pour les bases de code et les classes de vulnérabilités où le raisonnement IA est suffisamment mature pour être fiable.
Le produit poursuit une tendance plus large dans l'outillage de sécurité assisté par l'IA vers des systèmes qui comprennent la sémantique du code plutôt que simplement la syntaxe. Alors que les modèles d'IA formés sur de grands corpus de code deviennent plus capables de raisonner sur le comportement des programmes, l'écart entre ce que les outils automatisés peuvent trouver de manière fiable et ce que les chercheurs en sécurité humains compétents peuvent trouver se rétrécit—bien qu'il ne soit pas encore fermé.
Cet article est basé sur les rapports d'OpenAI. Lire l'article original.
Originally published on openai.com


