Du prompt à la pull request : modélisation des menaces pour le code écrit par des agents IA

Un agent de codage peut transformer une issue en une pull request crédible : il lit le dépôt, propose un plan, modifie des fichiers, met à jour les tests et prépare un diff prêt pour la revue. Le risque concret est que l’équipe évalue uniquement si la fonctionnalité fonctionne, sans se demander si le prompt initial décrivait réellement les données, les rôles, les abus possibles, les frontières de confiance (trust boundaries) et l’impact en production.

La modélisation des menaces (threat modeling) est utile précisément à cette étape : non pas comme un exercice bureaucratique, mais comme une méthode légère pour comprendre ce qui change, ce qui peut mal tourner, quels contrôles sont nécessaires et si la vérification effectuée est suffisante avant la fusion, le déploiement ou la mise en ligne.

Pour les CTO, tech leads et security champions, la question n’est pas “pouvons-nous utiliser des agents IA pour écrire du code ?”. La question utile est : comment transformer le prompt, le plan de l’agent et la pull request en une décision de risque traçable ?

Pourquoi la modélisation des menaces change avec le code écrit par des agents IA

Dans la modélisation des menaces applicatives traditionnelle, on part des fonctionnalités, des actifs, des acteurs, des flux de données et des frontières de confiance. Avec le code écrit par des agents IA, il faut ajouter un niveau : le parcours qui mène du prompt au diff.

Une requête comme “ajouter des invitations à l’équipe” peut générer un modèle de données, des API, des emails, des jetons temporaires, des rôles, des pages d’administration, des tests, des variables d’environnement et une migration. Chaque élément introduit des menaces différentes : invitations réutilisables, jetons trop longs dans les logs, rôles appliqués uniquement sur le frontend, endpoints non protégés, isolation des locataires (tenant isolation) incomplète, usurpation d’identité par email (spoofing), dépendances ajoutées sans revue. Le prompt contient rarement tout cela, car l’agent comble les vides avec des conventions plausibles. La modélisation des menaces sert à rendre explicites ces vides avant qu’ils ne deviennent du code accepté.

Les quatre questions à appliquer à chaque PR générée par IA

L’OWASP résume la modélisation des menaces en quatre questions : que construisons-nous, que peut-il mal tourner, que ferons-nous pour le gérer et avons-nous fait assez ? Dans le contexte du codage par IA, ces questions doivent être appliquées au prompt, au plan, au diff et à l’exécution.

Question	Dans le workflow avec agents IA, cela signifie
Que construisons-nous ?	Quelle tâche l’agent a-t-il reçue, quels fichiers a-t-il modifiés, quelles données et quels systèmes touche-t-il ?
Que peut-il mal tourner ?	Quels abus deviennent possibles sur les rôles, les données, les API, les outils, les pipelines et les surfaces exposées ?
Que faisons-nous ?	Quels contrôles sont intégrés dans le code, les tests, la configuration, la revue, le pipeline ou le processus ?
Avons-nous fait assez ?	Quelles preuves bloquent la fusion, quels risques sont acceptés et qui les gouverne ?

Cette structure évite deux erreurs fréquentes : traiter la modélisation des menaces comme une réunion abstraite ou la réduire à une simple checklist générique de vulnérabilités.

Partir des actifs, des données et des acteurs réels

La première étape n’est pas de lire le diff ligne par ligne, mais de comprendre quels actifs entrent dans le périmètre de la modification : données personnelles, documents clients, paiements, rôles administratifs, jetons, API internes, webhooks, dépôts, pipelines, logs, stockage, bases de données et services cloud.

Ensuite, il faut identifier les acteurs. Il ne suffit pas de distinguer “utilisateur” et “admin” : dans une fonctionnalité réelle, il peut exister un utilisateur invité, un utilisateur suspendu, un propriétaire, un admin partiel, un compte de service, une intégration externe, un membre d’un autre locataire, un client désactivé, un opérateur de support, un job planifié et un attaquant anonyme. Une matrice minimale acteur-action-ressource aide beaucoup plus qu’une revue générique. Pour chaque rôle, il faut se demander : quelles ressources peut-il lire, créer, modifier, supprimer ou exporter ? Le backend le vérifie-t-il vraiment, ou l’agent a-t-il implémenté le contrôle uniquement dans l’interface ?

