Installer et configurer la CLI

CodeMender est un agent IA autonome de sécurité du code qui analyse, valide et corrige les failles de cybersécurité profondes dans votre codebase. Avant d'exécuter CodeMender, téléchargez la CLI et initialisez les options de l'espace de travail.

Architecture et modèle de sécurité

CodeMender utilise un modèle d'exécution local en priorité :

  • Moteur de raisonnement hébergé : le raisonnement agentique, la modélisation des menaces et la logique d'orchestration s'exécutent de manière sécurisée dans Google Cloud sur Gemini Enterprise Agent Platform.
  • CLI d'exécution locale : le code source ne quitte jamais votre station de travail ni votre conteneur CI/CD de manière groupée. L'outil CLI cm local exécute les lectures de fichiers, les vérifications de compilation locales et les vérifications d'exploitation de preuve de concept (PoC) dans votre bac à sable local. Il n'envoie que des extraits de code chirurgicaux et des résultats d'exécution d'outils au backend cloud via l'API Interactions sur la plate-forme Gemini Enterprise Agent.

Configuration de l'environnement

Pour commencer à utiliser CodeMender, configurez votre projet Google Cloud , téléchargez et installez la CLI, configurez vos identifiants et initialisez votre espace de travail.

Configuration du projet et autorisations IAM

Avant de télécharger l&CLI et de configurer les identifiants, assurez-vous que le projet Google Cloud cible est correctement configuré avec les API et les autorisations requises.

API requises

Assurez-vous que les API Google Cloud suivantes sont activées dans votre projet :

  1. L'API Vertex AI (aiplatform.googleapis.com) permet le streaming et la gestion des sessions actives.
  2. API Cloud Resource Manager (cloudresourcemanager.googleapis.com) : valide les états d'authentification des utilisateurs et les métadonnées du projet.

Pour exécuter les commandes CLI, les utilisateurs doivent disposer du rôle IAM suivant :

  • Utilisateur Vertex AI (roles/aiplatform.user) : permet aux utilisateurs de créer, de diffuser et de gérer des sessions actives.

Télécharger et installer CodeMender CLI

Les binaires de la CLI CodeMender sont hébergés dans Artifact Registry. Sélectionnez l'onglet correspondant à votre système d'exploitation pour télécharger et installer l&#CLI.

Linux x86_64

Pour télécharger et installer la CLI CodeMender pour Linux (x86_64) :

  1. Téléchargez le package à l'aide de l'une des méthodes suivantes :
    • gcloud CLI : exécutez la commande suivante : 
      gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-linux-amd64.zip \
  --destination=./
    • curl : exécutez la commande suivante : 
      curl -L -o cm-linux-amd64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-linux-amd64.zip:download?alt=media"
  2. Installez la CLI : 
    unzip cm-linux-amd64.zip
chmod +x cm
sudo mv cm /usr/local/bin/cm

Linux ARM64

Pour télécharger et installer la CLI CodeMender pour Linux (ARM64) :

  1. Téléchargez le package à l'aide de l'une des méthodes suivantes :
    • gcloud CLI : exécutez la commande suivante : 
      gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-linux-arm64.zip \
  --destination=./
    • curl : exécutez la commande suivante : 
      curl -L -o cm-linux-arm64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-linux-arm64.zip:download?alt=media"
  2. Installez la CLI : 
    unzip cm-linux-arm64.zip
chmod +x cm
sudo mv cm /usr/local/bin/cm

macOS Intel

Pour télécharger et installer la CLI CodeMender pour macOS (Intel) :

  1. Téléchargez le package à l'aide de l'une des méthodes suivantes :
    • gcloud CLI : exécutez la commande suivante : 
      gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-darwin-amd64.zip \
  --destination=./
    • curl : exécutez la commande suivante : 
      curl -L -o cm-darwin-amd64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-darwin-amd64.zip:download?alt=media"
  2. Installez la CLI : 
    unzip cm-darwin-amd64.zip
