Gérer les sessions et exporter des rapports

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 mises en pause et exporter des rapports de résultats détaillés.

Gestion de la session

L'interface 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, 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 de point de contrôle :

cm session resume SESSION_ID

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 backend :

cm session cancel SESSION_ID

Afficher les rapports et exporter les correctifs

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

Formats de sortie

Tableau 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 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

Indicateurs de filtrage et de tri

  • Afficher les correctifs de code proposés (--patches) : incluez les diffs unifiés complets des corrections générées 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 (tels que les journaux et les scripts d'exploitation). bash cm report --artifacts
  • Trier les résultats (--sort) : triez les résultats par severity (gravité, par défaut) ou time (heure). 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 failles 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.
    • Gestion : 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 être vérifiées (cm verify) ou corrigées (cm fix).
  • FIXED
    • Signification : CodeMender a généré un correctif pour la faille, appliqué le diff à votre base de code locale, et compilé et exécuté avec succès les tests de vérification pour prouver que l'exploitation ne fonctionne plus.
    • Gestion : 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, car elle a été identifiée comme un faux positif ou déjà corrigée, ou le résultat n'est pas suffisamment fiable pour être confirmé comme exploitable (y compris par rapport au modèle de menace de votre projet, si vous en avez fourni un lors de l'intégration).
    • Gestion : le fait de 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. L'exécution de 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 base de code.
    • Gestion : cet état indique une régression (par exemple, une mauvaise fusion Git qui rétablit 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 que les développeurs examinent le processus de correction.

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 est-elle classée comme critique ? Elle répond à des 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 de flux de contamination à haute fiabilité ou une preuve de concept (PoC) validée exécutée dans le bac à sable de CodeMender.
  • HIGH
    • Signification : la faille représente une faille 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 des données importante, mais nécessite des conditions spécifiques pour être exécutée.
    • Pourquoi est-elle classée comme élevée ? Bien que l'impact de l'exploitation soit élevé (par exemple, lectures de base de données arbitraires ou piratage administratif), l' exploitabilité est légèrement limitée. Un pirate informatique peut avoir besoin d'une authentification utilisateur standard, dépendre d'une configuration système spécifique ou nécessiter 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 autorisant des perturbations localisées, mais elle présente un faible risque pour le système hôte.
    • Pourquoi est-elle classée comme moyenne ? L'exploitation est fortement limitée par l'accessibilité ou la complexité. Elle 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 défensives, 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 constitue pas une menace immédiate en soi.
    • Pourquoi est-elle classée comme faible ? Elle présente une exploitabilité extrêmement faible ou un impact minimal. Le résultat est généralement utilisé par les pirates informatiques pour la reconnaissance ou l'empreinte de configuration plutôt que pour une compromission directe, et il ne peut pas être utilisé 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 libérer de l'espace dans les caches d'exécution temporaires, exécutez la commande suivante :

cm clean