Présentation de CodeMender

Le lancement de modèles d'IA avancés a suscité une inquiétude généralisée concernant les failles de code. Les pirates informatiques ayant accès à de nouvelles fonctionnalités pour générer des exploits, les équipes de sécurité sont soumises à une pression temporelle énorme pour trouver et corriger de manière proactive les failles avant qu'elles ne soient exploitées.

CodeMender est un agent de sécurité du code basé sur l'IA qui peut détecter, vérifier et corriger les failles profondes de votre codebase. CodeMender enveloppe un harnais affiné autour d'un LLM, en utilisant des invites, des compétences et une logique d'orchestration conçues par Google DeepMind pour transformer le modèle en un système agentique spécialisé dans la sécurité du code.

Fonctionnement

CodeMender gère l'échelle et la diversité des environnements d'entreprise modernes, où le code s'étend sur de nombreux langages et types de systèmes :

  • Identifiez les failles en analysant votre codebase à l'aide d'un LLM guidé par l'agent, en tirant parti d'outils spécialisés et de prompt engineering pour concentrer le modèle sur les failles de sécurité. Vous pouvez également importer une liste de failles à partir d'outils d'analyse de sécurité externes.
  • Vérifiez les failles en compilant le code et en tentant d'exploiter les failles trouvées pour vérifier si elles sont exploitables. Cela permet de hiérarchiser les failles confirmées et de réduire le taux de faux positifs.
  • Corrigez les failles en générant et en testant un correctif compatible avec le langage de votre codebase.

Au cours des trois étapes, vous pouvez fournir du contexte à CodeMender pour vous assurer qu'il tient compte des nuances de votre application et de votre modèle de menace. Cette combinaison d'un LLM avec le harnais affiné de CodeMender fournit des résultats de meilleure qualité que l'utilisation d'un LLM seul pour identifier et corriger les failles.

Architecture du système

Du point de vue de l'utilisateur, le système CodeMender se compose de deux éléments :

  • Agent : système multi-agents hébergé qui exécute la logique métier et le raisonnement de base.
  • Client : client s'exécutant sur votre machine, servant à la fois de CLI (pour émettre des commandes et afficher des résultats) et de daemon (pour exécuter des commandes au nom de l'agent, avec une isolation facultative dans un bac à sable local au niveau du processus pour compiler du code, exécuter des tests et vérifier les failles de sécurité de manière sécurisée).

Langages et frameworks pris en charge

CodeMender est compatible avec les langages suivants par défaut : C/C++, C# / .NET, Go, Java, JavaScript et TypeScript, Kotlin, Python, Ruby, Rust et PHP. Il offre également une large prise en charge des bibliothèques standards dans ces langages, ainsi que des frameworks d'entreprise courants (tels que HTML/CSS, Django, Flask, React, Spring Boot, ASP.NET et Express).

Les langages de programmation listés ne sont pas une limite stricte. Comme CodeMender est un agent de sécurité du code basé sur l'IA, il peut analyser et corriger le code dans n'importe quelle langue comprise par le modèle sous-jacent. L'assistance est généralement disponible pour toute langue non propriétaire.

Analyse de langages de programmation supplémentaires

Vous pouvez configurer CodeMender pour qu'il recherche les langages de programmation qui ne figurent pas dans son ensemble par défaut de l'une des manières suivantes :

  • Configuration globale : ajoutez l'extension de fichier du langage de programmation à la section scan.extensions.include du fichier de configuration ~/.codemender/config.yaml global de CodeMender.
  • Configuration par dépôt : ajoutez l'extension de fichier du langage de programmation à la section scan.extensions.include du fichier de configuration config.yaml CodeMender dans le dépôt.

Par exemple, pour analyser d'autres langues ou formats de script :

scan:
  extensions:
    include:
      # Default languages
      - .py
      - .java
      - .go
      - .js
      - .jsx
      - .mjs
      - .cjs
      - .ts
      - .tsx
      - .c
      - .cc
      - .cpp
      - .cxx
      - .h
      - .hpp
      - .cs
      - .rs
      - .kt
      - .kts
      - .rb
      - .php
      # Additional / custom languages
      - .swift
      - .scala
      - .sh

  # Exclude build, dependency, cache, and artifact directories
  exclude_dirs:
    - node_modules
    - vendor
    - dist
    - bin
    - target
    - obj
    - build
    - .gradle

Pour en savoir plus sur la configuration des options d'analyse, consultez Paramètres de configuration (config.yaml).

Remarque sur la qualité

CodeMender ne publie pas d'évaluations formelles par langue. Les langues par défaut reflètent celles pour lesquelles nous disposons de la plus grande couverture de benchmarks. Les résultats dans les autres langues varieront. Si votre organisation a besoin qu'une langue spécifique soit priorisée pour une évaluation plus approfondie ou une inclusion par défaut, contactez l'équipe chargée de votre compte Google.

Modèles compatibles

CodeMender est compatible avec les modèles suivants :

Cliquer pour développer les modèles compatibles

Pour spécifier un modèle lorsque vous exécutez des commandes CodeMender CLI, consultez Spécifier le modèle.

Régions où le service est disponible

CodeMender est disponible dans le monde entier.

Suivre l'utilisation des jetons

CodeMender affiche la consommation de jetons à deux endroits : une ligne d'état en direct pendant l'exécution d'une commande et un récapitulatif sur une ligne lorsqu'une commande se termine correctement. Les nombres couvrent les jetons d'entrée, de sortie et totaux pour la session en cours.

Ligne d'état en direct

Pendant l'exécution de cm find, cm fix, cm verify ou cm session resume, transmettez l'indicateur --compact pour afficher une ligne d'état défilante qui se met à jour au fur et à mesure que l'agent travaille :

