ISGroup Conseil en Cybersécurité

Devin par Cognition : comment vérifier la sécurité du code produit par des agents IA

[Callforaction-WAPT]

Devin de Cognition et l’ingénierie logicielle autonome : comment vérifier le code produit par des agents de bout en bout

Devin fait passer l’IA dédiée au développement à un niveau supérieur par rapport aux assistants classiques. Il ne se contente pas de compléter du code ou de suggérer des modifications dans un fichier : il peut prendre en charge des tâches d’ingénierie complètes, travailler dans un environnement cloud dédié, utiliser un terminal, un navigateur et un système de fichiers, installer des dépendances, exécuter des tests, corriger des bugs et préparer des pull requests.

Pour les CTO, les responsables d’ingénierie et les sociétés de développement, la question pertinente n’est pas seulement de savoir si Devin produit du code fonctionnel. Il s’agit de comprendre comment vérifier un résultat généré par un agent qui a parcouru l’intégralité du cycle de la tâche : ticket, dépôt, environnement, commandes, tests, journaux, intégrations et pull requests. Avant la fusion (merge) ou le déploiement, la question est concrète : qu’est-ce que Devin a modifié dans le code, les tests, les dépendances, les secrets, les configurations, les API et le comportement de l’application ?

Pourquoi l’ingénierie logicielle autonome change la revue de code

Avec un assistant traditionnel, le relecteur voit souvent une suggestion circonscrite. Avec Devin, le résultat peut être une PR complète : l’agent a planifié, exploré la base de code, lancé des commandes, modifié des fichiers, mis à jour des tests, installé des paquets et vérifié son propre travail. Cela rend la revue structurellement plus difficile, car le diff final ne raconte pas toujours tout : il ne montre pas les commandes exécutées, les erreurs rencontrées, les journaux lus, les données vues dans le navigateur, les paquets essayés et écartés, ni les hypothèses faites pour valider la suite de tests.

Une PR peut sembler prête parce que les tests sont au vert, mais contenir une régression d’autorisation, une dépendance non approuvée ou un repli permissif. Le risque principal n’est pas que Devin se trompe dans le code : c’est d’accepter un cycle autonome comme s’il était équivalent à une revue humaine complète. L’équipe doit être capable de reconstruire ce qui s’est passé entre le ticket et la PR.

Espace de travail cloud, terminal et navigateur

Devin travaille comme un agent autonome dans un environnement dédié. La documentation officielle décrit sa capacité à écrire, exécuter et tester du code ; la version entreprise parle d’espaces de travail avec shell, navigateur et éditeur de code, ainsi que de modèles de déploiement avec des composants cloud et des devbox. Cette architecture est utile car l’agent peut poursuivre le travail même lorsque le développeur est absent, mais c’est aussi une surface qu’il faut gouverner avec attention.

Une commande shell peut installer des paquets, lire des variables d’environnement, modifier des fichiers, lancer des migrations, exécuter des tests, démarrer des services ou interagir avec des CLI cloud. Le navigateur peut voir des tableaux de bord, des écrans internes, des données de test, des outils de monitoring et des flux applicatifs. Avant d’utiliser Devin sur des dépôts d’entreprise, il faut décider explicitement quels environnements il peut atteindre. Des comptes de test, des données synthétiques, des dépôts sur liste blanche et des secrets limités réduisent le risque ; les secrets de production, les tableaux de bord avec des données réelles, les API en direct et les environnements cloud sensibles ne devraient pas être disponibles par défaut.

PR agentiques : le test au vert ne suffit pas

Devin peut générer des PR qui résolvent des tickets, des bugs ou des tâches de backlog. La PR est le point où l’équipe reprend le contrôle, et si ce contrôle se limite à vérifier que le code compile et que les tests passent, la valeur de l’autonomie devient aussi son point faible.

Les domaines à vérifier manuellement incluent l’authentification, les autorisations, l’isolation des tenants, les API, le middleware, la validation des entrées, la gestion des erreurs, la journalisation, les secrets, les dépendances, les pipelines et les configurations de déploiement. Une modification qui corrige un bug de connexion peut déplacer un contrôle dans le frontend ; un correctif sur une API peut accepter un paramètre côté client qui était auparavant dérivé du serveur ; un test généré en même temps que le code peut confirmer le nouveau comportement au lieu de le challenger. Chaque PR générée par Devin sur des zones sensibles devrait faire l’objet de relecteurs explicites, de protection de branche, de tests négatifs et d’une lecture du diff par ensemble de changements. Si la modification expose une application web ou une API, le comportement réel doit être testé avec une approche WAPT, et pas seulement avec des tests unitaires.