Dessiner le flux de données, même de manière légère

Le modèle de menace ne doit pas forcément produire un diagramme parfait, mais il doit rendre visibles les flux de données, les magasins de données, les processus, les entités externes et les frontières de confiance. Si une PR traverse le frontend, les routes API, la base de données, le stockage objet, le fournisseur d’email, les webhooks et le pipeline de déploiement, le risque n’est pas au même endroit pour tous les composants.

Avec le code généré par IA, le flux de données doit également inclure des éléments souvent oubliés : prompt de l’agent, historique de chat, sortie des outils, logs de build, variables d’environnement, gestionnaire de secrets, fixtures de test, données de seed, snapshots et artefacts de déploiement. Un secret copié dans le prompt ou dans un log n’apparaît pas toujours dans le diff final, mais peut tout de même nécessiter une rotation.

La frontière la plus importante est celle où une entrée non fiable entre dans un composant fiable. Une valeur provenant d’un formulaire, d’un ticket, d’un document, d’un webhook, d’un fichier téléchargé, d’une sortie LLM ou d’un outil externe doit être validée avant de devenir une requête, une commande, une autorisation, un email, une décision ou une action en aval.

Écrire des cas d’abus (abuse cases), pas seulement des user stories

Les user stories décrivent l’utilisation prévue ; les cas d’abus décrivent ce qu’un utilisateur, un locataire, une intégration ou un contenu malveillant peut faire lorsque le système est utilisé hors séquence. Quelques exemples utiles pour une PR générée par IA :

Un utilisateur change l’ID dans l’URL et lit l’enregistrement d’un autre locataire.
Une invitation expirée est réutilisée pour obtenir un accès.
Un webhook est répété ou signé avec une mauvaise clé.
Un rôle en lecture seule appelle directement l’API de modification.
Un fichier téléchargé contient une charge utile (payload) qui finit dans un HTML, un parser ou un stockage.
Une injection de prompt dans un ticket pousse l’agent à modifier une politique ou à utiliser un outil.
Une migration expose des données de test ou des champs sensibles en production.

STRIDE reste utile comme stimulation — usurpation d’identité, altération, répudiation, divulgation d’informations, déni de service, élévation de privilèges — mais dans le code généré par IA, il doit être lié à des cas concrets, et non utilisé comme un acronyme décoratif.

Évaluer le plan de l’agent avant le diff

Beaucoup d’équipes commencent la revue lorsque la pull request est prête. Avec les agents IA, il convient d’anticiper : si l’agent propose un plan qui touche à l’authentification, aux rôles, aux données, au cloud, à la CI/CD, aux secrets ou aux dépendances, le modèle de menace doit commencer avant que le diff ne devienne volumineux.

Le plan de l’agent doit être lu avec des questions précises : crée-t-il de nouveaux endpoints ou expose-t-il des routes inexistantes auparavant ? Change-t-il des middlewares, des politiques, des vérifications de permissions ou des rôles ? Ajoute-t-il des dépendances, des scripts, des workflows ou des commandes de déploiement ? Modifie-t-il les tests de manière à confirmer sa propre implémentation ? Suppose-t-il qu’un contrôle côté client suffit ? Utilise-t-il des données réelles, des logs ou des secrets pour accomplir la tâche ? Si la réponse est oui à ne serait-ce qu’une de ces questions, la PR doit être divisée ou marquée comme à haut risque, car une revue efficace ne peut pas traiter de la même manière une correction de texte et une modification qui traverse les autorisations, la base de données et le pipeline.

Relier les menaces, les contrôles et les tests

