L'IA écrit le code et installe des paquets : 5 vérifications avant de mettre l'application en production

Un assistant IA a écrit un espace personnel, connecté la base de données et affiché une page qui fonctionne. Ouvrez maintenant l'API au nom d'un autre utilisateur : si elle renvoie le profil de quelqu'un d'autre, l'application ne peut pas être mise en production. Des tests au vert ne l'excluent pas, surtout s'ils ne vérifient que la connexion réussie et le chargement de la page.

Habr a publié une analyse pratique de la sécurité du code écrit avec l'IA et des agents qui exécutent ce code. Son idée utile est simple : en accélérant le développement, l'équipe obtient aussi davantage d'actions à vérifier. L'assistant propose des bibliothèques, installe des dépendances, lit des fichiers et exécute des commandes. Chacune de ces actions exige des limites d'accès claires.

Pour le développeur, c'est l'occasion de revoir sa relecture de code. Pour le chef de produit et le fondateur, c'est le moment d'ajouter au critère « la démo fonctionne » plusieurs vérifications sans lesquelles une mise en production reste une loterie.

Commencez par le profil d'un autre

Les vérifications les plus utiles semblent souvent ennuyeuses. Un utilisateur peut-il lire la commande d'un autre en remplaçant l'identifiant dans la requête ? La table est-elle accessible sans autorisation ? Le nom saisi se retrouve-t-il directement dans le HTML ?

L'article donne l'exemple d'une application sur Supabase. Une clé publique dans le frontend n'implique pas à elle seule une fuite : l'accès aux lignes doit être limité par des politiques Row Level Security. L'erreur survient lorsque l'application est déjà connectée à la base alors que les règles d'accès ne sont pas encore configurées ou autorisent trop de choses.

Il faut le vérifier par des scénarios distincts : requête sans jeton, requête d'un utilisateur sur son propre objet, et requête du même utilisateur sur l'objet d'un autre. Ce dernier cas est particulièrement important. Vérifier que « la personne est connectée » ne répond pas à la question « ce document lui appartient-il ».

L'analyse statique aide à repérer les opérations dangereuses et les fuites de secrets. Mais sans les règles de votre produit, elle ne peut généralement pas déterminer qui a le droit de lire telle commande. Il faut ici des revues et des contrôles d'autorisation.

Une dépendance commence par la vérification du nom

Le deuxième problème apparaît avant même le lancement de l'application. Le modèle peut proposer le nom plausible d'une bibliothèque qui n'a jamais existé. Si un attaquant enregistre ce nom, la prochaine installation amènera son code dans l'environnement du développeur.

Imaginez : l'agent a besoin d'une bibliothèque de traitement de documents. Il propose un paquet, l'installe et poursuit son travail. Le développeur voit une fonction prête, mais personne n'a vérifié l'origine de la dépendance. Dans certains écosystèmes, du code étranger peut s'exécuter dès l'installation.

C'est pourquoi chaque nouvelle dépendance doit être comparée à la documentation officielle du projet. Ensuite, il faut figer la version et utiliser un fichier lock lors du build. Cela rend l'installation reproductible, mais ne prouve pas à lui seul que le paquet choisi est sûr.

Interdire les scripts d'installation a aussi ses limites : une bibliothèque peut exécuter du code malveillant plus tard, lorsque l'application l'importe. Quant à un scanner de vulnérabilités connues, il peut manquer une publication malveillante récente. Ces mesures complètent la vérification de l'origine du paquet.

L'agent a besoin de limites de pouvoirs

Quand l'assistant obtient un terminal, le risque dépasse le code généré. Il peut installer un paquet, lire un fichier de clés ou exécuter une instruction trouvée dans le README de quelqu'un d'autre. Un texte externe devient dangereux si l'agent le prend pour une autorisation d'agir.

La réponse pratique consiste à accorder l'accès en fonction de la tâche. Pour corriger une interface, on n'a généralement besoin ni des secrets de production ni du droit de publier des paquets. Les commandes d'installation de dépendances, l'accès aux secrets et les modifications d'infrastructure méritent un contrôle distinct.

Avant la prochaine mise en production, on peut retenir cinq vérifications : l'accès aux objets d'autrui, l'origine des nouveaux paquets, la reproductibilité de l'installation, les secrets dans le code et les journaux, les pouvoirs de l'agent. Ce sont des points précis où une petite erreur se transforme en fuite ou en exécution de code étranger.

L'analyse elle-même reste une synthèse : des exemples isolés et des études ne permettent pas de calculer la probabilité d'une attaque contre votre service en particulier. Demander au modèle de « vérifier la sécurité » ne donne pas non plus de garantie. Le résultat devient utile lorsque l'équipe transforme les recommandations en conditions de mise en production vérifiables et désigne un responsable pour chacune d'elles.