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 é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é de code basé sur l'IA qui peut détecter, vérifier et corriger les failles profondes de votre codebase. CodeMender enveloppe un LLM affiné, en utilisant des prompts, des compétences et une logique d'orchestration conçus 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 :
- Détectez les failles en analysant votre codebase à l'aide d'un LLM guidé par l'agent, en tirant parti d'outils spécialisés et du 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 créant le code et en tentant d'exploiter les failles détecté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 et du harnais affiné de CodeMender fournit des résultats de meilleure qualité que l'utilisation d'un LLM seul pour détecter et corriger les failles.
Architecture du système
Du point de vue de l'utilisateur, le système CodeMender se compose de deux composants :
- Agent : système multi-agent hébergé qui exécute la logique métier et le raisonnement de base.
- Client : client exécuté sur votre machine, agissant à la fois comme une CLI (pour émettre des commandes et afficher des résultats) et comme un daemon (pour exécuter des commandes au nom de l'agent, avec une isolation facultative dans un bac à sable local au niveau du processus afin de compiler le code, d'exécuter des tests et de vérifier les failles en toute sécurité).
Langages et frameworks pris en charge
Par défaut, CodeMender est compatible avec les langages suivants : C/C++, C# / .NET, Go, Java, JavaScript et TypeScript, Kotlin, Python, Ruby, Rust et PHP. De plus, il offre 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é de code basé sur l'IA, il peut analyser et corriger le code dans n'importe quel langage compris par le modèle sous-jacent. La prise en charge est généralement disponible pour tous les langages non propriétaires.
Analyse de langages de programmation supplémentaires
Vous pouvez configurer CodeMender pour qu'il recherche des 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.includedu fichier de configuration global CodeMender~/.codemender/config.yaml. - Configuration par dépôt : ajoutez l'extension de fichier du langage de programmation à la section
scan.extensions.includedu fichier de configuration CodeMenderconfig.yamldans le dépôt.
Par exemple, pour analyser des langages ou des formats de script supplémentaires :
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 concernant la qualité
CodeMender ne publie pas d'évaluations formelles par langage. Les langages par défaut reflètent les cas où nous disposons de la couverture de référence la plus étendue. Les résultats pour les autres langages varient. Si votre organisation a besoin qu'un langage spécifique soit priorisé pour une évaluation plus approfondie ou une inclusion par défaut, contactez votre équipe de compte Google.
Modèles compatibles
CodeMender est compatible avec les modèles suivants :
Cliquez pour développer les modèles compatibles
CodeMender est également compatible avec Gemini 3.8 Flash Cyber et Gemini 4 Argon Cyber Permissive pour les clients ayant accès via le programme Fairwind.
Gemini 4 Argon (gemini-4-argon) inclut des fonctionnalités de cybersécurité intégrées qui peuvent bloquer les requêtes impliquant la génération d'exploits ou la vérification des failles.
Tout blocage de sécurité sur gemini-4-argon déclenche automatiquement une nouvelle tentative sur
Gemini 3.8 Flash Cyber (gemini-3.8-flash-cyber), puis
revient à Gemini 3.8 Flash
(gemini-3.8-flash) si votre projet n'a pas accès à
Gemini 3.8 Flash Cyber.
Pour spécifier un modèle lors de l'exécution 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ésumé d'une ligne une fois la commande terminée. Les nombres couvrent les jetons d'entrée, de sortie et totaux pour la session en cours.
Ligne d'état en direct
Lors de l'exécution de cm find, cm fix, cm verify ou cm session resume, transmettez l'option --compact pour afficher une ligne d'état continue qui se met à jour au fur et à mesure que l'agent fonctionne :
cm find ./src/auth/ --compact
La ligne d'état indique les totaux cumulés de la session :
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. Il 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ésumé d'une ligne avec le temps écoulé et les totaux de jetons :
✅ Completed 14 tool steps in 3m 42s | Tokens: 40k in / 12k out / 60k total
Utilisation des jetons facturée
Pour afficher l'utilisation cumulée des jetons facturés et les tendances des coûts dans votre Cloud de Confiance by S3NS projet, consultez Afficher les rapports sur la 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 un projet Cloud de Confiance : configurez votre Cloud de Confiance projet avec les API et les rôles IAM requis.
- Télécharger la CLI CodeMender: téléchargez et installez le binaire de la CLI CodeMender pour votre système d'exploitation.
- Configurer Cloud de Confiance les identifiants et le projet: configurez Cloud de Confiance les identifiants par défaut de l'application (ADC) et définissez votre projet cible pour authentifier la CLI.
- Provisionner 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 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 l'option --model avec l'identifiant de modèle correspondant :
- Gemini 3.8 Flash (par défaut) :
--model gemini-3.8-flash - Gemini 3.8 Flash Cyber:
--model gemini-3.8-flash-cyber - Gemini 4 Argon:
--model gemini-4-argon - Gemini 4 Argon Cyber Permissive:
--model gemini-4-argon-cyber-permissive - 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 findcm verifycm fix
Pour spécifier un modèle lors de l'exécution de 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 ne téléchargez jamais 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 indépendamment.
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 des commandes.
- Métadonnées, diagnostics, erreurs et télémétrie d'utilisation (tels que les jetons consommés et la durée des commandes).
Nous n'utilisons jamais votre code source client pour entraîner les pondérations du modèle sous-jacent.
Quelle est la règle de conservation ?
CodeMender utilise une règle de conservation des données stricte et à court terme :
- Conservation maximale de sept jours : nous conservons les données de session, y compris les extraits de code et les états de suivi, pendant sept jours maximum dans le stockage de Gemini Enterprise Agent Platform pour permettre aux utilisateurs de reprendre facilement les analyses interrompues. Au bout de sept jours, le système les supprime automatiquement (voir Conservation zéro donnée).
- 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 et les correctifs des failles 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 "zéro accès aux données" en ce qui concerne la visibilité humaine :
- Aucun accès humain : aucun groupe humain ni aucun ingénieur Google n'a accès en lecture aux données client dans l'environnement de production.
- Aucune visibilité de l'opérateur : même pour le débogage et le suivi des erreurs en production, les opérateurs Google sont limités et n'ont pas de visibilité sur le contexte du code source client ni sur les états de session temporaires.
- Isolation stricte : nous isolons logiquement toutes les données et contrôlons leur accès par organisation et par projet de facturation client afin de protéger la confidentialité des locataires dans notre infrastructure partagée.
- VPC Service Controls (VPC-SC) : pour mieux protéger 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 Cloud de Confiance ressources, ce qui contribue à réduire les risques d'exfiltration de données lorsque vos données localisées sont envoyées au moteur de raisonnement cloud.
Étape suivante
Pour obtenir des instructions détaillées, consultez les guides suivants :