Le code écrit par l’IA a changé ce que le SAST doit détecter

Regarder un assistant de codage IA produire une fonctionnalité opérationnelle en quelques secondes peut ressembler à une avancée. Le code se compile. Les tests passent. La demande de tirage looks clean. Pour les équipes de développement sous pression pour expédier plus rapidement, cela ressemble à un progrès.

Mais le code fonctionnel et le code sécurisé ne sont pas la même chose.

Le code généré par l’IA a changé la forme du risque logiciel. Le problème n’est pas simplement que les grands modèles de langage écrivent un « mauvais » code. Dans de nombreux cas, ils écrivent un code qui semble poli, suit un modèle de framework familier et résout la tâche demandée. Le problème est plus subtil : le code peut être fonctionnellement correct tout en étant encore non sécurisé, obsolète, sur-autorisé ou contextuellement faux.

Cette distinction est importante car les tests de sécurité d’application statiques, ou SAST, ont été conçus pour un monde où les développeurs écrivaient du code à la vitesse humaine et où les équipes de sécurité examinaient des modèles de risque prévisibles. L’IA a changé les deux côtés de cette équation. Le volume de code augmente, les validations sont de plus en plus petites et les modèles non sécurisés peuvent désormais être générés à grande échelle.

Le résultat est une nouvelle question pour les équipes logicielles : que devrait détecter le SAST lorsque l’auteur du code n’est pas nécessairement humain ?

Le code opérationnel n’est plus un signal fort

Pendant des années, les équipes logicielles ont utilisé une hiérarchie de confiance approximative. Si le code se compilait, passait les tests et survivait à l’examen par les pairs, il se rapprochait de la production. L’analyse de sécurité ajoutait une autre couche, mais la fonctionnalité restait la première porte.

Les assistants de codage IA perturbent cette hiérarchie car ils sont particulièrement doués pour produire du code qui semble complet. Ils peuvent déduire les parties génériques, connecter les API, générer la gestion des erreurs et correspondre au style d’un référentiel existant. Cela les rend utiles, mais cela rend également leurs erreurs plus difficiles à détecter.

Un examinateur humain peut parcourir une fonction écrite par l’IA et penser : « Cela semble normal. » C’est précisément le risque. De nombreuses vulnérabilités générées par l’IA ne sont pas exotiques. Ce sont des problèmes familiers tels que les failles d’injection, la validation faible, les paramètres non sécurisés, la désérialisation non sécurisée, les problèmes de journalisation et les choix de dépendance obsolètes.

Des recherches récentes ont rendu cette tension plus difficile à ignorer. Par exemple, la mise à jour de sécurité du code GenAI de Veracode pour le printemps 2026 a constaté que les modèles de codage IA étaient devenus beaucoup plus forts pour produire du code syntaxiquement correct que du code sécurisé. En d’autres termes, l’IA devient très bonne pour écrire des logiciels qui fonctionnent, mais cela ne signifie pas qu’elle devient également bonne pour écrire des logiciels qui peuvent être considérés comme fiables.

La sortie peut sembler prête pour la production, mais le risque sous-jacent peut être complètement différent.

L’ancien modèle SAST a été conçu pour les goulets d’étranglement humains

Le SAST traditionnel a toujours eu un travail difficile. Il analyse le code source, mappe les modèles aux faiblesses connues et avertit les équipes avant que le code vulnérable ne soit expédié. Dans un cycle de développement conventionnel, cela crée déjà de la friction : trop d’alertes, trop de faux positifs et pas assez de temps pour remédier à tout.

L’IA rend cela plus difficile en supprimant l’une des contraintes cachées du développement logiciel : la vitesse de frappe humaine.

Lorsqu’un assistant IA peut générer un service, un fichier de test, une intégration d’API et un extrait de configuration dans une seule session, l’examen de sécurité ne peut pas s’appuyer sur les mêmes hypothèses. Le risque n’est pas une ligne de code négligente. C’est la multiplication de code plausible à travers des dizaines de fichiers, chacun avec de petites décisions que le modèle a prises au nom de l’équipe.

C’est là que les outils SAST modernes doivent évoluer. Ils ne peuvent pas simplement analyser les signatures de vulnérabilité connues après qu’une demande de tirage est presque terminée. Ils doivent fonctionner plus près du flux de travail du développeur, comprendre les modèles de changement assistés par l’IA et aider les équipes à séparer l’automatisation inoffensive de l’automatisation risquée.

L’IA introduit de la dette de sécurité à la vitesse de la machine

La dette technique n’est pas nouvelle. La dette de sécurité est la cousine plus dangereuse : elle s’accumule lorsque les vulnérabilités, les hypothèses faibles et les raccourcis risqués restent dans la base de code parce qu’ils ne sont pas suffisamment urgents pour être corrigés aujourd’hui.

L’IA peut accélérer ce processus.

Un développeur peut demander à un assistant d’« ajouter une authentification », de « nettoyer cette entrée » ou de « connecter ce point de terminaison à la base de données ». Le modèle produira généralement une réponse. Mais à moins que la invite ne comprenne les contraintes de sécurité correctes, la réponse peut s’appuyer sur des pratiques obsolètes, une validation incomplète ou des paramètres non sécurisés. Pire, elle peut être suffisamment bonne pour passer un examen occasionnel.

Il existe plusieurs modèles spécifiques à l’IA que le SAST doit désormais reconnaître :

