Gérer les sessions et exporter des rapports

Aperçu

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

CodeMender suit chaque analyse, vérification et tentative de correction en tant que session avec état, sauvegardée par une base de données SQLite locale (state.db). Vous pouvez inspecter les sessions actives, reprendre les tâches suspendues et exporter des rapports de résultats détaillés.

Gestion de la session

La CLI CodeMender gère les sessions d'exécution avec état localement, ce qui vous permet de suivre les tâches actives, de reprendre les workflows interrompus et d'exporter des rapports de sécurité.

Lister les sessions actives et passées

Exécutez la commande suivante pour lister toutes les sessions, leur état (RUNNING, WAITING_FOR_TOOL, COMPLETED, FAILED, CANCELLED) et les chemins d'accès cibles :

cm session list

Reprendre une session interrompue

Si une session est mise en pause en raison d'une interruption du réseau ou de l'échec d'une étape, reprenez-la à partir de la dernière étape de point de contrôle :

cm session resume SESSION_ID

Vous pouvez transmettre --yes (-y), --sandbox, --allow-all-paths, --allow-all-commands et --bypass-warning à cm session resume pour contrôler les invites de confirmation, le bac à sable et les limites de stratégie pour l'exécution reprise.

Annuler une session en cours d'exécution

Pour mettre fin à une session active et arrêter l'exécution du calcul de l'agent de backend :

cm session cancel SESSION_ID

Afficher les rapports et exporter les correctifs

Affichez les résultats de la session, les états de validation et les détails des correctifs à l'aide de cm report.

Formats de sortie

Tableau des terminaux (par défaut)

Liste récapitulative des résultats.

cm report

Rapport HTML

Générer un rapport HTML mis en forme. Utilisez --open (ou -o) pour le lancer automatiquement dans votre navigateur par défaut.

cm report --format html --open

Markdown

Générer un rapport Markdown au format GitHub.

cm report --format md

JSON

Exportez tous les détails des résultats de la session au format JSON brut.

cm report --format json

SARIF

Exportez les résultats au format SARIF standard (v2.1.0) pour les intégrer à d'autres outils de sécurité.

cm report --format sarif

Filtrer et trier les signalements

• Afficher les correctifs de code proposés (--patches) : incluez les différences unifiées complètes des correctifs générés dans le rapport. bash cm report --patches
• Filtrer par niveau de gravité (--severity) : affichez les résultats correspondant à un niveau (CRITICAL, HIGH, MEDIUM, LOW). bash cm report --severity HIGH
• Filtrer par état (--status) : affichez les résultats correspondant à un état (OPEN, FIXED, DISMISSED, REOPENED). bash cm report --status OPEN
• Filtrer par session (--session) : affichez les résultats d'un préfixe d'ID de session spécifique.

  cm report --session SESSION_ID_PREFIX