chmod +x cm
mv cm /usr/local/bin/cm

macOS Apple Silicon

Pour télécharger et installer la CLI CodeMender pour macOS (Apple Silicon) :

  1. Téléchargez le package à l'aide de l'une des méthodes suivantes :
    • gcloud CLI : exécutez la commande suivante : 
      gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-darwin-arm64.zip \
  --destination=./
    • curl : exécutez la commande suivante : 
      curl -L -o cm-darwin-arm64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-darwin-arm64.zip:download?alt=media"
  2. Installez la CLI : 
    unzip cm-darwin-arm64.zip
chmod +x cm
mv cm /usr/local/bin/cm

Windows x86_64

Pour télécharger et installer la CLI CodeMender pour Windows (x86_64) :

  1. Téléchargez le package à l'aide de l'une des méthodes suivantes :
    • gcloud CLI : exécutez la commande suivante dans PowerShell : 
      gcloud artifacts generic download `
  --project=cmoc-prod `
  --location=us `
  --repository=codemender-cli-production `
  --package=cm `
  --version=stable `
  --name=cm-windows-amd64.zip `
  --destination=./
    • PowerShell : exécutez la commande suivante : 
      Invoke-WebRequest -Uri "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-windows-amd64.zip:download?alt=media" -OutFile cm-windows-amd64.zip
  2. Installez la CLI : 
    Expand-Archive -Path cm-windows-amd64.zip -DestinationPath ./
# Move cm.exe to a permanent folder and add it to your system PATH (e.g. Environmental Variables)

Windows ARM64

Pour télécharger et installer la CLI CodeMender pour Windows (ARM64) :

  1. Téléchargez le package à l'aide de l'une des méthodes suivantes :
    • gcloud CLI : exécutez la commande suivante dans PowerShell : 
      gcloud artifacts generic download `
  --project=cmoc-prod `
  --location=us `
  --repository=codemender-cli-production `
  --package=cm `
  --version=stable `
  --name=cm-windows-arm64.zip `
  --destination=./
    • PowerShell : exécutez la commande suivante : 
      Invoke-WebRequest -Uri "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-windows-arm64.zip:download?alt=media" -OutFile cm-windows-arm64.zip
  2. Installez la CLI : 
    Expand-Archive -Path cm-windows-arm64.zip -DestinationPath ./
# Move cm.exe to a permanent folder and add it to your system PATH (e.g. Environmental Variables)

Configurer les identifiants Google Cloud

Étant donné que la CLI CodeMender interagit avec le moteur de raisonnement hébergé dans le cloud via l'API Interactions, vous devez configurer les identifiants par défaut de l'application (ADC) dans votre environnement Google Cloud .

Pour vous authentifier, exécutez la commande suivante et suivez les invites de connexion :

gcloud auth application-default login

Initialiser l'espace de travail

Une fois que vous vous êtes authentifié, l'étape suivante consiste à initialiser CodeMender dans votre environnement local. L'initialisation de CodeMender prépare votre espace de travail local en créant des fichiers de suivi de l'état et en établissant des paramètres de connexion au moteur de raisonnement hébergé dans le cloud.

Exécutez cm init à partir du répertoire racine de votre code pour créer des fichiers de suivi de l'état local et établir des configurations de référence :

cm init

Utilisez l'indicateur --verify pour tester la connectivité au moteur de raisonnement hébergé dans le cloud et vérifier les paramètres de l'espace de travail :

cm init --verify

Paramètres de configuration (config.yaml)

L'objectif principal de config.yaml est d'aligner les comportements de l'agent CodeMender sur les besoins de votre système local en termes de sécurité, de contraintes environnementales et de performances.

