Gains :
- Capacité à utiliser l'intelligence artificielle comme deuxième œil et à signaler les vulnérabilités de la classe OWASP (injection, secret matériel, contrôle d'accès) dans le code en donnant du contexte
- Capacité à éliminer les faux positifs produits par l'intelligence artificielle avec contexte et à éviter de traiter chaque découverte comme une véritable vulnérabilité sans la valider
- Capacité à reconnaître que le correctif suggéré par l'intelligence artificielle peut introduire de nouvelles vulnérabilités/bugs et faire passer chaque correctif par la porte d'examen et de test
Les vulnérabilités logicielles comptent parmi les vulnérabilités les plus coûteuses, car elles sont intégrées au produit dès le départ et distribuées à des millions d’utilisateurs. La révision du code sécurisé est le processus de lecture du code source ligne par ligne et de détection des vulnérabilités (injection SQL, vulnérabilité d'authentification, mot de passe codé en dur, autorisation incorrecte) avant leur mise en production. Lorsqu’il est fait à la main, c’est lent et fatiguant ; Il est facile de rater une vulnérabilité dans une base de code volumineuse.
L'IA est puissante en matière de révision de code pour deux raisons : le code est également un langage et l'IA est efficace en matière de reconnaissance de formes. L'IA peut rapidement signaler des modèles dangereux dans un morceau de code (entrée de l'utilisateur directement dans la requête, stockage de données non chiffrées, validation d'entrée manquante), expliquer pourquoi chacun est risqué et suggérer une solution. Mais l'IA ne voit pas tout le contexte de fonctionnement du code (l'entrée peut être effacée à une autre couche), elle peut inventer une vulnérabilité qui n'existe pas (faux positif) ou rater une vulnérabilité réelle (faux négatif), et surtout, le « correctif » qu'elle propose peut introduire une nouvelle vulnérabilité ou un nouveau bug. L'IA est un deuxième œil et un indicateur dans la révision du code ; Le développeur et l'expert en sécurité décident si une découverte constitue une réelle vulnérabilité et si le correctif est correct et sûr.
Étapes de la révision du code
- Donnez la portée et le contexte. Quel langage, quel framework, où ce code prend-il ses entrées, où donne-t-il sa sortie, à quelle couche fonctionne-t-il ? La révision du code sans contexte produit des faux positifs.
- Recherchez les modèles dangereux. Recherchez les classes de vulnérabilités IA connues (telles que OWASP Top 10) : injection, authentification, divulgation de données sensibles, contrôle d'accès.
- Justifiez chaque constat. Pour chaque flag : quelle ligne, quelle classe de vulnérabilité, comment peut-elle être exploitée, quelles sont les preuves. Un constat injustifié n’est pas pris au sérieux.
- Éliminez les faux positifs. L'entrée est-elle réellement effacée, ce chemin est-il vraiment accessible - vérifiez avec le contexte.
- Vérifiez le correctif. Confirmez que le correctif recommandé par AI corrige réellement la vulnérabilité, n'introduit pas de nouvelles vulnérabilités/bogues et a réussi les tests.
- Approbation humaine. Un développeur + un expert en sécurité examine le résultat et le correctif ; C'est ainsi qu'il entre dans le référentiel de code.
Termes : SAST (Static Application Security Testing — tests de sécurité statiques qui analysent le code source sans l'exécuter). DAST (Dynamic — test dynamique qui teste l'application en cours d'exécution en externe). OWASP Top 10 est la liste standard des vulnérabilités des applications Web les plus courantes. L'injection est une vulnérabilité causée par l'interprétation des entrées de l'utilisateur comme une commande/requête (par exemple, une injection SQL). La requête paramétrée est la méthode correcte qui empêche l'injection en séparant l'entrée du code.
Tableau des classes de vulnérabilité courantes
Classe de vulnérabilité
Symptôme (dans le code)
bonne solution
Le piège de l'IA
Injection SQL
Joindre une entrée à une requête
Requête paramétrée
Peut ignorer la désinfection
secret codé en dur
Mot de passe/clé du code
Coffre-fort secret (coffre-fort), env
Faux positif (échantillon/test)
Faible authentification
Contrôle manquant/incorrect
Contrôle puissant et centralisé
manque de contexte
Contrôle d'accès défectueux
Pas de contrôle d'autorisation
Autorisation côté serveur
Ne comprend pas les flux complexes
Divulgation de données sensibles
Stockage/journalisation sans mot de passe
Cryptage, masquage
Je ne peux pas connaître la criticité
Sérialisation non sécurisée
Désérialiser les données peu fiables
Analyse sécurisée
Manque un motif rare
trois mini-cases
Cas 1 — Récupération de l'injection proprement dite. Un développeur demande à l'IA d'examiner une fonction d'accès aux données. L'IA marque la ligne où la valeur userId de l'utilisateur est concaténée directement dans le texte SQL et dit "il s'agit d'une injection SQL classique, transformez-la en une requête paramétrée" ; Fournit une correction d’échantillon. Le développeur confirme que l'entrée n'a pas été nettoyée ailleurs, vérifie qu'il s'agit d'une vulnérabilité réelle, implémente la requête paramétrée suggérée et écrit un test. L’IA a mis en évidence la vulnérabilité ; les tests de vérification et de correction provenaient du développeur.
Cas 2 — Secret fixe faux positif. L'IA voit la ligne password = "test1234" dans un fichier et dit "critique : mot de passe codé en dur". Le développeur vérifie le contexte : il s'agit d'un fichier de test unitaire, de données de test factices, non mises en production et non portées sur un système réel. Le résultat est un faux positif. Le développeur documente cela mais ne prend aucune mesure car ce n’est pas un vrai secret. Leçon : le signe « dur secret » de l'IA doit être éliminé par le contexte ; Toutes les chaînes ne sont pas un secret.
Cas 3 — Nouveau correctif de vulnérabilité. AI propose un correctif pour une vulnérabilité XSS (cross-site scripting) ; mais le code qu'il suggère efface l'entrée au mauvais endroit et ignore l'encodage de la sortie dans une autre zone ; L’écart ne se comble donc pas complètement. L'expert en sécurité examine le correctif, remarque le codage manquant et le corrige au niveau de la couche appropriée. Leçon : le correctif recommandé par AI n'est pas automatiquement sécurisé ; Chaque correctif est examiné et testé.
Invite faible/Invite forte
Invite faible :
Y a-t-il une faille dans ce code, corrigez-la : [code]
Cette invite ne donne aucun contexte (langage, cadre, source d'entrée), ne demande pas de justification, ne remet pas en question le faux positif et est ouverte à l'acceptation aveuglément de la correction produite par l'IA. L’IA mélangeait des signes de vulnérabilité réelle et inexistante.
Invite puissante :
Votre rôle : assistant qui est le DEUXIÈME ŒIL du développeur en révision de code sécurisé. Prise de décision ; considérez le correctif directement appliqué. Code : [spécifier la langue/le framework]. Contexte : cette fonction [source d'entrée : par ex. reçoit [requête HTTP externe], écrit dans [destination de sortie]. Votre tâche : (1) signaler les vulnérabilités possibles avec la classe OWASP, donner le numéro de ligne + pourquoi risqué + comment exploiter + preuves pour chacune, (2) écrire au moins 1 scénario faux positif pour chaque résultat (par exemple si l'entrée est nettoyée dans une autre couche), (3) suggérer un correctif mais avec le signe "[révision + test d'écriture]" ; Évaluez également si le correctif introduit de nouvelles vulnérabilités/bogues. Ajout d'une fausse vulnérabilité.[code]
Une invite forte donne le contexte, demande la classe et les preuves OWASP, remet en question les faux positifs et les risques de remédiation, force un examen humain.
Modèles d'invite copiables
MODÈLE D'ANALYSE DE VULNÉRABILITÉ Examinez le code [langage/framework] pour OWASP Top 10. Pour chaque résultat possible : numéro de ligne, classe de vulnérabilité, pourquoi il est risqué, exemple d'exploit, force de la preuve (certaine/probable/faible). Contexte : entrée [source], sortie [cible]. Ajout de découvertes fabriquées ; Si vous n'êtes pas sûr, tapez "[doit être vérifié]". Code : [coller]
MODÈLE D'ÉLIMINATION FAUX POSITIF Pour la découverte de code suivante, répertoriez les scénarios dans lesquels il n'y a PAS de réelle vulnérabilité : l'entrée pourrait-elle être effacée sur une autre couche, ce chemin est-il accessible, cette valeur est-elle un test/échantillon, le framework est-il automatiquement protégé. Écrivez comment confirmer pour chacun. Résultat : [coller]
CORRIGER LE MODÈLE D'ÉVALUATIONRecommander un correctif pour la vulnérabilité suivante ; puis critiquez votre propre correctif : (1) ferme-t-il vraiment la vulnérabilité, (2) introduit-il une nouvelle vulnérabilité/un nouveau bug, (3) quel test dois-je écrire (cas positif et négatif), (4) impact sur les performances/fonctionnalités. Je vais examiner et tester le correctif. Vulnérabilité + code : [coller]
MODÈLE D'ENSEIGNEMENT DE MODÈLE SÉCURISÉ pour la classe de vulnérabilité [par ex. Injection SQL] montre comparativement un modèle de frappe sûr et des modèles erronés courants dans ce langage/framework. Règle générale + donner un exemple de code ; mais je veux que vous demandiez le contexte avant de l'implémenter dans mon code. Langage/framework : [écrire]
Erreurs courantes
- Revue sans contexte. Sans langage, cadre et contexte d’entrée/sortie, l’IA confond les résultats réels et fallacieux ; Assurez-vous de donner le contexte.
- Prendre chaque signe pour une réelle faiblesse. L'IA produit des faux positifs (données de test, entrées nettoyées sur une autre couche) ; Examinez chaque constatation avec son contexte.
- Appliquer aveuglément la correction de l'IA. Le correctif recommandé peut introduire de nouvelles vulnérabilités/bugs ; réviser et rédiger des tests.
- Faire confiance au faux négatif. Même si l'IA dit « aucune vulnérabilité », examinez vous-même les chemins critiques ; L'analyse statique ne détecte pas toutes les vulnérabilités.
- Donner le code/secret à l'outil externe. Le code privé et les secrets réels (clé, mot de passe) sont propriété intellectuelle et vulnérabilité ; anonymiser ou utiliser des outils d’entreprise isolés.
Astuce : Lorsque vous disposez du code de révision de l’IA, le filtre le plus efficace consiste à demander la « force de preuve » (certaine/probable/faible) pour chaque résultat. La plupart des résultats marqués « faibles » sont des faux positifs ; vous allouez votre énergie aux « sûrs ».
Attention : le correctif de sécurité proposé par AI ne doit pas entrer dans l'entrepôt sans avoir été testé. Un « correctif » incorrect peut à la fois laisser la vulnérabilité ouverte et conduire à une erreur fonctionnelle en production ; Chaque correctif passe par la porte d’examen et de test.
En résumé
L’examen sécurisé du code est le moyen le moins coûteux de détecter les vulnérabilités avant qu’elles ne soient mises en production, et comme le code est un langage, l’IA devient ici un puissant deuxième œil : signale les modèles dangereux, explique les risques, suggère des correctifs. Mais l’IA ne voit pas l’intégralité du contexte opérationnel, produit des faux positifs et des faux négatifs, et le correctif qu’elle recommande peut introduire de nouvelles vulnérabilités. L'examen comporte donc six étapes (contexte, filtrage, justification, élimination des faux positifs, vérification du correctif, approbation humaine) et la décision appartient au développeur et à l'expert en sécurité. Trois principes : aucune découverte n'est interprétée sans contexte, chaque signe est éliminé avec le contexte, aucun correctif n'est stocké sans avoir été testé. Et le code/secret n’est jamais communiqué à un outil extérieur sans anonymisation.
Tâche de candidature
Prenez un exemple d'extrait de code (soit en supprimant les parties sensibles de votre propre code, soit un exemple de code comportant des vulnérabilités). Demandez à l'IA de l'examiner avec le modèle « Vulnerability Scanning » ; Appliquez le modèle « Élimination des faux positifs » pour chaque résultat et éliminez les vrais. Prenez la correction du résultat le plus grave avec le modèle « Évaluation de remédiation », examinez-le vous-même et rédigez un cas de test positif + un cas de test négatif. Notez combien de résultats étaient des faux positifs.
liste de contrôle
- [ ] J'ai donné le langage, le framework et le contexte d'entrée/sortie avant de revoir le code.
- [ ] J'ai demandé le numéro de ligne, la classe de vulnérabilité, le chemin d'exploitation et les preuves pour chaque découverte.
- [ ] J'ai examiné chaque résultat pour détecter les faux positifs avec le contexte.
- [ ] Je n'ai pas appliqué aveuglément la correction de l'IA ; J'ai révisé et écrit un test.
- [ ] Malgré le résultat « Aucune vulnérabilité », j'ai moi-même examiné les chemins critiques.
- [ ] J'ai anonymisé le code/les secrets ou j'ai utilisé des outils isolés d'entreprise.
- [ ] J'ai réussi la découverte et la correction via l'approbation du développeur + sécurité.