Audits de code

Les audits de code sont expérimentaux.

Un audit de code est un examen de sécurité d’un projet réalisé par votre agent de codage local. Cliquez avec le bouton droit sur un projet dans la barre latérale et choisissez « Expérimental » → « Audit de code », puis « Nouvel audit ». Sous « Assistant local », choisissez « Codex » ou « Claude » ; choisissez ensuite un « Modèle », un « Effort de réflexion » et le « Périmètre », puis cliquez sur « Lancer l’audit ». La page du rapport indique la phase actuelle de l’analyse. « Session de l’assistant » affiche les appels d’outils d’origine de l’agent, son analyse et les demandes d’autorisation en attente ; répondez-y à cet endroit pour que l’audit puisse se poursuivre. Le rapport apparaît lorsque Codex Security scelle ses résultats.

L’audit s’exécute sur la machine qui héberge le projet et utilise l’interface en ligne de commande (CLI) installée de l’agent sélectionné, avec sa connexion, sa configuration et sa gestion des autorisations existantes (« Utilise la connexion et la configuration de l’assistant local. Aucune API de modèle supplémentaire à configurer. »). VelaTerm ajoute un serveur MCP Codex Security pour la seule session d’audit ; vos autres serveurs MCP restent inchangés, et VelaTerm n’appelle lui-même aucune API de modèle. La CLI doit être installée, connectée et dans les limites de son compte. La configuration propre de la CLI peut sélectionner un fournisseur de modèles ; VelaTerm ne la modifie pas.

L’élément « Audit de code » apparaît aussi pour les collections. Une collection sans dossier racine ne peut pas faire l’objet d’un audit.

Modèles et effort de réflexion

La liste des modèles est celle qu’utilise la boîte de dialogue de nouvelle session pour cet agent, et elle tient compte des arguments de lancement par défaut de l’agent ; elle correspond donc à la façon dont l’audit s’exécutera. « Modèle par défaut » conserve le choix propre de l’agent. « Effort de réflexion » devient disponible lorsque vous choisissez un modèle qui propose des niveaux d’effort ; « Automatique » conserve le choix propre de l’agent. Si la liste ne peut pas être chargée, un bouton permettant de réessayer apparaît. Le serveur vérifie les combinaisons explicites, et l’audit enregistre les valeurs sélectionnées pour son historique et pour les exécutions ultérieures. La présence d’un modèle dans la liste ne signifie pas que votre compte peut l’utiliser. Les échecs du fournisseur, y compris l’épuisement des limites d’utilisation, mettent fin à l’audit en échec.

Les nouveaux audits demandent que l’analyse soit rédigée dans la langue de l’interface. Les champs de protocole, les chemins, les identifiants et les extraits de source cités restent inchangés.

Intégration de Codex Security

VelaTerm intègre la version publique @openai/codex-security@0.1.26, distribuée sous licence Apache-2.0, dont le manifeste d’extension indique la version 0.1.95 ; la page de nouvel audit affiche ces deux versions. Les compétences, références, schémas, scripts, environnement d’exécution et licence d’origine sont inclus, et UPSTREAM.json enregistre la source du paquet, sa valeur d’intégrité et les empreintes des fichiers.

Chaque nouvel audit enregistre une véritable analyse dans l’atelier (workbench) amont. L’agent lit la compétence d’entrée intégrée et utilise les outils MCP et le format de résultat amont. Les enregistrements de l’ancien flux de travail par lots, implémenté indépendamment, restent lisibles et portent la mention « Ancien audit · Cet enregistrement n’a pas utilisé le processus Codex Security. »

Les deux agents utilisent le même flux de travail amont. Le SDK TypeScript public pilote l’environnement d’exécution de Codex et ne propose pas d’exécuteur Claude Code ; VelaTerm s’intègre donc par l’intermédiaire du serveur MCP amont et de l’atelier local. La prise en charge de Claude Code repose sur un adaptateur de VelaTerm ; le projet amont ne revendique pas de prise en charge officielle de Claude.

L’environnement d’exécution nécessite Node.js dans le PATH, dans une version prise en charge par le paquet amont, ainsi que Python 3.10 ou version ultérieure ; Python 3.10 nécessite aussi le paquet tomli, que Python 3.11 et les versions ultérieures remplacent par le module intégré tomllib. VelaTerm vérifie les ressources intégrées et les décompresse dans son répertoire de données. Il ne les installe pas dans votre configuration Codex ou Claude.

Périmètre et déroulement