Autorisations et logique métier

De nombreuses vulnérabilités introduites par des agents autonomes ne cassent pas la fonctionnalité : l’application continue de faire ce que le ticket demandait, mais elle perd une contrainte. Un utilisateur peut lire les données d’un autre tenant, un rôle peut appeler une route non prévue, un flux de travail peut sauter un état, une validation côté serveur peut être considérée comme dupliquée et supprimée.

C’est pourquoi la revue d’une PR Devin doit inclure des cas d’abus (abuse cases). Un compte avec des privilèges bas doit essayer d’appeler des points de terminaison administratifs ; un utilisateur d’un autre tenant doit essayer de lire ou de modifier des enregistrements qui ne lui appartiennent pas ; une invitation expirée doit être réutilisée ; une requête hors séquence doit essayer d’altérer l’état d’une commande, d’un dossier ou d’un flux de travail. La logique métier n’est pas toujours visible par les scanners automatiques : une lecture du domaine est nécessaire. Quelles opérations nécessitent une approbation ? Quelles données sont séparées par client, rôle, groupe ou pays ? Quelles conditions ne doivent pas être contrôlables par le client ?

Secrets dans le flux de travail autonome

Lorsqu’un agent travaille de bout en bout, les secrets peuvent apparaître à plusieurs endroits : dépôts, fichiers .env, historique du shell, journaux de test, sorties de build, invites (prompts), commentaires de code, description de PR, artefacts CI/CD, navigateur et outils de monitoring. La documentation entreprise de Devin indique l’utilisation d’une fonction Secrets pour partager des identifiants si nécessaire, mais cela n’élimine pas le risque applicatif : le code généré peut toujours imprimer une valeur, la transmettre au frontend, l’inclure dans un test ou la copier dans un fichier d’exemple.

Avant la fusion, un scan des secrets sur le diff et l’historique pertinent est nécessaire. Si une clé s’est retrouvée dans un prompt, un journal, un artefact ou une PR, elle doit être renouvelée. Les accès accordés à Devin doivent être limités à la tâche : jetons de développement, portées minimales, dépôts et environnements séparés, aucun secret de production sauf si strictement nécessaire et approuvé.

Dépendances, scripts et chaîne d’approvisionnement

Un agent autonome qui veut fermer un ticket peut ajouter des bibliothèques, mettre à jour des fichiers de verrouillage (lockfiles), changer des scripts de build ou installer des outils pour reproduire un bug. Cela peut être correct du point de vue fonctionnel et risqué du point de vue de la chaîne d’approvisionnement. Chaque modification apportée à package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, aux lockfiles ou aux scripts postinstall doit être révisée : il faut comprendre pourquoi la dépendance a été introduite, si elle est maintenue, quelle licence elle possède, quelles dépendances transitives elle apporte, si des vulnérabilités connues existent et si les scripts exécutent du code non prévu.

La revue des dépendances est particulièrement importante lorsque Devin résout des erreurs de build ou de test, car dans ces cas, l’agent peut choisir la voie la plus rapide : remplacer une bibliothèque, abaisser une version, désactiver un contrôle ou ajouter un paquet d’assistance. L’équipe doit décider si ce choix est acceptable pour le produit, et pas seulement s’il résout le problème immédiat.

Intégrations : GitHub, Slack, Linear, Datadog, AWS

Devin peut s’insérer dans le flux de travail de l’équipe via des outils de ticketing, des dépôts, des chats et du monitoring, rendant naturel la délégation de tâches depuis Linear ou Jira, les commentaires dans Slack, l’ouverture de PR sur GitHub ou GitLab, la consultation de journaux et l’intervention sur des problèmes réels. Chaque intégration, cependant, élargit le contexte et les permissions disponibles pour l’agent.

Une intégration GitHub trop large peut donner accès à des dépôts inutiles ; un fil Slack peut contenir des données client ou des jetons ; un outil d’observabilité peut montrer des charges utiles sensibles, des traces de pile (stack traces), des en-têtes, des requêtes ou des points de terminaison internes ; un accès AWS peut permettre des modifications sur des ressources non liées au ticket. La configuration des intégrations doit suivre le principe du moindre privilège. Des dépôts sur liste blanche, des canaux dédiés, des permissions en lecture seule lorsque cela suffit, des jetons séparés par environnement et un contrôle périodique des accès réduisent le risque de manière significative.

