Modes de recherche de CodeMender

CodeMender propose trois modes d'analyse distincts via la commande cm find. Chaque mode est conçu pour une étape spécifique du cycle de vie du développement logiciel, en équilibrant la vitesse, la portée et la profondeur.

Comparer les modes Localiser

Le tableau suivant compare les trois modes d'analyse cm find :

Mode Commande Champ d'application cible Durée d'exécution habituelle Application idéale
Analyse standard cm find PATH Répertoire spécifié Durée d'exécution modérée Découverte de développeurs locaux, vérifications rapides, avis exploratoires
Analyse des différences cm find PATH --diff[=REF] Fichiers modifiés et fichiers dépendants (tels que les appelants et les appelés) Exécution rapide Pipelines CI/CD pour les demandes d'extraction (GitHub Actions, Cloud Build), hooks pre-commit
Analyse approfondie cm find PATH --deep Dépôt entier Durée d'exécution plus longue Audits planifiés, préparation des versions, certifications de conformité (SOC 2, ISO)

Analyse standard (par défaut)

Une analyse standard est le mode par défaut lorsque vous exécutez cm find sans fournir d'indicateurs d'analyse supplémentaires. Il exécute une analyse autonome d'une seule session du répertoire cible spécifié. Lors de l'analyse, CodeMender découvre les fichiers sources, les hiérarchise en fonction des modèles de failles, effectue une analyse de sécurité initiale et signale les failles potentielles regroupées par gravité et par type.

Les exemples suivants montrent comment exécuter une analyse standard sur un répertoire cible :

# Scan a directory using the default model
cm find ./src

# Scan with a specific Gemini model
cm find ./src --model gemini-3.8-flash

Points forts

Une analyse standard fonctionne sans configuration, ni indicateurs ni paramètres supplémentaires. Elle équilibre la vitesse et la couverture avec une durée d'exécution modérée, et utilise un minimum de jetons et de ressources de calcul, ce qui la rend économique pour le développement quotidien.

Compromis et limites

Une analyse standard a un rappel plus faible sur les grands codebases et peut ne pas explorer tous les fichiers des grands dépôts d'entreprise multipackages, car elle fonctionne dans un contexte de session unique. Elle se concentre également principalement sur les modèles locaux dans les fichiers individuels, ce qui limite l'analyse inter-packages et peut passer à côté des failles de sécurité qui s'étendent sur des packages distants.

Cas d'utilisation

Utilisez une analyse standard dans les scénarios suivants :

  • Exécutez une analyse sur votre machine locale avant de valider les modifications pour obtenir un retour rapide lors du développement local.
  • Inspectez un dépôt récemment cloné ou un petit projet pour une première évaluation de sa posture de sécurité.
  • Inspectez un sous-répertoire ou un module spécifique lorsque vous examinez un problème potentiel.

Analyse des différences

Une analyse diff effectue une analyse Git diff pour les workflows de demande d'extraction et les pipelines CI/CD en inspectant les fichiers modifiés et ajoutés, en se concentrant sur les plages de lignes exactes (hunks diff) qui ont été modifiées. En plus d'inspecter les lignes modifiées, il effectue une analyse d'impact pour découvrir les fichiers non modifiés du dépôt qui appellent, importent ou dépendent des fonctions et des symboles modifiés. Cela permet de s'assurer que les modifications apportées aux contrats ou aux signatures de fonction dans un fichier n'introduisent pas de failles dans les fichiers dépendants.

Lors de l'analyse, CodeMender isole automatiquement les failles préexistantes dans le code non modifié afin que les anciens problèmes n'entraînent pas l'échec de l'analyse ni le blocage de la demande d'extraction d'extraction. Il évalue ensuite les résultats par rapport à votre règle --fail-on et génère les résultats au format tableau, JSON ou SARIF v2.1.0.

Les exemples suivants montrent comment exécuter une analyse diff sur les modifications de la copie de travail, les modifications préparées ou une branche cible :

# Scan working copy changes versus HEAD
cm find . --diff

# Scan staged changes only (pre-commit)
cm find . --diff --staged

# Scan a pull request branch against the main branch in CI/CD
cm find . --diff=origin/main --format=sarif --output=results.sarif \
    --fail-on=CRITICAL,HIGH

Pour les configurations de pipeline de bout en bout, consultez Intégrer à CI/CD.

Points forts

L'analyse des différences est rapide et déterministe. Elle se termine généralement en moins de deux minutes pour que les durées d'exécution du pipeline CI/CD restent courtes. Contrairement aux scanners de différences qui n'inspectent que les lignes modifiées, --diff inspecte les relations entre l'appelant et l'appelé pour détecter les régressions de sécurité et les violations de contrat entre les fichiers. Comme il supprime les résultats dans le code non modifié, l'analyse ne bloque les requêtes d'extraction que pour les problèmes introduits ou affectés par les modifications, ce qui évite les rapports bruyants et les échecs de compilation inutiles. Une analyse des différences émet également un fichier SARIF v2.1.0 pour une intégration directe dans les annotations GitHub Code Scanning et les tableaux de bord Cloud Build.

Compromis et limites

Une analyse diff n'analyse que le code dans la zone concernée de la demande d'extraction d'extraction et ne détecte pas les failles préexistantes dans les parties non modifiées du dépôt. Il nécessite également un dépôt Git avec accès à la référence de base cible.

Cas d'utilisation

Utilisez une analyse des différences dans les scénarios suivants :

  • Exécutez des vérifications automatiques sur chaque demande d'extraction'extraction dans les pipelines CI/CD tels que GitHub Actions, Cloud Build, GitLab CI ou Jenkins.
  • Vérifiez que les modifications locales sont propres dans les hooks pre-commit ou pre-push avant de transférer le code vers le dépôt distant.
  • Validez que les fusions entre les branches de version n'introduisent pas de régressions.