Étant donné que l'agent d'IA hébergé exécute des commandes locales (comme la création de code, l'exécution de tests ou la modification de fichiers) à l'aide de votre client de démon local, ce fichier de configuration sert de limite pour définir ce que l'agent est autorisé ou non à faire.

Utilisation

  • Emplacement : par défaut, la CLI recherche ce fichier dans votre espace de travail initialisé (généralement .codemender/config.yaml ou un répertoire de configuration global tel que ~/.config/codemender/config.yaml).
  • Exécution : lorsque vous exécutez des commandes telles que cm find, cm verify ou cm fix, le client local lit ce fichier pour configurer les paramètres de sécurité, appliquer les contournements du système et spécifier les fichiers ou répertoires à ignorer.

Paramètres par défaut de base

Voici ce que signifient les paramètres par défaut principaux :

  • human_confirmation: true (ou require_confirmation: true)

    • Ce que cela signifie : par défaut, CodeMender ne peut pas modifier de fichier sur votre disque ni exécuter de commandes shell sans vous demander explicitement une confirmation [Y/n] dans le terminal.
    • Pourquoi ce paramètre est-il défini par défaut ? CodeMender peut générer des correctifs spéculatifs ou tenter d'exécuter des scripts d'exploitation pour vérifier une faille. Forcer la confirmation humaine permet d'éviter les modifications accidentelles du système ou l'exécution de code non autorisée dans votre environnement local.
    • Ignorer : pour les pipelines CI/CD non interactifs, cette valeur peut être définie sur false.

  • confirm_writes: false

    • Ce que cela signifie : désactive les invites interactives pour les modifications de fichiers, ce qui permet à l'agent CodeMender d'écrire des correctifs de sécurité et de modifier les fichiers sources directement sur votre disque local sans attendre l'approbation humaine.
    • Pourquoi cette valeur par défaut ? Par défaut, CodeMender définit ce garde-fou sur true pour appliquer un workflow "Human-in-the-Loop". Étant donné que CodeMender agit sur votre base de code locale, l'exigence d'une confirmation manuelle (par exemple, Write? [Y/n]) empêche l'agent d'apporter des modifications spéculatives, incorrectes ou destructrices à vos fichiers sources. Vous ne devez passer à false que lorsque vous exécutez des pipelines CI/CD isolés, jetables ou automatisés sans interface graphique.

  • include: [".py", ".java", ".go", ".js", ".ts", ".c", ".cc", ".cpp", ".h", ".rb", ".php"]

    • Signification : définit la liste explicite des extensions de fichier que vous autorisez CodeMender à ingérer et à analyser lors de l'analyse de votre espace de travail. CodeMender ignore automatiquement tout fichier de votre dépôt dont l'extension n'est pas spécifiée dans cette liste.
    • Pourquoi cette liste est-elle définie par défaut ? Cette liste est définie par défaut sur les principaux langages de programmation pour maximiser l'efficacité de l'analyse et empêcher l'agent de perdre du temps et des jetons sur des fichiers texte, des artefacts de compilation ou des fichiers binaires non pertinents. Toutefois, comme les applications modernes intègrent souvent des failles dans les configurations de déploiement ou les outils d'automatisation, nous vous recommandons vivement de développer manuellement cette liste par défaut pour inclure les fichiers de configuration, les formats de script et les fichiers IaC (par exemple, les scripts shell, les fichiers XML, YAML, de propriétés et JSON) afin que CodeMender ne les ignore pas silencieusement.

  • exclude_paths: ["node_modules", "vendor", "dist", "bin"]

    • Ce que cela signifie : CodeMender ignorera complètement ces répertoires lors de l'analyse de l'espace de travail et du code.
    • Pourquoi cette valeur par défaut ? Les grands dossiers de dépendances ou de compilation entraînent une latence et une pénalité de jetons massives. Le fait de les exclure par défaut garantit des performances élevées et des temps de réponse rapides.

  • project_paths: []

    • Signification : liste des chemins d'accès aux répertoires auxquels CodeMender peut accéder (lecture/écriture) lors de l'exécution de l'outil.
    • Pourquoi cette valeur est-elle définie par défaut ? Par défaut, elle est vide, ce qui limite l'agent au répertoire cible de l'analyse, au répertoire de l'espace de travail .codemender et à /tmp. Si votre processus de compilation ou de test nécessite d'accéder à des fichiers en dehors de ces répertoires, vous devez ajouter ces chemins d'accès ici.

  • sandbox :

    • Signification : bloc de configuration pour l'environnement de bac à sable au niveau du processus.
    • Sous-paramètres :
      • enabled: true : (valeur booléenne) active ou désactive le bac à sable. Si vous définissez cette valeur sur true (par défaut), l'agent exécute les outils dans le bac à sable local. Si vous le définissez sur false, l'agent exécute les outils directement sur le système hôte sans isolation.
      • mounts : (Objet)
        • target_dir: "." : (chaîne) répertoire à installer en tant qu'espace de travail actif dans le bac à sable. La CLI résout les chemins relatifs par rapport à la racine de l'espace de travail.
      • network : (Objet)
        • profile: "permissive-closed" : (chaîne) profil d'accès au réseau sortant dans le bac à sable. Il n'est pas encore possible d'autoriser de manière précise des domaines ou des formats d'URL spécifiques. Profils compatibles :
          • permissive-closed (par défaut) : isolement complet du réseau. Le bac à sable bloque toutes les connexions sortantes.
          • permissive-open : autorise un accès complet au réseau sortant.

  • security :

    • Signification : bloc de configuration pour les règles de sécurité.
    • Sous-paramètres :
      • protected_files: [] : (liste de chaînes) fichiers ou répertoires du système hôte que vous souhaitez monter en lecture seule dans le bac à sable pour les protéger contre toute modification (par exemple, ["~/.ssh/*"]). Prend en charge l'expansion de chemin (~) et les caractères génériques (*).

  • model: "gemini-3.5-flash"

    • Signification : moteur d'intelligence par défaut qui alimente les boucles de raisonnement du backend.
    • Pourquoi cette valeur est-elle définie par défaut ? gemini-3.5-flash offre l'équilibre optimal entre la vitesse, le coût et le raisonnement analytique requis pour suggérer des correctifs. (Les utilisateurs peuvent remplacer cette valeur par gemini-3.1-pro pour un raisonnement plus approfondi et complexe si nécessaire.)

  • vcs: { type: "git" }

    • Signification : définit le type de système de contrôle des versions utilisé par votre projet via la clé vcs. Si vous ne configurez pas cette option, l'outil tente d'identifier automatiquement les dépôts Git ou Mercurial. Si vous définissez vcs sur none, la CLI génère un avertissement, mais poursuit l'exécution sans la fonctionnalité VCS. CodeMender s'appuie sur ce paramètre pour gérer les correctifs de sécurité spéculatifs, suivre les modifications apportées à la codebase et s'intégrer à votre dépôt local.
    • Pourquoi ce paramètre est-il défini par défaut ? CodeMender est compatible avec Git, Mercurial ou les configurations VCS personnalisées. Git est le système par défaut, car il s'agit de la norme du secteur pour le suivi du contrôle des versions. Il garantit une intégration fluide des différences et la sécurité des annulations.

  • build: { command: "make build && make test" }

    • Signification : définit la commande shell exacte que CodeMender exécute pour compiler et créer votre projet, ainsi que pour exécuter vos tests unitaires et de régression.
    • Pourquoi cette option est-elle définie par défaut ? Il est essentiel de définir une commande de compilation et de test pour le workflow de validation. Il permet à CodeMender de compiler votre projet et d'exécuter votre suite de tests existante dans l'environnement de bac à sable isolé pour prouver que le correctif de sécurité généré atténue avec succès la faille sans perturber la logique d'application existante.

Exécution en bac à sable

Pour protéger votre poste de travail contre les modifications de fichiers non souhaitées ou les effets secondaires inattendus des outils, la CLI CodeMender s'exécute par défaut dans un bac à sable au niveau de l'OS. Vous pouvez désactiver le bac à sable de manière persistante dans la configuration ou le contourner par commande à l'aide d'indicateurs de la CLI.

Bien que ce sandboxing offre une première ligne de défense sur votre poste de travail, il offre une protection de sécurité plus faible que l'exécution de l'agent dans une machine virtuelle (VM) entièrement isolée :

  • Linux : utilise des espaces de noms de noyau (CLONE_NEWNS, CLONE_NEWUSER, etc.) et des filtres seccomp pour isoler les points de montage et restreindre les appels système.
  • macOS : utilise le mécanisme sandbox-exec (Seatbelt) intégré.
  • Windows (expérimental) : utilise l'isolation AppContainer et les listes de contrôle d'accès (LCA). Le sandboxing sur Windows est expérimental et peut nécessiter des droits d'administrateur ou être incompatible avec certaines configurations système.

Comportement du bac à sable

Lorsque le bac à sable est actif :

  1. Isolation du système de fichiers : l'agent ne peut lire et écrire des fichiers que dans les répertoires autorisés. Le bac à sable redirige toute écriture en dehors de ces répertoires vers un système de fichiers temporaire en mémoire (tmpfs) sans affecter votre système hôte.
  2. Isolation du réseau : le bac à sable bloque l'accès au réseau sortant par défaut. Cela empêche l'agent (ou les outils de compilation qu'il appelle) d'établir des connexions externes inattendues ou de transmettre des données en dehors de l'espace de travail.

Accès au réseau pendant la compilation et la validation

Étant donné que le bac à sable permet l'isolation du réseau par défaut (sandbox.network.profile est défini sur permissive-closed par défaut), l'agent ne peut pas accéder à Internet lors de l'exécution de l'outil.

Cela introduit des limites pour les projets qui nécessitent la récupération de dépendances externes lors des étapes de compilation ou de validation (par exemple, l'exécution de npm install, pip install ou go get dans le cadre de build.command). Si votre processus de compilation tente d'accéder à des services Web externes, il échouera.

Gérer les dépendances réseau

Si votre projet nécessite un accès réseau pour les compilations ou les tests, vous disposez des options suivantes :

  • Précharger les dépendances : installez toutes les dépendances requises sur le système hôte avant d'exécuter les commandes cm. La commande de compilation n'a ainsi pas besoin d'accéder au réseau.

  • Activez l'accès au réseau dans le bac à sable : modifiez le profil réseau dans votre config.yaml pour autoriser les connexions sortantes :

    sandbox:
  network:
    profile: "permissive-open"

  • Contourner le bac à sable : exécutez la commande avec le flag --unrestricted pour désactiver complètement le bac à sable et les limites du système de fichiers pour cette exécution.

Configuration du bac à sable

Vous pouvez configurer et contrôler le bac à sable à l'aide des options suivantes :

  • Configuration persistante (config.yaml) : vous pouvez personnaliser le comportement du bac à sable, les montages du système de fichiers, l'accès au réseau et les règles de sécurité en ajoutant des blocs sandbox, execution et security à votre fichier config.yaml. Pour en savoir plus, consultez Paramètres de configuration.
  • Contrôler le bac à sable à l'aide de la CLI (--sandbox) : vous pouvez activer ou désactiver explicitement le bac à sable pour une seule exécution en transmettant --sandbox=true ou --sandbox=false à cm find, cm verify ou cm fix.
  • Contourner l'isolation à l'aide de la CLI (--unrestricted) : vous pouvez contourner temporairement toutes les protections du bac à sable pour une seule exécution en transmettant l'indicateur --unrestricted. Cela désactive les limites du chemin d'accès au système de fichiers (ce qui permet à l'agent d'accéder à n'importe quel chemin d'accès sur votre hôte) et désactive complètement l'isolation des conteneurs au niveau de l'OS (y compris l'isolation du réseau).

Choisir un niveau d'isolation

En fonction de vos exigences en termes de sécurité et de votre environnement de développement, vous pouvez choisir le niveau d'isolation approprié pour exécuter l'interface de ligne de commande CodeMender.

Méthode Description Avantages Inconvénients
Bac à sable intégré (au niveau de l'OS) Cette fonctionnalité est activée par défaut. Vous pouvez la désactiver dans le fichier config.yaml ou la contourner à l'aide d'options de ligne de commande. Utilise les fonctionnalités intégrées de l'OS (espaces de noms/seccomp, sandbox-exec, AppContainer (expérimental)) pour isoler l'exécution. Léger : aucune surcharge au démarrage, accès direct aux outils de l'espace de travail local avec un contrôle précis. Recommandé pour le développement local quotidien. La sécurité repose sur les fonctionnalités du noyau de l'OS. Elle est moins isolée qu'une VM complète. La compatibilité avec Windows est expérimentale et peut nécessiter des droits d'administrateur ou être incompatible avec certaines configurations.
Conteneurs Exécuter l'agent dans un conteneur (par exemple, Docker) Bonne isolation ; environnement standardisé. Nécessite un environnement d'exécution de conteneur, peut être lourd et ne permet pas d'interagir directement avec les outils sur l'ordinateur local.
VM complètes Exécutez l'agent dans une VM dédiée. Sécurité maximale : isolation complète. Frais généraux élevés en termes de ressources, démarrage lent, interaction directe avec les outils sur la machine locale impossible.

Télémétrie

Pour nous aider à surveiller et à améliorer l'état du produit, nous collectons des données de télémétrie anonymes via lCLI. Nous anonymisons entièrement toutes les données collectées, y compris les métriques d'utilisation de base et les diagnostics de performances. La télémétrie ne collecte ni ne transmet jamais de code source, de contenu de fichier, de résultats, de correctifs ni d'identités d'utilisateur.

La télémétrie est activée par défaut. Si vous souhaitez désactiver la télémétrie, définissez la variable d'environnement CM_TELEMETRY_OPT_OUT sur 1 ou true.

Mettre à jour la CLI

CodeMender dispose d'un mécanisme de mise à jour intégré pour vous assurer d'exécuter la dernière version de la CLI.

Vérification automatique des mises à jour

Par défaut, la CLI CodeMender recherche automatiquement les mises à jour en arrière-plan lorsque vous exécutez des commandes :

  • Limitation du débit : pour minimiser les frais généraux, la vérification automatique s'exécute au maximum une fois toutes les 24 heures.
  • Terminal interactif (TTY) requis : la CLI ne recherche les mises à jour et ne vous y invite que lorsqu'elle s'exécute dans un terminal interactif. Dans les environnements non interactifs (tels que les pipelines ou les scripts CI/CD), la vérification est ignorée et un avertissement est consigné dans stderr au maximum une fois par jour.
  • Invite : Si une nouvelle version est disponible, vous serez invité à la télécharger sur stderr : none 🆕 A new CodeMender release is available: 1.1.0 Update now? (y/N): Si vous répondez oui (y ou yes), CodeMender télécharge la mise à jour, remplace le fichier binaire et quitte. Vous devez exécuter à nouveau votre commande pour l'exécuter avec la nouvelle version. Si vous choisissez "Non", la mise à jour est ignorée et votre commande d'origine est exécutée.
  • Tolérance hors connexion : si vous êtes hors connexion ou si le dépôt de versions est inaccessible, la vérification échoue silencieusement et CodeMender continue d'exécuter votre commande.
  • Contournement : vous pouvez contourner la vérification automatique des mises à jour en transmettant l'indicateur --yes ou -y à n'importe quelle commande.

Mises à jour manuelles (cm update)

Vous pouvez forcer CodeMender à rechercher et à appliquer immédiatement les mises à jour en exécutant la commande update :

cm update

La commande cm update :

  • Ignore la limitation de 24 heures.
  • Télécharge et applique la mise à jour immédiatement, sans invite (non interactif).
  • Ne nécessite pas de terminal interactif (sans danger pour les scripts et la gestion de la configuration).

Si la CLI est installée dans un répertoire système qui nécessite des autorisations élevées, exécutez la mise à jour avec sudo :

sudo cm update