• Dépôt entier exécute l’analyse Standard amont sur un instantané fixe de la cible et sur la politique de sécurité du dépôt.
• Dossier ou fichier exécute l’analyse Standard avec un « Chemin relatif » exact. D’autres fichiers source peuvent être lus pour comprendre une chaîne d’appels, sans que ces zones soient présentées comme ayant fait l’objet d’un audit complet.
• Modifications de l’arbre de travail exécute la compétence amont d’analyse des différences sur un ensemble fixe de modifications Git. Ce mode inclut les modifications indexées, non indexées et non suivies que le résolveur de cible amont prend en charge, et conserve les preuves de référence des fichiers supprimés.

L’analyse Standard lit skills/security-scan/SKILL.md et references/core-scan.md. Elle effectue des vérifications préalables, une analyse indépendante de la référence et de l’architecture, des investigations ancrées dans le code source, des points de contrôle sur les résultats potentiels, un examen des contre-preuves, une validation et un rapprochement de la couverture. Des sous-agents indépendants sont utilisés lorsque l’agent les prend en charge ; sinon, le mode séquentiel de repli prévu en amont s’applique, et ses limites doivent être signalées. Un réglage du nombre de sous-agents ne prouve pas à lui seul que des sous-agents indépendants ont été exécutés.

Les audits de l’arbre de travail lisent skills/security-diff-scan/SKILL.md. Ils fixent la cible, établissent le modèle de menaces, préparent et énumèrent les éléments à examiner, recherchent des résultats potentiels, les valident, analysent les chemins d’attaque et soumettent le brouillon de résultat pour finalisation. Examiner uniquement le contenu actuel des fichiers modifiés ne remplace pas ce processus.

L’atelier amont n’accepte que des répertoires comme périmètre. Pour que la sélection d’un fichier reste possible, l’environnement d’exécution installé applique deux correctifs ciblés dont les empreintes sont enregistrées : un fichier existant est accepté comme périmètre et compte comme une seule entrée d’instantané. Les originaux intégrés restent inchangés, et le fichier ADAPTER.json installé enregistre à la fois les empreintes d’origine et les empreintes adaptées. La sélection d’un fichier ne se transforme jamais en analyse de tout son répertoire.

Les instructions d’audit interdisent de modifier le code source, d’appliquer des correctifs, de publier quoi que ce soit et de modifier la configuration de l’agent. Les autorisations d’outils propres à l’agent restent en vigueur. Ces instructions ne constituent pas un bac à sable du système d’exploitation. La validation doit indiquer ce qui a réellement été vérifié, et un résultat d’analyse statique ne signifie pas qu’une exploitation a été reproduite (« Analyse statique uniquement. La couverture déclarée ne garantit pas la détection de toutes les vulnérabilités. Aucun exploit n’est exécuté. »).

Rapports, couverture et annulation

Les résultats qui font foi sont les fichiers amont scan-manifest.json, findings.json et coverage.json. Le module de finalisation amont les valide et les scelle, puis génère le rapport lisible. VelaTerm importe ces fichiers et vérifie l’emplacement de chaque résultat ainsi que les lignes de source exactes, en considérant les fins de ligne LF et CRLF comme équivalentes. Une structure valide et des lignes de source concordantes ne prouvent pas à elles seules qu’un résultat est exploitable. Si les preuves dans le code source ne concordent pas, l’audit reste à l’état « Échec » et ses résultats ne sont pas acceptés comme validés. Le rapport amont scellé reste disponible, et les exports Markdown placent l’échec de validation en tête sans réécrire le rapport.

Avant le scellement, VelaTerm vérifie les chemins, les plages de lignes et les extraits du brouillon avec le même vérificateur que celui utilisé lors de l’importation. Si les preuves ne concordent pas, l’analyse reste non scellée et l’agent est informé des emplacements à corriger. L’outil de finalisation de Codex Security génère et scelle ensuite le rapport. Cette vérification ne réécrit jamais les extraits, ne supprime aucun résultat et ne modifie pas les résultats scellés. L’importation répète la vérification, de sorte que des modifications ultérieures du code source ne peuvent pas transformer silencieusement des preuves invalides en résultat réussi.

La couverture provient des traces de vérification et des décisions amont, et non du nombre de fichiers que l’agent affirme avoir lus. Les résultats potentiels non résolus, le travail reporté, les exclusions et les avertissements de finalisation restent visibles. Une analyse scellée dont la couverture est incomplète est affichée comme « Couverture partielle ». Même une couverture complète ne garantit pas que toutes les vulnérabilités ont été trouvées.

Lorsque l’agent termine un tour alors que l’analyse a encore du travail à effectuer, VelaTerm poursuit la même session et la même analyse, en conservant les résultats existants et ceux des sous-agents. Les demandes d’autorisation restent en attente (« Autorisation ou saisie requise »), et une annulation ou une erreur du fournisseur interrompt la poursuite automatique. Si trois tours consécutifs se terminent sans aucune évolution de la progression de l’examen amont, des résultats ou de la couverture, l’audit s’arrête avec une erreur d’analyse incomplète et conserve ses points de contrôle.