• Afficher les artefacts de l'agent (--artifacts) : incluez les chemins d'accès aux artefacts d'exécution générés par l'agent (comme les journaux et les scripts d'exploitation). bash cm report --artifacts
• Trier les résultats (--sort) : triez les résultats par severity (par défaut) ou time. bash cm report --sort time
• Filtrer par ID de résultat : transmettez un ID de résultat spécifique (ou un préfixe) en tant qu'argument positionnel pour afficher les détails d'un seul résultat.

  cm report FINDING_ID_PREFIX

États des résultats de failles

CodeMender suit les résultats dans les états de faille suivants :

• OPEN
  • Signification : la faille a bien été détectée lors d'une analyse (ou importée depuis un outil tiers), mais elle n'a pas encore été vérifiée, corrigée ou marquée comme inactive.
  • Comment elle est gérée : il s'agit de l'état initial de toute faille de sécurité nouvellement découverte. Les failles à l'état OPEN sont activement mises en file d'attente pour vérification (cm verify) ou application de correctifs (cm fix).
• FIXED
  • Signification : CodeMender a généré un correctif pour la faille, appliqué le diff à votre codebase local, puis compilé et exécuté des tests de vérification pour prouver que l'exploit ne réussit plus.
  • Comment il est géré : une fois qu'il est confirmé qu'un correctif résout le problème sans interrompre la logique de code existante, CodeMender fait passer le résultat à l'état FIXED. Il restera dans cet état, sauf si une analyse ultérieure détecte une régression.
• DISMISSED
  • Signification : la faille est désignée comme inactive, soit parce qu'elle a été identifiée comme un faux positif ou qu'elle a déjà été corrigée, soit parce que le résultat n'est pas suffisamment fiable pour confirmer qu'elle est exploitable (y compris par rapport au modèle de modélisation des menaces de votre projet, si un tel modèle a été fourni lors du processus d'intégration).
  • Comment elle est gérée : marquer un élément comme DISMISSED désactive les futures alertes et exclut le résultat de la sortie de votre CLI active avec cm report --status OPEN. Réexécuter cm verify sur un résultat ignoré réexamine ou restaure les éléments ignorés.
• REOPENED
  • Signification : une faille précédemment marquée comme FIXED ou DISMISSED a été détectée à nouveau lors d'une analyse ultérieure de la codebase.
  • Comment elle est gérée : cet état indique une régression (par exemple, une mauvaise fusion Git annulant le correctif) ou l'échec d'une stratégie de correction. Il signale le problème pour une réévaluation immédiate et demande aux développeurs d'examiner le processus d'application des correctifs.

Niveaux de gravité des failles

CodeMender classe les résultats selon les niveaux de gravité suivants :

• CRITICAL
  • Signification : la faille présente un risque immédiat et grave pour votre application ou l'infrastructure sous-jacente, ce qui peut entraîner une compromission complète du système.
  • Pourquoi elle est classée comme critique : elle atteint les seuils d'impact à conséquences graves (comme l'exécution de code à distance ou les écritures au niveau racine), est directement accessible depuis des limites non approuvées sans conditions préalables, et est étayée par une analyse de flux de données corrompues de haute confiance ou une démonstration de faisabilité validée exécutée dans le bac à sable de CodeMender.
• HIGH
  • Signification : la faille représente un problème de sécurité grave qui pourrait entraîner un contrôle non autorisé du système, une élévation des privilèges ou une exposition importante des données, mais nécessite des conditions spécifiques pour être exploitée.
  • Pourquoi elle est classée comme élevée : bien que l'impact de l'exploitation soit élevé (par exemple, des lectures de base de données arbitraires ou un piratage administratif), l'exploitabilité est légèrement limitée. Il peut nécessiter qu'un pirate informatique dispose d'une authentification utilisateur standard, dépende d'une configuration système spécifique ou nécessite une chaîne d'actions très précise.
• MEDIUM
  • Signification : la faille présente un risque modéré, exposant généralement des données restreintes ou permettant des perturbations localisées, mais elle présente un risque faible pour le système hôte.
  • Pourquoi il est classé comme moyen : l'exploit est fortement limité par l'accessibilité ou la complexité. Elle nécessite généralement une interaction active de l'utilisateur (comme cliquer sur un lien malveillant), des privilèges élevés ou des conditions complexes pour contourner les couches de défense, et sa zone d'impact finale est limitée.
• LOW
  • Signification : le résultat représente un risque de sécurité mineur ou un manque général d'hygiène de défense en profondeur qui ne présente pas de menace immédiate en soi.
  • Pourquoi elle est classée comme faible : elle présente une exploitabilité extrêmement faible ou un impact minimal. La détection est généralement utilisée par les pirates informatiques pour la reconnaissance ou l'empreinte de configuration plutôt que pour une compromission directe, et elle ne peut pas être utilisée pour exécuter du code arbitraire ou exfiltrer des données d'application sensibles.

Suivre l'utilisation des jetons

CodeMender écrit les journaux de session par appel localement sous ~/.codemender/logs/sessions/. Utilisez cm stats pour inspecter l'utilisation des jetons hors connexion, les taux de succès de cache (hit), le nombre d'interrogations et les durées d'exécution des commandes ou d'une session individuelle sans effectuer d'appels de backend.

• Résumer l'activité récente (--since) : affichez l'utilisation des jetons regroupée par type de commande sur une période récente (168h par défaut, ou sept jours). bash cm stats cm stats --since 24h
• Inspecter une session spécifique (--session) : affichez l'utilisation des jetons par tour pour un ID de session ou un préfixe d'ID de session unique, y compris les exécutions cm find --deep et cm find --diff multi-travailleurs.

  cm stats --session SESSION_ID_PREFIX

• Exporter au format JSON (--json et --jsonl) : émettez du code JSON en retrait avec --json ou du code JSON sur une seule ligne avec --jsonl pour l'ingestion de journaux structurés. La sortie JSON inclut model (ou models lorsque plusieurs modèles apparaissent) et team_id (ou team_ids lorsque plusieurs équipes sont agrégées).

  cm stats --json
  cm stats --jsonl
  cm stats --session SESSION_ID_PREFIX --jsonl

• Utilisation des attributs par équipe (--team-id ou CM_TEAM_ID) : définissez un identifiant d'équipe (1 à 63 caractères correspondant à [A-Za-z0-9._-]) lors de l'exécution d'analyses ou de corrections avec l'option --team-id, la variable d'environnement CM_TEAM_ID ou team_id dans ~/.codemender/config.yaml. Les sessions exécutées sans équipe configurée restent non attribuées dans la sortie JSON cm stats. Lorsque la fenêtre interrogée ne contient aucun enregistrement de session, --team-id, CM_TEAM_ID ou config.yaml fournit l'étiquette team_id de premier niveau.

  CM_TEAM_ID=TEAM_ID cm find .
  cm stats --jsonl

Pour les jobs Cloud Run et les étapes Cloud Build où les fichiers journaux locaux ne sont pas conservés, consultez Exporter la télémétrie des jetons vers Cloud Logging.

Collecter des données de diagnostic pour l'assistance

Si vous contactez l'assistance au sujet d'un problème avec CodeMender, exécutez cm support-bundle pour collecter les données de diagnostic dont l'assistance a besoin dans une seule archive .tar.gz. La commande lit les fichiers locaux et vérifie vos identifiants, votre configuration et votre connexion à CodeMender. Il n'importe rien : vous examinez l'archive et la joignez à votre demande d'assistance.

Pour collecter des données pour des sessions spécifiques, transmettez leurs ID ou préfixes d'ID. Pour trouver les ID de session, exécutez cm session list. Vous pouvez répéter --session :

cm support-bundle --session SESSION_ID

Sans --session, la commande collecte l'activité des 72 dernières heures. Pour modifier la fenêtre, utilisez --since :

cm support-bundle --since 24h

La commande écrit cm-support-bundle-TIMESTAMP.tar.gz dans le répertoire actuel et affiche son chemin d'accès. Pour choisir le chemin d'accès, utilisez --output (ou -o).

Contenu de l'archive

Par défaut, l'archive n'inclut pas le code source, les différences, ni les entrées et sorties des outils. Elle contient les éléments suivants :

• La version de la CLI, le système d'exploitation et la liste des éléments collectés.
• CM_* : variables d'environnement, et paramètres de projet et de proxy.
• Résultats des vérifications des identifiants, de la configuration et de la connectivité.
• Votre fichier de configuration et votre règle de commande.
• L'état, le modèle et la cible de chaque session sélectionnée.
• Durée par tour, utilisation des jetons, et noms et durées des appels d'outils.

Les données de session peuvent toujours contenir des chemins d'accès aux fichiers et aux répertoires, les arguments de chaque commande cm, les titres des résultats et les messages d'erreur de l'outil.

Si l'assistance vous demande plus de détails, ajoutez --include-content. Cela permet également de collecter les résultats, les correctifs générés et les journaux de débogage de la CLI, qui enregistrent les arguments de chaque appel d'outil. Ces fichiers peuvent contenir du code source de votre dépôt. Examinez donc l'archive avant de la partager.

cm support-bundle --session SESSION_ID --include-content

Dans les deux modes, la commande masque les jetons d'accès, les clés API, les clés privées, les en-têtes d'autorisation et les champs de mot de passe.

Pour ignorer les vérifications des identifiants, de la configuration et de la connectivité, par exemple lorsque vous exécutez la commande sans accès au réseau, utilisez --skip-health.

Maintenance de l'espace de travail

Pour réinitialiser les fichiers de suivi de l'état local et nettoyer les caches d'exécution temporaires, exécutez la commande suivante :

cm clean