Déploiement, pipelines et configurations

Devin peut être utilisé pour corriger des CI, mettre à jour des Dockerfiles, corriger des configurations, modifier des pipelines ou préparer des déploiements. Ces modifications ne sont pas neutres : elles changent la façon dont le code arrive en production. Une PR qui “répare le pipeline” peut élargir les permissions, exposer des secrets dans les journaux, désactiver des étapes de sécurité, changer la protection des branches, rendre un Dockerfile plus permissif, modifier des variables d’environnement ou sauter des tests. Un correctif sur le déploiement peut introduire un mode débogage, un CORS ouvert, des erreurs détaillées ou l’absence de limitation de débit (rate limit).

Les modifications apportées aux CI/CD, conteneurs, IaC, configurations cloud, env, secrets, feature flags et scripts de déploiement doivent faire l’objet d’une revue séparée. Si la tâche touche au cloud, au réseau, à l’IAM, aux buckets, aux bases de données ou aux pipelines, le périmètre dépasse la simple revue de code et peut nécessiter une évaluation de la sécurité cloud (Cloud Security Assessment) ou une revue de l’architecture sécurisée (Secure Architecture Review).

Piste d’audit : reconstruire le pourquoi, pas seulement le quoi

Dans l’ingénierie logicielle autonome, le diff final ne suffit pas. Il faut une piste d’audit qui relie le ticket, le prompt, la session, les commandes, les tests, les journaux, les erreurs, les PR et les approbations : sans cette chaîne, il est difficile de comprendre pourquoi l’agent a choisi une solution et quelles alternatives il a écartées. La piste d’audit est également utile pour la réponse aux incidents : si une vulnérabilité arrive en production, l’équipe doit pouvoir comprendre quelle tâche l’a introduite, quels contrôles ont été passés, qui a approuvé la PR, quels tests manquaient et quelles données ou quels secrets étaient disponibles pour l’agent.

Conserver les journaux et les trajectoires ne signifie pas accumuler des données sensibles. Cela signifie définir ce qu’il faut enregistrer, comment rédiger les secrets, qui peut accéder aux journaux d’audit, combien de temps les conserver et comment les utiliser pour améliorer les politiques au fil du temps.

Checklist avant la fusion (merge)

PR, diff et tests

  • Révisez la PR pour des ensembles de changements petits et vérifiables.
  • Vérifiez les tests ajoutés ou modifiés et assurez-vous qu’ils incluent des cas négatifs, pas seulement le chemin heureux (happy path).
  • Si l’agent a mis à jour des snapshots, des mocks ou des tests pour faire passer la suite, lisez attentivement ces modifications.

Commandes et environnement

  • Contrôlez les commandes shell exécutées, les paquets installés, les scripts lancés, les migrations, les builds et les tests.
  • Vérifiez que l’environnement ne contenait pas de secrets de production ou d’accès à des systèmes réels non nécessaires.
  • Si des navigateurs ou des tableaux de bord ont été utilisés, assurez-vous qu’aucune donnée sensible n’a été exposée.

Auth, données et API

  • Testez les autorisations côté serveur, les rôles, l’isolation des tenants, les failles IDOR/BOLA, les points de terminaison non visibles dans l’UI, les jetons expirés, les entrées malveillantes et les abus de logique métier.
  • Les zones modifiées par Devin ne doivent pas être acceptées simplement parce que le ticket est marqué comme fermé.

Secrets et dépendances

  • Effectuez un scan des secrets sur le diff, les journaux, les artefacts et l’historique pertinent.
  • Renouvelez ce qui a été exposé.
  • Révisez les nouvelles dépendances, les lockfiles, les scripts d’installation/build/test, les licences et les vulnérabilités connues.

Pipelines et déploiement

  • Contrôlez les Dockerfiles, CI/CD, la protection des branches, les secrets dans les pipelines, les variables d’environnement, les feature flags, l’IaC, les configurations cloud et les scripts de déploiement.
  • Chaque modification qui affecte le chemin vers la production doit avoir un propriétaire et une approbation dédiée.

Quand une revue interne suffit-elle et quand une vérification indépendante est-elle nécessaire ?