Un modèle de menace utile produit des contrôles vérifiables. Si la menace est “l’utilisateur du locataire A lit les données du locataire B”, le contrôle n’est pas “gérer les autorisations” : c’est une politique côté serveur, une requête filtrée par locataire, des tests avec deux locataires distincts, des logs d’accès refusé et une revue du middleware.

Si la menace est “jeton d’invitation réutilisable”, les contrôles peuvent inclure l’expiration, l’usage unique, la liaison à un email ou à un locataire, le hachage du jeton au repos, le rate limiting et les logs d’audit. Si la menace est “injection de prompt via un ticket”, les contrôles sont la séparation entre les données et les instructions, la confirmation humaine pour les outils sensibles, une liste blanche d’actions et des tests avec des contenus hostiles.

Les scanners et les tests automatiques aident, mais ne démontrent pas à eux seuls que la logique métier, l’isolation des locataires, les autorisations et les frontières de confiance sont correctes dans le contexte réel.

Définir ce qui bloque la fusion et la mise en ligne

La modélisation des menaces ne doit pas se conclure par “nous avons parlé des risques” : elle doit produire des décisions. Bloquent la fusion ou la mise en ligne les preuves qui exposent des données, permettent une escalade de privilèges, contournent des autorisations, révèlent des secrets, rendent publics des stockages ou des bases de données, affaiblissent les pipelines, désactivent des contrôles de sécurité ou introduisent des dépendances critiques non évaluées.

D’autres points peuvent devenir une remédiation planifiée, mais seulement avec un propriétaire, une date et un risque résiduel clairs. Améliorer la journalisation, ajouter des alertes, renforcer la documentation ou rendre la matrice des rôles plus granulaire peut être planifié ; accepter un contrôle d’accès incertain avant la mise en ligne, non.

Checklist de modélisation des menaces pour les PR générées par IA

Identifier le prompt/tâche original, l’agent ou l’outil utilisé et les parties générées ou modifiées.
Lister les actifs, les données réelles, les rôles, les locataires, les systèmes externes et les secrets touchés.
Dessiner un flux de données minimal avec les frontières de confiance, les processus, les magasins de données et les entités externes.
Écrire des cas d’abus spécifiques à la fonctionnalité, pas seulement des vulnérabilités génériques.
Vérifier les autorisations au niveau de l’objet et l’isolation des locataires avec différents utilisateurs.
Contrôler si la PR modifie des middlewares, politiques, rôles, callbacks, redirections, CORS ou sessions.
Séparer la revue du code, la revue du pipeline, la revue des dépendances et la revue des tests.
Chercher des secrets dans les prompts, logs, dépôts, builds, workflows et configurations.
Exiger des tests négatifs dérivés des menaces, pas seulement des tests sur le chemin nominal.
Documenter ce qui bloque la fusion, ce qui bloque la mise en ligne et ce qui reste comme risque accepté.

Comment intégrer la méthode dans le cycle de développement

La modélisation des menaces pour le codage par IA doit être légère et répétable. Il n’est pas nécessaire d’avoir une session longue pour chaque commit, mais il faut des seuils clairs : une PR qui touche au texte ou à la mise en page peut suivre le flux normal, tandis qu’une PR qui touche à l’authentification, aux données, aux API, aux paiements, au cloud, à la CI/CD, aux secrets, aux rôles ou aux outils agentiques doit activer un contrôle plus rigoureux.

Dans le processus pratique, la tâche devrait inclure des contraintes de sécurité ; le plan de l’agent devrait être approuvé lorsqu’il touche des zones sensibles ; la PR devrait être petite ; les tests devraient couvrir les cas d’abus ; la revue devrait avoir des propriétaires techniques ; la décision finale devrait laisser une trace. Lorsque l’utilisation d’agents IA devient continue, cela devient un thème de Software Assurance Lifecycle : règles de développement, protection des branches, portes de sécurité, propriété, preuves, remédiation et contrôles récurrents.

Quand impliquer une vérification indépendante

