Configurer les environnements sandbox et la gestion des secrets dans Devin pour des builds et des tests d'intégration sécurisés

Pour exécuter des builds automatisés et des tests d'intégration en toute sécurité avec Devin, les équipes d'ingénierie s'appuient sur un modèle de sécurité à trois niveaux : des Blueprints déclaratifs qui créent des environnements de machines isolés et reproductibles à partir d'instantanés (snapshots) ; une gestion hiérarchisée des secrets (Secret Management) qui injecte les identifiants exclusivement à l'exécution sous forme de variables d'environnement, sans jamais les figer dans les images ou le code ; et des mécanismes rigoureux de sandbox, englobant les instances éphémères dans Devin Cloud, l'isolation au niveau de l'OS par bubblewrap dans le CLI et les nœuds locaux avec Devin Outposts pour les infrastructures privées.

Contrairement aux extensions traditionnelles de complétion de code, Devin fonctionne comme un ingénieur logiciel autonome. Il clone des dépôts Git, installe des paquets système, démarre des services en arrière-plan, lance des suites de tests et pilote des navigateurs web pour valider les fonctionnalités de bout en bout. Accorder un accès au terminal et au réseau à un agent autonome sans un cloisonnement strict expose l'entreprise à des fuites de données sensibles, à des appels non contrôlés sur les réseaux internes ou à la corruption de la machine hôte.

1. Architecture des environnements dans Devin : Modèles de calcul et isolation

Devin s'adapte aux contraintes de conformité, aux topologies réseau et aux politiques de sécurité grâce à trois modes d'exécution :

Sandboxes dans Devin Cloud

En mode cloud par défaut, chaque session de Devin s'exécute dans une machine virtuelle éphémère et isolée, supervisée par Cognition.

• Isolation par instantané : L'environnement est décrit dans un Blueprint déclaratif. À la construction du blueprint, un snapshot chiffré de la machine est généré. Les sessions suivantes et les builds différentiels démarrent systématiquement à partir de cette base saine.
• État éphémère : Toutes les modifications apportées pendant l'exécution des tests (fichiers temporaires, modifications de bases de données, journaux) sont cantonnées au conteneur de la session et sont définitivement détruites à sa fermeture.

Isolation au niveau de l'OS avec Devin CLI

Lors de l'utilisation du CLI de Devin sur des postes locaux ou sur des runners de CI d'entreprise, l'option --sandbox active un cloisonnement strict au niveau du système d'exploitation :

• Confinement du système de fichiers : Les droits d'écriture sont restreints au répertoire de travail actif et aux chemins explicitement déclarés dans les portées Write(...). Les bibliothèques partagées, les répertoires système et les profils utilisateurs restent en lecture seule.
• Règles d'exclusion (Deny Rules) : Tout chemin spécifié dans une règle d'interdiction Read(...) est totalement masqué aux commandes exécutées dans la sandbox, empêchant les scripts de test d'accéder à des fichiers sensibles de l'hôte (tels que ~/.ssh ou ~/.aws).
• Verrouillage par défaut en cas d'erreur (Fail-Closed) : Si les dépendances nécessaires au bac à sable sont absentes sous Linux (comme bubblewrap/bwrap ou socat), le CLI refuse de démarrer plutôt que de fonctionner sans protection. De même, l'usage de --sandbox sur Windows interrompt immédiatement l'exécution afin d'éviter toute faille de sécurité involontaire.
• Filtrage réseau : Des listes d'autorisation (allowed_domains) et de refus (denied_domains) peuvent être définies dans la configuration utilisateur afin de restreindre le trafic sortant uniquement aux serveurs mock de test et aux registres privés autorisés.

Devin Outposts (Infrastructure auto-hébergée)

Pour les organisations soumises à de strictes obligations de souveraineté des données ou dont les tests d'intégration doivent accéder à des bases de données internes et à des microservices non exposés sur Internet, Devin Outposts dissocie le plan de contrôle du plan de données :

• Principe de fonctionnement : La planification et le raisonnement de l'agent s'effectuent sur le cloud de Cognition, tandis que l'exécution des commandes, l'édition des fichiers et les tests se déroulent exclusivement sur les serveurs de l'entreprise (machines virtuelles, serveurs dédiés ou clusters Kubernetes).
• Connexion sortante uniquement : Les machines workers exécutent la commande devin worker start --outpost=<nom_outpost> et n'établissent que des liaisons HTTPS sortantes vers Devin Cloud. Aucun port d'entrée n'a besoin d'être ouvert dans le pare-feu et aucune adresse IP publique n'est requise.
• Périmètre de données confidentiel : Le code source propriétaire, les identifiants des bases de données de test et les journaux ne quittent jamais le réseau privé.

2. Gestion hiérarchique des secrets et injection sans persistance

L'une des vulnérabilités les plus fréquentes dans les pipelines automatisés réside dans la présence de clés d'accès dans les commits Git, les couches d'images de conteneurs ou les logs publics. Devin résout cette problématique grâce à une gestion centralisée et chiffrée des secrets.

Portées de visibilité (Scopes)

