Gérer les sessions et exporter des rapports

CodeMender suit chaque tentative d'analyse, de validation et de correction en tant que session avec état soutenue 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 détaillés sur les résultats.

Gestion de la session

L'interface de ligne de commande CodeMender conserve les sessions d'exécution avec état en local, ce qui vous permet de suivre les tâches actives, de reprendre les workflows interrompus et d'exporter les rapports de sécurité.

Lister les sessions actives et passées

Exécutez la commande suivante pour lister toutes les sessions, leurs états (RUNNING, WAITING_FOR_TOOL, COMPLETED, FAILED, CANCELLED) et les chemins cibles :

cm session list

Reprendre une session interrompue

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

cm session resume SESSION_ID

Annuler une session en cours

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

Table de terminal (par défaut)

Liste récapitulative des résultats.

cm report

Rapport HTML

Générez 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érez un rapport Markdown compatible avec GitHub.

cm report --format md

JSON

Exporter tous les détails des résultats de 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 diffs unifiées complètes des correctifs générés dans le rapport. bash cm report --patches
  • Filtrer par 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 (ou un préfixe) spécifique 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 été détectée lors d'une analyse (ou importée à partir d'un outil tiers), mais n'a pas encore été vérifiée, corrigée ni marquée comme inactive.
    • Traitement : 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 correction (cm fix).
  • FIXED
    • Explication : CodeMender a généré un correctif pour la faille, appliqué le diff à votre codebase locale, et compilé et exécuté avec succès des tests de validation pour prouver que l'exploit ne fonctionne plus.
    • Comment cela fonctionne : une fois qu'un correctif est confirmé comme résolvant le problème sans casser la logique de code existante, CodeMender fait passer le résultat à FIXED. Il restera dans cet état, sauf si une future analyse détecte une régression.
  • DISMISSED
    • Ce que cela signifie : la faille est désignée comme inactive, soit parce qu'elle a été identifiée comme un faux positif ou déjà corrigée, soit parce que le résultat n'a pas un niveau de confiance suffisant pour être confirmé comme exploitable (y compris par rapport au modèle de menace de votre projet, le cas échéant, s'il a été fourni lors de l'intégration).
    • Comment cela fonctionne : marquer un élément comme DISMISSED désactive les futures alertes et exclut le résultat de votre sortie CLI active avec cm report --status OPEN. Si vous réexécutez cm verify sur un résultat ignoré, les éléments ignorés sont réexaminés ou restaurés.
  • REOPENED
    • Explication : 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 est-ce géré : cet état indique une régression (par exemple, une mauvaise fusion Git qui annule le correctif) ou une stratégie d'atténuation qui a échoué. Il signale le problème pour une réévaluation immédiate et exige des développeurs qu'ils examinent le processus de correction.

Niveaux de gravité des failles

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

  • CRITICAL
    • Ce que cela signifie : la faille présente un risque immédiat et grave pour votre application ou l'infrastructure sous-jacente, pouvant potentiellement entraîner une compromission complète du système.
    • Pourquoi cette catégorie est-elle considérée comme critique ? Elle répond aux seuils d'impact à conséquences élevées (comme l'exécution de code à distance ou les écritures au niveau racine), est directement accessible à partir de limites non fiables sans prérequis et est soutenue par une analyse du flux de contamination à haute confiance ou une preuve de concept (PoC) validée exécutée dans le bac à sable de CodeMender.
  • HIGH
    • Ce que cela signifie : cette faille représente un grave défaut de sécurité 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 qui nécessite des conditions spécifiques pour être exécutée.
    • Pourquoi cette catégorie est-elle considérée comme élevée ? Bien que l'impact de l'exploitation soit élevé (par exemple, lectures arbitraires de bases de données ou piratage administratif), l'exploitabilité est légèrement limitée. Il peut exiger d'un pirate informatique qu'il dispose d'une authentification utilisateur standard, qu'il dépende d'une configuration système spécifique ou qu'il nécessite une chaîne d'actions très précise.
  • MEDIUM
    • Signification : la faille présente un risque modéré, qui expose généralement des données soumises à restriction ou permet des perturbations localisées, mais qui présente un faible risque pour le système hôte.
    • Pourquoi cette catégorie ? L'exploitation est fortement limitée par l'accessibilité ou la complexité. Il nécessite généralement une interaction utilisateur active (comme cliquer sur un lien malveillant), des privilèges élevés ou des conditions complexes pour contourner les couches de protection, et sa zone d'impact ultime 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 constitue pas une menace immédiate en soi.
    • Pourquoi cette catégorie est-elle considérée comme faible ? : elle présente une exploitabilité extrêmement faible ou un impact minimal. Les pirates informatiques utilisent généralement cette découverte pour la reconnaissance ou l'empreinte digitale de configuration plutôt que pour une compromission directe. Elle ne peut pas être utilisée pour exécuter du code arbitraire ni pour exfiltrer des données d'application sensibles.

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