cm find ./src/auth/ --compact

La ligne d'état indique le nombre total de sessions cumulées :

Tokens: 40k in / 12k out / 60k total

Les sessions reprises continuent de compter à partir de l'endroit où l'exécution précédente s'est arrêtée. Le nombre total peut inclure les jetons de raisonnement interne du modèle et peut donc dépasser in + out.

Résumé de la sortie

Lorsqu'une commande se termine correctement et qu'au moins une étape d'outil a été exécutée, CodeMender affiche un récapitulatif d'une ligne avec le temps écoulé et le nombre total de jetons :

✅ Completed 14 tool steps in 3m 42s | Tokens: 40k in / 12k out / 60k total

Utilisation de jetons facturée

Pour afficher l'utilisation cumulée des jetons facturés et les tendances des coûts pour votre projet Google Cloud , consultez Afficher les rapports de facturation et l'évolution des coûts dans Cloud Billing.

Premiers pas avec la CLI

Configurez l'outil CLI et initialisez votre espace de travail pour commencer l'analyse.

Prérequis

Avant d'initialiser la CLI CodeMender, assurez-vous que votre environnement est correctement préparé :

  • Configurer le projet Google Cloud  : configurez votre projet Google Cloud avec les API et les rôles IAM requis.
  • Téléchargez la CLI CodeMender : téléchargez et installez le binaire de la CLI CodeMender pour votre système d'exploitation.
  • Configurer les identifiants Google Cloud  : configurez les identifiants par défaut de l'application (ADC) Google Cloud pour authentifier la CLI.
  • Provisionnez votre code source : clonez ou copiez le code source du projet que vous souhaitez analyser dans votre espace de travail.
  • Configurer le bac à sable : définissez les montages de répertoire, les profils d'accès au réseau et les exceptions de sécurité pour l'environnement de bac à sable.

Spécifier le modèle

Par défaut, CodeMender utilise Gemini 3.8 Flash. Pour remplacer le modèle par défaut, transmettez le flag --model avec l'identifiant de modèle correspondant :

  • Gemini 3.8 Flash (par défaut) : --model gemini-3.8-flash
  • Gemini 3.7 Flash : --model gemini-3.7-flash
  • Gemini 3.6 Flash : --model gemini-3.6-flash
  • Gemini 3.5 Flash : --model gemini-3.5-flash
  • Preview Gemini 3.1 Pro : --model gemini-3.1-pro-preview

Les commandes suivantes sont compatibles avec l'option --model :

  • cm find
  • cm verify
  • cm fix

Pour spécifier un modèle lorsque vous exécutez l'une de ces commandes, utilisez la syntaxe suivante :

cm COMMAND TARGET --model MODEL_NAME

Sécurité et confidentialité des données

Les sections suivantes décrivent le modèle de sécurité, les règles de conservation des données et les contrôles d'accès de CodeMender :

Quelles données CodeMender envoie-t-il au cloud ?

Lorsque vous utilisez CodeMender, l'outil CLI local sert d'intermédiaire pour accéder à votre code. Vous n'avez ainsi jamais besoin d'importer l'intégralité de vos dépôts de code source sur les serveurs de Google, et l'agent hébergé ne les clone pas de manière indépendante.

Au lieu de cela, la CLI localise strictement les données qu'elle envoie à l'agent hébergé par Google, qui se compose des éléments suivants :

  • Contenu de fichiers ou extraits de code ciblés, informations sur les failles, correctifs proposés et résultats d'exécution de commandes.
  • Métadonnées, diagnostics, erreurs et télémétrie d'utilisation (comme les jetons consommés et la durée des commandes).

Nous n'utilisons jamais le code source de vos clients pour entraîner les pondérations du modèle sous-jacent.

Quelles sont les règles de conservation ?

CodeMender utilise une règle stricte de conservation des données à court terme :

  • Durée de conservation maximale de 7 jours : nous conservons les données de session, y compris les extraits de code et les états de suivi, pendant 7 jours maximum dans l'espace de stockage de Gemini Enterprise Agent Platform pour permettre aux utilisateurs de reprendre facilement les analyses interrompues. Au bout de sept jours, le système le supprime automatiquement (voir Conservation des données nulle).
  • Suppression explicite : les clients n'ont pas à attendre sept jours. Ils peuvent déclencher un nettoyage immédiat de toutes les données de session en appelant DeleteInteraction.
  • Résultats éphémères : nous ne stockons pas les résultats de failles et les correctifs dans des bases de données à long terme. Ils s'accumulent en mémoire pendant le pipeline.

Qui peut accéder aux données ?

CodeMender utilise une approche "Zero-Data-Access" concernant la visibilité humaine :

  • Aucun accès humain : aucun groupe humain ni aucun ingénieur Google n'a accès aux données client dans l'environnement de production.
  • Aucune visibilité pour les opérateurs : même pour le débogage et le suivi des erreurs en production, les opérateurs Google sont soumis à des restrictions et n'ont pas accès au contexte du code source du client ni aux états de session transitoires.
  • Isolation stricte : nous isolons logiquement toutes les données et contrôlons leur accès par organisation et par projet de facturation client pour protéger la confidentialité des locataires au sein de notre infrastructure partagée.
  • VPC Service Controls (VPC-SC) : pour protéger davantage votre environnement, l'architecture de CodeMender est entièrement compatible avec VPC Service Controls (VPC-SC). Cela vous permet de définir un périmètre de sécurité autour de vos ressources Google Cloud , ce qui contribue à atténuer les risques d'exfiltration de données lorsque vos données localisées sont envoyées au moteur de raisonnement cloud.

Étapes suivantes

Pour obtenir des instructions détaillées, consultez les guides suivants :