Une vérification interne peut suffire pour des modifications isolées, sans données réelles, sans rôles, sans API exposées et avec des relecteurs experts. Une vérification indépendante est nécessaire lorsque le code généré ou modifié par l’IA entre dans un produit utilisé par des clients, des employés ou des partenaires, ou lorsque la PR touche aux autorisations, aux données, aux pipelines, au cloud, aux paiements, aux secrets ou à une logique critique.

Scénario	Risque principal	Contrôle conseillé
PR générée par IA sur auth, rôles, API, requêtes, secrets ou dépendances	Vulnérabilités ou régressions dans le code	Code Review
Adoption continue d’agents de codage dans le cycle d’ingénierie	Contrôles non répétables sur les tâches, PR et releases	Software Assurance Lifecycle
Décision sur la mise en ligne, risque résiduel, impacts business ou conformité	Risque non priorisé ou accepté sans propriétaire	Risk Assessment
Architecture, flux de données, frontières de confiance et intégrations complexes	Hypothèses de conception faibles	Secure Architecture Review
App ou API déjà exposées aux utilisateurs et clients	Comportement abusable de l’extérieur	Web Application Penetration Testing

Le choix ne doit pas être un package standard. Si le risque est dans le diff, il faut une Code Review. Si le risque est dans le processus d’adoption des agents, il faut un Software Assurance Lifecycle. Si l’équipe doit décider du risque résiduel, des priorités et de l’impact, il faut un Risk Assessment. Si la modification traverse l’architecture, les flux de données et les intégrations, il faut une revue de conception.

Preuves à préparer

Pour rendre la vérification efficace, il faut des dépôts, des pull requests, la description de la tâche, le prompt ou l’issue de départ, la liste des agents ou outils utilisés, les parties générées ou modifiées, les rôles applicatifs, le schéma de données, les API exposées, les intégrations, les workflows CI/CD, les variables d’environnement, les dépendances principales et les environnements disponibles.

Des preuves de processus sont également utiles : qui a approuvé le plan de l’agent, qui a révisé le diff, quels tests ont été ajoutés, quelles menaces ont été prises en compte, quels risques ont été acceptés et quelles remédiations ont été planifiées. Ces informations évitent une revue aveugle, car le code ne raconte pas toujours pourquoi une décision a été prise, quelles hypothèses l’agent a faites ou quel risque l’équipe pensait accepter.

Questions fréquentes

La modélisation des menaces sert-elle aussi pour une seule PR générée par IA ?
Oui, si la PR touche aux données, rôles, API, secrets, paiements, pipelines, cloud ou logique métier. Pour des modifications mineures, un modèle de menace léger suffit, mais les questions sur les actifs, acteurs, flux et abus restent utiles.
Modélisation des menaces et Code Review sont-ils la même chose ?
Non. La modélisation des menaces définit ce qui peut mal tourner et quels contrôles sont nécessaires. La Code Review vérifie si le code, le diff et les tests implémentent ces contrôles sans régressions.
STRIDE suffit-il pour le code généré par IA ?
STRIDE est utile pour ne pas oublier des familles de menaces, mais il doit être adapté aux prompts, agents, dépôts, pipelines, appels d’outils, secrets et données d’exécution. La partie importante est de transformer chaque menace en un contrôle vérifiable.
Les tests automatiques générés par l’IA suffisent-ils ?
Non. Les tests générés par l’IA ont tendance à couvrir le chemin prévu. Il faut aussi des tests négatifs, des cas multi-utilisateurs, des abus de rôles, l’isolation des locataires, des entrées manipulées et des vérifications sur les pipelines et configurations.
Quand un Risk Assessment est-il nécessaire ?
Lorsque l’équipe doit décider d’accepter un risque, prioriser des remédiations ou lier le projet à des impacts métier, données personnelles, conformité, fournisseurs ou continuité opérationnelle.

[Callforaction-SAL-Footer]

ISGroup Conseil en Cybersécurité

Modélisation des menaces pour le code IA : du prompt à la pull request