Modéliser les menaces d’un processus de développement avec l’IA

Choisir un scénario limité

Commencez par un processus compréhensible. Par exemple, un agent lit une issue, modifie un dépôt, exécute des tests et ouvre une pull request. Incluez les systèmes qui rendent ces actions possibles.

Listez les actifs importants : code source, informations client, identifiants secrets, artefacts de livraison et disponibilité du service. Identifiez leurs responsables. Identifiez ensuite les personnes et les systèmes qui peuvent lire ou modifier chaque actif.

L’OWASP recommande de modéliser le système, d’identifier les menaces, de choisir des réponses et de valider le résultat. Utilisez cette méthode tôt et actualisez-la à mesure que le système évolue. Conseils de modélisation des menaces.

Dessiner les limites de confiance

Pour le processus fictif allant de l’issue à la PR, représentez ces connexions :

Issue → agent → dépôt → exécuteur de tests → stockage des artefacts → déploiement

Ajoutez le fournisseur du modèle et le stockage des secrets. Signalez les endroits où le contenu provient d’une source moins fiable. Signalez les endroits où une identité acquiert une nouvelle capacité, comme le passage de la lecture d’une issue à l’écriture dans les fichiers du dépôt.

Le schéma de l’application ne montre pas, à lui seul, tous les risques du développement. Une base de production peut être privée tandis qu’un job CI expose un identifiant secret. Incluez les environnements temporaires et l’accès du support lorsqu’ils interviennent dans le scénario.

Décrire un scénario concret de défaillance

Évitez les entrées comme « L’IA pourrait être dangereuse ». Décrivez un acteur, une action, un actif touché et une conséquence. Précisez les conditions nécessaires à la réalisation du scénario.

Ce sont des exemples, pas une liste complète de menaces. Vos données, vos outils et votre environnement d’exploitation déterminent les scénarios pertinents.

Choisir une réponse et lui attribuer un responsable

Priorisez les conséquences et l’exposition crédible. Ne donnez pas à un score numérique une précision que vous ne possédez pas. Consignez les incertitudes et les preuves qui pourraient modifier la priorité.

Une réponse peut supprimer la capacité risquée, réduire son périmètre, ajouter un contrôle ou accepter un risque résiduel défini. L’acceptation nécessite un responsable habilité et une justification. Elle ne doit pas être la conclusion non revue d’un agent.

Transformez la réponse choisie en travail assorti d’une condition d’acceptation observable. « Améliorer la sécurité de l’agent » est difficile à vérifier. « Le job de test ne peut pas lire le secret de production » définit une limite vérifiable.

Réexaminer après les modifications importantes

Un nouveau connecteur, un autre chemin vers le modèle, un environnement ou une permission peut modifier le modèle de menaces. Ajoutez ces changements aux déclencheurs de réexamen. Utilisez aussi les incidents et les évaluations échouées pour actualiser les hypothèses.

Essayez l’exercice d’analyse des risques pour modifier les données, les pouvoirs, le public et les conditions de reprise d’un scénario. Le résultat suggère des questions. Il ne remplace pas un modèle de menaces propre au système et n’autorise pas le travail.