Analyse approfondie

L'analyse approfondie est un mode d'analyse exhaustif conçu pour les audits de sécurité complets à l'échelle du dépôt. Il audite simultanément les fichiers sources de l'ensemble du dépôt à l'aide de nœuds de calcul parallèles (configurés avec --deep-workers, qui est défini par défaut sur 8 et accepte une plage de 1 à 16). À mesure qu'il découvre des résultats candidats, il les valide et les confirme par rapport au contexte du code environnant pour filtrer les faux positifs avant de générer les résultats.

Les exemples suivants montrent comment exécuter une analyse approfondie dans un dépôt :

# Run an exhaustive deep scan across the entire repository
cm find . --deep

# Tune concurrency and use the cyber-specialized security model
cm find . --deep --deep-workers=8 --model=gemini-3.8-flash-cyber

Points forts

Une analyse approfondie offre un rappel élevé et une découverte complète des failles dans les grandes bases de code d'entreprise. Elle surpasse les analyses en une seule session et utilise la validation automatique pour maintenir une haute précision. Il est compatible avec plusieurs langues et est indépendant de la plate-forme. Il fonctionne dans toutes les langues prises en charge par Gemini sans nécessiter de compilateurs, de configurations de compilation ni de fichiers de grammaire spécifiques à une langue. Il optimise également l'utilisation des ressources en concentrant l'analyse sur le code de production et en minimisant la consommation de calcul et de jetons sur les fichiers non destinés à la production.

Compromis et limites

N'utilisez pas d'analyse approfondie comme vérification synchrone qui bloque les demandes d'extraction. Les analyses approfondies effectuent une analyse complète de l'ensemble du dépôt. Par conséquent, ils nécessitent une durée d'exécution plus longue et une dépense de jetons plus élevée que les analyses standards ou différentielles.

Cas d'utilisation

Utilisez une analyse approfondie dans les cas suivants :

  • Exécutez des audits de sécurité planifiés quotidiennement ou hebdomadairement dans tous les dépôts de production.
  • Effectuez un audit de sécurité complet avant les versions majeures ou les déploiements en production.
  • Générez des preuves d'audit pour les examens de conformité et de certification SOC 2, ISO 27001, FedRAMP ou PCI-DSS.
  • Établissez une référence de sécurité initiale lorsque vous intégrez une nouvelle base de code à CodeMender.

Choisir un mode de recherche

Utilisez le tableau de référence suivant pour sélectionner le mode d'analyse adapté à votre workflow :

Workflow ou environnement Cas d'utilisation et objectif Mode recommandé Exemple de commande
Terminal local Découverte rapide ou vérification de la fiabilité d'un module spécifique Analyse standard cm find ./src
Terminal local Vérification avant validation des modifications préparées avant l'envoi Analyse des différences cm find . --diff --staged
Pipeline CI/CD Contrôle automatisé des demandes d'extraction sur le code et les appelants modifiés Analyse des différences cm find . --diff=origin/main --fail-on=CRITICAL,HIGH
Pipeline ou audit planifié Audits quotidiens, portes de sortie avant la publication, conformité SOC 2 Analyse approfondie cm find . --deep --deep-workers=8

Documentation de référence sur les indicateurs de commande par mode

Les tableaux suivants décrivent les indicateurs de ligne de commande acceptés par chaque mode d'analyse.

Options courantes (tous les modes)

Les indicateurs suivants s'appliquent à tous les modes d'analyse cm find :

Option Valeur par défaut Description
-c, --context TEXT "" Contexte supplémentaire pour guider l'agent d'analyse, comme des notes sur l'architecture.
--model MODEL_NAME gemini-3.8-flash Modèle Gemini à utiliser (gemini-3.8-flash, gemini-3.8-flash-cyber).
-y, --yes false Ignorer toutes les invites de confirmation interactives.
--unrestricted false Désactivez le bac à sable du système de fichiers.

Indicateurs d'analyse des différences

Les options suivantes permettent de configurer les analyses cm find --diff :

Option Valeur par défaut Description
--diff[=REF] Désactivé Activez le mode Diff par rapport à la référence cible, par exemple origin/main ou HEAD~1. Sans REF, la comparaison s'effectue avec HEAD. Ne peut pas être utilisé avec --deep.
--staged Désactivé Limiter la comparaison au contenu de l'index intermédiaire (git diff --cached). Nécessite --diff.
--diff-depth DEPTH 1 Profondeur de parcours pour l'analyse d'impact (de 1 à 3, par défaut : 1 saut).
--diff-workers COUNT 4 Nombre de nœuds de calcul simultanés pour les jobs d'audit des demande d'extraction d'extraction (de 1 à 16).
--diff-max-neighbors COUNT 10 Nombre maximal de fichiers d'appelant ou d'appelé dépendants à inspecter.
--fail-on SEVERITIES CRITICAL,HIGH Gravités séparées par une virgule entraînant la sortie de cm find avec le code 1.
--fail-on-truncation Désactivé Quittez avec le code 1 si la découverte des voisins dépasse la limite.
--format FORMAT table Format de sortie : table, json ou sarif.
--output FILE Sortie standard Écrit le rapport dans un fichier au lieu de la sortie standard.

Options d'analyse approfondie

Les options suivantes permettent de configurer les analyses cm find --deep :

Option Valeur par défaut Description
--deep false Activez l'analyse approfondie exhaustive à l'échelle du dépôt. Ne peut pas être utilisé avec --diff.
--deep-workers COUNT 8 Nombre de nœuds de calcul simultanés pour l'analyse approfondie (de 1 à 16).