Gains :
- Possibilité de vérifier les résultats de l'IA à trois niveaux : précision, sécurité et source/licence
- Capacité à couvrir les risques tels que les injections, les hallucinations et les secrets enfouis avec des moules et des outils sûrs
- Capacité à présenter le code critique pour la sécurité à l'approbation d'un ingénieur compétent et à comprendre l'intransférabilité de la responsabilité
Générer du code IA est simple ; Lui faire confiance coûte cher. Le seul objectif de cette unité est de transformer le principe de « vérifier », que nous avons répété dans toutes les unités précédentes, en une discipline d'ingénierie systématique. Car le code produit par l’IA, même s’il semble correct à première vue, comporte trois dangers distincts : ne pas fonctionner/incorrect (hallucination), être peu sûr (vulnérabilité) et comporter des risques juridiques/de licence. Connaître ces trois éléments et établir une porte pour chacun d’eux fait de vous un professionnel.
Ici, nous considérons la « validation » à trois niveaux : l'exactitude (le code fait-il réellement le travail ?), la sécurité (résiste-t-il aux entrées malveillantes ?) et la provenance/licence (ai-je le droit d'utiliser ce code ?). Chaque couche a ses propres moyens de contrôle, et aucun d'entre eux ne peut être contourné avec "c'est ce que l'IA a dit".
Trois niveaux de risque
1. Risque d'exactitude (hallucination). Le modèle peut appeler une fonction inexistante, utiliser à mauvais escient une API, contourner silencieusement un cas limite. Le code semble "raisonnable" mais il est faux. Antidote : compilation, tests, analyse statique et inspection visuelle.
2. Risque de sécurité. L'IA peut répéter des modèles non sécurisés dans les données d'entraînement : requête vulnérable à l'injection SQL, saisie utilisateur non authentifiée, cryptage faible, désérialisation non sécurisée, redirection ouverte. Le code fonctionne mais est vulnérable aux attaques. Antidote : examen axé sur la sécurité, scanners automatisés (SAST) et imposition de modèles de sécurité connus.
3. Risque de source/licence. L’IA peut produire une sortie qui ressemble beaucoup à du code protégé par des droits d’auteur ou sous licence restrictive, ou elle peut suggérer une dépendance sous licence inappropriée. Antidote : vérification des dépendances et des licences, vérification de l'originalité, politique d'entreprise.
Attention : Le plus insidieux de ces trois risques est la sécurité ; car le code peut réussir les tests, s'exécuter sans problème en production et la vulnérabilité n'est révélée que lorsqu'un attaquant la trouve. « Travailler » n'est pas la même chose que « sécuriser ».
Étape par étape : porte d'authentification en couches
- Lisez avec compréhension. Bien comprendre le code avant de l’accepter ; Ne fusionnez pas le code que vous ne comprenez pas. Si vous n'arrivez pas à expliquer "pourquoi ça marche", cela n'a pas encore été validé.
- Vérifiez qu'il existe. Confirmez que chaque fonction, API et package utilisé existe réellement et est utilisé correctement (porte d'hallucination).
- Exécutez des outils automatisés. Compilateur, linter (scanner de style/erreur), vérificateur de type, tests unitaires et si possible un SAST (Static Application Security Testing — outil qui analyse le code source à la recherche de vulnérabilités).
- Regardez-le du point de vue de la sécurité. La saisie est-elle validée ? La requête est-elle paramétrée ? Le secret est-il enterré ? Y a-t-il un contrôle d'autorisation ?
- Vérifiez la source et la licence. Les nouvelles dépendances sont-elles sous licence ? Le résultat ressemble-t-il trop à une base de code connue ?
- Si cela est critique pour la sécurité, demandez l’approbation d’un expert. Un examen indépendant par un ingénieur compétent dans des domaines tels que l'authentification, le paiement, la cryptographie, le contrôle d'accès est obligatoire.
Trois mini-étuis
Cas 1 — Injection SQL interceptée à la porte d'inspection. Le code généré par l'IA qui concatène les entrées de l'utilisateur directement dans la requête SQL pour un point de terminaison de recherche ("... WHERE name = '" + q + "'"). Le code fonctionnait et a réussi le test. L'inspection axée sur la sécurité et l'analyse SAST ont détecté ce problème ; Elle a été convertie en requête paramétrée (instruction préparée). Si elle n’avait pas été détectée, il s’agirait d’une vulnérabilité classique en matière de fuite de données.
Cas 2 – Forfait Hallucination. AI a suggéré un package npm inexistant (fast-safe-parse) pour une tâche. Lorsque le développeur a essayé de l'installer, le package n'a pas été trouvé. Pire encore : dans certains cas, les attaquants peuvent remplir ces noms de packages "fantômes" avec des packages réels et malveillants (confusion des dépendances). Leçon : vérifiez chaque package recommandé par rapport au registre officiel et à l'historique de téléchargement/maintenance.
Cas 3 — Incompatibilité de licence. Une astucieuse bibliothèque complémentaire suggérée par AI disposait d'une forte licence copyleft incompatible avec la licence de produit de l'institution. L'analyse des licences de dépendance a signalé cela ; L'équipe a remplacé la licence par une alternative appropriée. Sans vérification, une charge juridique apparaîtrait dans la distribution des produits.
Quatre modèles copiables
Autocontrôle pré-admission :
Avant d'accepter le code généré par l'IA suivant, vérifiez : 1) Chaque fonction/API/package qu'il utilise existe-t-il réellement ? Signalez les suspects.2) Y a-t-il des entrées non validées, une concaténation SQL/commande, un secret enfoui, un crypto faible ?3) Quels sont les bogues/cas limites non résolus ?Étiquetez chaque résultat comme « certain/probable » et suggérez des correctifs.{{code}}
Examen axé sur la sécurité :
Examinez ce code avec un œil de sécurité. Recherchez les vulnérabilités courantes de type OWASP : injection, authentification/autorisation interrompue, divulgation de données sensibles, désérialisation non sécurisée, redirection non authentifiée. Pour chaque constat : risque, scénario d’exploitation, remédiation. Il s'agit d'une sélection préliminaire ; renvoyer les conclusions critiques à un examen de la sécurité humaine.{{code}}
Vérification des dépendances et des licences :
Lister les dépendances ajoutées/suggérées par ce code. Pour chacun : le package existe-t-il réellement, est-il maintenu, quelle serait sa licence typique (DOIT ÊTRE VÉRIFIÉE) et est-il réellement nécessaire pour le projet ou peut-il être réalisé avec un outil existant ?{{code ou liste de dépendances}}
Imposition de coffrages en toute sécurité (en production) :
Écrivez du code pour {{task}}. Règles de sécurité OBLIGATOIRES :- Valider/désinfecter toutes les entrées externes.- Utiliser uniquement des requêtes paramétrées dans l'accès à la base de données.- Ne pas intégrer de secrets dans le code ; supposez une variable d'environnement/un gestionnaire de secrets - N'avalez pas les erreurs ; Considérez-le de manière significative. Expliquez comment le code respecte ces règles en 3 éléments.
Invite faible/Invite forte
Faible : "Écrivez une requête qui recherche par nom d'utilisateur." (Un code vulnérable à l'injection peut survenir.)
Fort : "Écrivez une fonction qui recherche par nom d'utilisateur. Ne joignez jamais l'entrée de l'utilisateur dans une requête sous forme de chaîne ; utilisez une requête paramétrée (instruction préparée). Validez l'entrée pour la longueur et le caractère. Expliquez en 2 phrases pourquoi le code est fermé à l'injection. "
La version forte impose le schéma sécurisé dès le départ ; Ainsi, cela garantit que la vulnérabilité ne se produira pas du tout, plutôt que de la détecter plus tard. Cependant, il est essentiel de faire passer le code généré via des portes de vérification.
Couche d'authentification
Outil/méthode
Est-ce que « AI dit » est suffisant ?
précision
Compilation, tests, inspection visuelle
non
Réalité API/package
Contrôle des documents/dossiers officiels
non
Sécurité
SAST, revue de sécurité
non
Licence/source
Vérification des dépendances et des licences
non
Logique critique pour la sécurité
Approbation d'un ingénieur expert
Absolument pas
La responsabilité ne peut pas être transférée
La responsabilité des erreurs, vulnérabilités ou violations résultant du code produit par un outil d'IA appartient à l'équipe qui assemble et distribue ce code, et non au fournisseur de l'outil. C’est un fait professionnel autant que juridique : vous signez. Ainsi, « l’IA l’a produit » n’est pas une excuse, mais une justification pour une prudence accrue. En particulier dans les systèmes critiques pour la sécurité, les résultats de l'IA ne remplacent en aucun cas l'examen et l'approbation par un ingénieur qualifié ; Tout au plus, l’IA fournit un modèle qui accélère cet ingénieur.
Astuce : créez une courte liste de contrôle au sein de votre équipe que vous appelez « porte de validation pour le code généré par l'IA » (build + test + analyse de sécurité + inspection visuelle). Une fois ce portail devenu une habitude, la perte de vitesse est minime et la réduction des risques est maximale.
Erreurs courantes
- Confondre « fonctionne » avec « sûr ». Le code qui réussit les tests peut être vulnérable aux attaques.
- Utiliser le package/l'API sans le vérifier. Les paquets hallucinatoires sont à la fois corrompus et présentent un risque pour la sécurité.
- Contourner les outils automatisés. Linter, le vérificateur de type et SAST capturent à moindre coût ce que les humains manquent.
- Ignorer la licence. Une dépendance inappropriée sous licence crée une charge juridique sur la distribution.
- Mettre la responsabilité sur le véhicule. L'équipe est responsable du code en production ; « L’IA l’a fait » n’est pas une excuse.
En résumé
L'acceptation des résultats de l'IA nécessite trois niveaux de vérification : l'exactitude (compilation, test, inspection visuelle), la sécurité (SAST et examen axé sur la sécurité) et la source/licence (vérification des dépendances). Confirmez que chaque package et API utilisé existe réellement, appliquez des modèles sécurisés dès le départ et soumettez le code critique pour la sécurité pour approbation par un ingénieur qualifié. « Travaux » ne signifie pas sûr, et « IA produite » n'élimine pas la responsabilité. La porte de vérification est le prix du professionnalisme, pas de la rapidité.
Tâche de candidature
Confiez délibérément à une IA une tâche sensible en matière de sécurité (par exemple « une fonction qui recherche dans la base de données avec la saisie de l'utilisateur »), cette fois sans imposer de modèle sûr. Transmettez le code entrant via des modèles d'« auto-audit de pré-admission » et d'« examen axé sur la sécurité » : y a-t-il une injection, un secret enfoui, un paquet halluciné ou une entrée non authentifiée ? Recommencez ensuite la même tâche avec le modèle « imposition de motif sécurisé » et comparez les deux résultats. Si possible, exécutez un outil linter/SAST et comparez les résultats à l'autorégulation de l'IA.
liste de contrôle
- [ ] Je vérifie les résultats de l'IA à trois niveaux : précision, sécurité et licence.
- [ ] Je confirme que chaque fonction, API et package utilisé existe réellement.
- [ ] J'exécute les outils de compilation, de test, de linter et, si possible, SAST.
- [ ] J'impose des modèles sécurisés (requête paramétrée, validation des entrées, gestion des secrets) dès le début.
- [ ] Je vérifie la licence et les exigences des nouvelles dépendances.
- [ ] Je soumets un code critique à la sécurité pour approbation par un ingénieur compétent et je comprends que j'en suis responsable.