Une revue interne peut suffire si Devin a travaillé sur des tâches non exposées, sans données réelles, sans authentification, sans nouvelles dépendances, sans pipelines et sans intégrations opérationnelles. Même dans ce cas, l’équipe devrait conserver les diffs, les tests et les commandes principales.

Une vérification indépendante est nécessaire lorsque Devin a modifié l’authentification, les autorisations, les API, les données, les dépendances, les secrets, les pipelines, le cloud, le déploiement ou la logique applicative critique. Elle est également nécessaire lorsque les PR agentiques entrent durablement dans le cycle de développement et que l’équipe doit définir des politiques, une protection des branches, des relecteurs, une journalisation, une gestion des secrets et des seuils de risque. Le but n’est pas de ralentir Devin : c’est de séparer ce qui peut être délégué de ce qui doit être vérifié.

Comment ISGroup peut vérifier le code et les flux de travail produits par Devin

Le contrôle change en fonction de ce que Devin a modifié. Si le risque se situe dans la PR, dans le code applicatif, dans la logique d’autorisation, dans les secrets ou dans les dépendances, la Revue de Code aide à identifier les vulnérabilités et les régressions avant la fusion. Si le résultat est une application web ou une API exposée, le Test de Pénétration d’Application Web vérifie le comportement réel de l’extérieur.

Si Devin a touché à… Risque principal Contrôle conseillé
PR, code applicatif, middleware, auth, rôles, dépendances Vulnérabilités ou régressions dans le code Revue de Code
App web, API, routes publiques, flux utilisateurs exposés Comportements abusables de l’extérieur Test de Pénétration d’Application Web
Pipeline, déploiement, config cloud, IaC, secrets en CI/CD Mauvaise configuration ou privilèges excessifs Évaluation de la Sécurité Cloud
Architecture, frontière de confiance, intégrations, données sensibles Hypothèses architecturales faibles Revue d’Architecture Sécurisée
Utilisation continue de Devin dans le cycle d’ingénierie Contrôles non répétables sur les PR agentiques Cycle de Vie de l’Assurance Logicielle

Le choix du contrôle dépend de ce qui a réellement changé : code, comportement exposé, pipeline, intégrations ou processus de développement. Avant la mise en ligne, il convient de délimiter ce périmètre et de vérifier le risque effectif sur l’application.

Évidences à préparer avant la revue

Avant d’impliquer une équipe externe, il convient de rassembler les tickets, les PR, les branches, les diffs, les tests, les commandes exécutées, les journaux disponibles, les dépendances ajoutées, les configurations modifiées, la liste des dépôts accessibles, les intégrations actives et la description des environnements utilisés par Devin. Sont également utiles les informations sur les secrets accordés à l’agent, les politiques de protection des branches, les relecteurs impliqués, la CI/CD, les scripts de déploiement, les configurations cloud, les données traitées, les systèmes de monitoring consultés et les décisions déjà prises sur les risques acceptés ou les remédiations planifiées.

FAQ

  • Devin teste son propre code : est-ce suffisant pour aller en production ?
  • Non. Les tests de l’agent peuvent confirmer que le ticket a été résolu, mais ils ne prouvent pas à eux seuls que les autorisations, la logique métier, les secrets, les dépendances et les configurations sont sécurisés.
  • Quel est le risque principal des PR générées par Devin ?
  • Accepter une PR parce qu’elle est complète et qu’elle passe les tests, sans reconstruire les commandes, les dépendances, les décisions et l’impact sur l’auth, les API, les données et les pipelines.
  • Devin peut-il gérer les secrets de manière sécurisée ?
  • Il peut offrir des mécanismes dédiés pour partager des identifiants, mais le code généré peut toujours journaliser, copier ou exposer des secrets. Il faut contrôler l’utilisation, la portée, la rotation et les artefacts.
  • Quand le Cycle de Vie de l’Assurance Logicielle est-il nécessaire ?
  • Lorsque Devin devient une partie stable du cycle d’ingénierie : les tickets, les PR, les revues, la CI/CD, le déploiement et la remédiation doivent avoir des règles répétables, et non des décisions au cas par cas.
  • Quand le Test de Pénétration d’Application Web est-il nécessaire ?
  • Lorsque le code produit ou modifié par Devin expose des applications web, des API ou des flux accessibles par des utilisateurs externes, des clients, des partenaires ou des employés.

[Callforaction-WAPT-Footer]

Sources et références utiles

In

, , ,

Leave a Reply

Your email address will not be published. Required fields are marked *