L’onglet « Rapport » affiche les résultats conservés, les preuves dans le code source et les limites de couverture. Chaque résultat dispose de sa propre URL et présente son chemin d’attaque, la manière dont il a été validé et la conclusion (lorsqu’elle est fournie), des recommandations de correction et les extraits de source signalés ; vérifiez l’état de l’audit avant de considérer ces extraits comme vérifiés. L’onglet « Fichiers du rapport » conserve le rapport complet généré en amont et l’identifiant de l’analyse. Une analyse en cours affiche les versions du paquet et de l’extension amont, la phase et la progression réelles, ainsi que les avertissements ; tant qu’aucun rapport scellé n’existe, les informations de progression et de points de contrôle sont affichées à la place d’une évaluation vide. Dans la « Session de l’assistant », la zone de message habituelle et le retour en arrière sont désactivés afin qu’aucun tour sans rapport avec l’audit ne puisse le remplacer ; les demandes d’autorisation restent utilisables.

« Annuler » arrête l’analyse amont et l’agent. Les points de contrôle enregistrés restent disponibles lorsque l’atelier amont peut les sceller, et ils conservent leur état annulé ou en échec. Des résultats tardifs ne peuvent pas réactiver un audit annulé. Après un redémarrage, VelaTerm rapproche l’état amont : un résultat terminé et scellé peut être importé, et une exécution inachevée est marquée « Interrompu », ses fichiers conservés restant distinguables d’un résultat terminé.

« Lancer l’audit » sur un enregistrement existant crée une nouvelle analyse de la cible actuelle avec l’agent et les sélections enregistrés. Cette action ne reprend pas un tour de modèle arrêté et ne réutilise pas un ancien verdict.

L’historique des audits, le formulaire de nouvel audit, le détail des rapports et la session de l’agent disposent chacun de leur propre URL ; ils peuvent donc être ouverts directement, actualisés et parcourus avec les boutons Précédent et Suivant du navigateur. Sur les écrans étroits, l’historique et le détail sont affichés dans des vues distinctes.

Exports et limites

« Exporter le rapport » propose les formats Markdown et JSON. Les exports Markdown contiennent le rapport amont lorsqu’il existe ; sinon, ils indiquent clairement qu’il s’agit de l’enregistrement d’une analyse incomplète. Les exports JSON conservent toutes les données importées ainsi que les métadonnées propres à VelaTerm. Le dossier d’analyse amont conserve aussi le fichier SARIF généré et les autres fichiers. Les exports peuvent contenir des extraits de source et des détails sur des vulnérabilités ; partagez-les avec prudence.

Cette interface propose les audits Standard et les audits des différences de l’arbre de travail. Les autres compétences intégrées, telles que les analyses approfondies, la correction, la vérification des correctifs et le suivi de tickets externes, sont conservées en tant que ressources amont, mais ne sont pas proposées comme actions distinctes. Un audit n’applique pas de correctifs, ne publie pas de résultats, ne crée pas de tickets et n’ouvre pas de demandes de fusion (pull requests).

Diagnostic

Le serveur consigne le cycle de vie de l’audit et les informations de phase amont dans runtime-*.log, dans le répertoire des journaux de l’application. VLX_LOG_DIR définit l’emplacement commun ; lorsqu’il n’est pas défini, VLX_SECURITY_LOG_DIR définit l’emplacement des événements d’audit. VLX_SECURITY_LOG_LEVEL=error les limite aux échecs, et off les désactive. Les invites et les réponses sont décrites par leur taille et leur empreinte SHA-256 ; le code source complet, les identifiants de connexion et les réponses complètes de l’IA ne sont pas copiés dans le journal, et les messages bruts du fournisseur ne sont pas conservés. Les noms de modèles personnalisés sont remplacés par des identifiants anonymes valables uniquement dans le processus en cours. Le nombre de jetons, lorsqu’il est disponible, correspond à l’utilisation cumulée de la session. La conversation de l’agent conserve son historique habituel.

Pour un audit en échec, lisez l’explication du fournisseur dans le rapport ou ouvrez « Session de l’assistant ». Résolvez les problèmes de connexion, d’environnement d’exécution, d’autorisations ou de limites de compte avant de lancer un autre audit. Un serveur MCP connecté indique seulement que les outils sont disponibles ; il n’indique pas que le modèle a mené l’analyse à son terme.

Références amont : présentation de la CLI, référence de la CLI, code source public.