• Le code de mise en page sécurisé : l’IA produit souvent du code qui ressemble aux meilleures pratiques mais manque d’un contrôle important, tel que des vérifications d’autorisation ou des encodages de sortie.
• Les hypothèses de dépendance obsolètes : un modèle peut suggérer des bibliothèques, des versions ou des API basées sur des modèles qui étaient courants dans ses données de formation mais qui ne sont plus recommandés.
• Les correctifs sans contexte : l’IA peut patcher le symptôme local sans comprendre le flux d’application plus large, créant des failles de sécurité ailleurs.
• Les modèles vulnérables répétés : si la même invite produit le même modèle erroné à travers plusieurs référentiels, une faiblesse peut se propager silencieusement au sein d’une organisation.

Ceci n’est pas seulement à propos de la recherche de mauvais code. C’est à propos de la détection de quand le code a été produit sans suffisamment de contexte.

Le SAST doit comprendre l’intention, et non seulement la syntaxe

La prochaine génération de SAST devra aller au-delà de la simple correspondance de modèles. Les modèles de vulnérabilité connus sont toujours importants, et de nombreuses failles de base devraient être détectées automatiquement. Mais le code écrit par l’IA soulève la barre car la syntaxe seule raconte rarement toute l’histoire.

Considérez un point de terminaison qui récupère des enregistrements de clients. Le code peut utiliser des requêtes paramétrées, gérer les erreurs correctement et passer les tests d’injection standard. Mais impose-t-il l’isolement des locataires ? Vérifie-t-il que l’utilisateur actuel est autorisé à accéder à l’enregistrement demandé ? Enregistre-t-il des données sensibles ?

Ce type de changement soulève également une question de confidentialité : si la logique générée par l’IA modifie ce que l’application stocke, enregistre ou expose, les équipes doivent comprendre son comportement de collecte de données d’application dans le cadre de l’examen de sécurité.

Ce ne sont pas toujours des problèmes de syntaxe. Ce sont des problèmes d’intention.

Le SAST a besoin de plus de conscience de la logique métier, du flux de données, des conventions de framework et de la relation entre une modification et le reste de l’application. L’objectif n’est pas de rendre le SAST « alimenté par l’IA » à des fins de marketing. L’objectif est de le rendre suffisamment conscient du contexte pour détecter les types d’erreurs que l’IA est susceptible de commettre.

Les développeurs doivent encore apprendre la sécurité, mais différemment

De meilleurs outils aideront, mais ils n’enlèveront pas la responsabilité humaine. Les assistants de codage IA rendent les développeurs plus productifs, mais ils rendent également plus facile pour les équipes d’accepter du code qu’ils ne comprennent pas entièrement.

Cela crée un défi de formation. La formation de sécurité traditionnelle annuelle est trop lente et trop détachée du travail quotidien. Les développeurs ont besoin de leçons pratiques et courtes délivrées près du moment où ils prennent des décisions. C’est là que l’apprentissage micro devient pertinent : de petits moments d’apprentissage peuvent renforcer les habitudes de codage sécurisé sans retirer les ingénieurs de leur flux de travail pendant des heures.

La meilleure éducation en matière de sécurité dans l’ère du codage IA ressemblera moins à une salle de classe et plus à une explication bien ciblée à l’intérieur d’une demande de tirage, à un avertissement IDE qui enseigne plutôt qu’il ne rappelle, ou à une note de correction qui explique pourquoi un modèle généré par l’IA est risqué.

Le processus d’examen doit changer

L’examen de code répondait à des questions familières : Le code est-il lisible ? Résout-il le problème ? Le casse-t-il ?

Le code écrit par l’IA ajoute de nouvelles questions. L’invite était-elle consciente de la sécurité ? Le modèle a-t-il introduit une dépendance ? A-t-il copié un modèle d’ailleurs dans le référentiel sans comprendre pourquoi ce modèle existait ? Le développeur a-t-il vérifié la logique ou seulement la sortie ?

Cela ne signifie pas que chaque validation assistée par l’IA nécessite une enquête forensique. Mais les équipes ont besoin d’un moyen léger d’identifier les modifications générées par l’IA à haut risque. L’authentification, l’autorisation, la cryptographie, les flux de paiement, les téléchargements de fichiers, l’accès à la base de données, la journalisation et la configuration de l’infrastructure méritent plus d’attention que la copie d’interface utilisateur ou le squelette de test.

Le fond

L’IA ne rend pas le SAST obsolète. Elle le rend plus important.

À mesure que la génération de code devient plus rapide et plus profondément intégrée dans les environnements de développement, l’ancienne hypothèse selon laquelle le code non sécurisé pénètre lentement par les mains humaines n’est plus valable. L’IA peut générer des logiciels utiles, mais elle peut également mettre à l’échelle des modèles faibles, des hypothèses obsolètes et des correctifs sans contexte plus rapidement que les processus d’examen traditionnels ne peuvent les absorber.

Les gagnants ne seront pas les équipes qui interdisent les outils de codage IA. Les gagnants seront les équipes qui conçoivent leurs flux de travail de sécurité autour de la nouvelle réalité : le code peut être généré instantanément, mais la confiance doit encore être gagnée.

Le SAST doit désormais détecter plus que les erreurs de syntaxe. Il doit détecter l’intention manquante, le contexte non sécurisé, les modèles répétés de l’IA et la dette de sécurité avant qu’elle ne s’accumule.