• Secrets d'organisation et d'entreprise (Organization Secrets) : Configurés dans Settings > Resources > Secrets, ils sont chiffrés au repos et accessibles à l'ensemble de l'organisation. Au niveau Enterprise, ils peuvent être marqués comme Build only : ils ne sont disponibles que lors de la phase de création du snapshot de base et sont systématiquement effacés avant le clonage du code et l'ouverture des sessions de test.
• Secrets spécifiques au dépôt (Repository Secrets) : Définis dans l'éditeur de Blueprints du dépôt concerné (Settings > Environment > Blueprints > [Dépôt] > Secrets). Ils ne sont injectés que lorsque Devin travaille sur ce projet. Les membres ne disposant pas de droits d'administration voient le nom des variables mais ne peuvent jamais afficher la valeur déchiffrée.
• Secrets personnels et de session (Personal & Session Secrets) : Réservés au développeur pour ses phases de débogage ou fournis temporairement lors d'une session interactive, avec destruction automatique dès la clôture de la conversation.

Principes d'injection sans figeage ("Zero-Baking")

• Association dynamique aux variables d'environnement : Les secrets déclarés dans l'interface sont injectés sous forme de variables d'environnement (par exemple $TEST_DB_PASSWORD, $STRIPE_TEST_KEY) uniquement lors de l'exécution des commandes. Ils ne doivent en aucun cas être inscrits dans les fichiers YAML des Blueprints ou dans des fichiers .env commités.
• Nettoyage automatique des instantanés (Scrubbing) : Lorsque Devin enregistre un instantané de machine, l'ensemble des secrets injectés est purgé de la mémoire et du disque, garantissant qu'aucune donnée sensible ne soit gravée dans l'image machine.
• Fichiers de configuration en pièce jointe : Les outils de build nécessitant des fichiers d'authentification (comme le settings.xml de Maven ou le .npmrc privé) peuvent être téléversés sous forme de pièces jointes dans le Blueprint. Devin les place dans ~/.files/ et génère automatiquement des variables telles que $FILE_SETTINGS_XML, permettant aux scripts de les copier sans jamais inclure d'identifiants dans Git.
• Cookies de session et TOTP pour les tests web : Devin prend en charge les cookies Chromium encodés en base64 ainsi que les clés de double authentification (TOTP). Lors des tests d'intégration de bout en bout, le navigateur intégré peut accéder aux interfaces de staging déjà authentifié, évitant ainsi d'exposer les mots de passe maîtres des administrateurs.

3. Guide de configuration étape par étape

Méthode standard pour mettre en place une chaîne de compilation et de tests d'intégration sécurisée :

Étape 1 : Structurer le Blueprint déclaratif

Dans l'éditeur de Blueprints, séparez nettement l'installation des outils système de la gestion des dépendances :

# 1. initialize : Exécuté uniquement lors des builds complets pour installer les runtimes
initialize: |
  curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
  apt-get update && apt-get install -y nodejs postgresql-client

# 2. maintenance : Installation rapide et autonome des dépendances du projet
maintenance:
  - name: "Installer les dépendances du projet"
    run: npm ci

# 3. knowledge : Consignes d'exécution destinées à Devin
knowledge: |
  Commande pour les tests unitaires : npm test
  Commande pour les tests d'intégration avec base locale : npm run test:e2e

Étape 2 : Associer des secrets dédiés aux tests

1. Rendez-vous dans Settings > Environment > Blueprints et sélectionnez votre dépôt.
2. Ouvrez l'onglet Secrets et cliquez sur Create secret.
3. Renseignez uniquement des identifiants restreints à l'environnement de test :
   • E2E_DATABASE_URL : Chaîne de connexion vers un conteneur de test ou une base de staging isolée.
   • TEST_API_KEY : Clé d'API limitée à des données simulées (mock).
   • DEVIN_AUTH_COOKIE : Cookie de session temporaire pour les validations d'interface utilisateur.
4. Précisez dans le champ Note l'usage et la politique de rotation (ex. : "Strictement réservé à la QA Staging ; rotation mensuelle").

Étape 3 : Délimiter les accès réseau et le bac à sable

• En environnement Cloud : Restreignez dans les paramètres d'entreprise les dépôts et les branches auxquels Devin est autorisé à accéder.
• Sur le CLI ou la CI : Utilisez l'option --sandbox accompagnée d'une liste blanche de domaines pour bloquer toute connexion vers des serveurs externes inconnus.
• Sur Outposts : Déployez les workers dans un sous-réseau isolé et configurez des groupes de sécurité (Security Groups) pour interdire tout accès aux réseaux de production.

Étape 4 : Lancer les tests d'intégration et examiner les livrables

Une fois les modifications de code terminées, donnez la consigne à Devin :

« Lance le build automatisé, exécute npm run test:e2e et valide le parcours de connexion et de paiement. »

Devin active automatiquement son mode de test (Testing Mode) :

1. Contrôle l'environnement du blueprint et installe les dépendances requises.
2. Lit les variables d'environnement de test injectées dynamiquement.
3. Démarre les services locaux, lance la suite de tests et manipule le navigateur intégré si une validation d'interface est requise.
4. Enregistre une vidéo commentée du test et la joint directement à la Pull Request, apportant la preuve irréfutable du bon fonctionnement sans afficher d'identifiants sensibles dans les journaux.

4. Bonnes pratiques de sécurité et pièges critiques à éviter

Références

• Secrets & Site Cookies - Devin Docs
• Devin environment blueprints - Devin Docs
• Blueprint reference - Devin Docs
• Sandbox - Devin Docs
• Devin Outposts: self-hosted infrastructure - Devin Docs
• Testing & Video Recordings - Devin Docs
• Enterprise security - Devin Docs