Code Guardian 17.2 : ce qui change pour vous

Après la mise à jour vers Code Guardian 17.2 (disponible depuis le 28.09.2026), vous remarquerez trois choses : certaines commandes qui passaient jusqu'ici sans contrôle reçoivent désormais un refus. Les questions inutiles se font plus rares. Et davantage de fichiers sont considérés comme non testés, car seul un test réellement exécuté compte. Ces trois changements sont voulus ; vous n'avez rien à configurer. Exemple de faille fermée : l'outil Monitor de Claude Code échappait jusqu'ici aux contrôles de commandes.

Ce que vous devriez faire maintenant :

• En cas de nouveau refus, lisez l'indication qu'il contient — elle nomme souvent la voie qui fonctionne.
• Attendez-vous à davantage de fichiers non testés ; avant de modifier un tel fichier, Code Guardian exige un test d'épinglage (pin test).
• Si vous utilisez Codex sous Windows, répartissez les grosses modifications sur plusieurs patchs.

Quelles failles de sécurité Code Guardian 17.2 ferme-t-il ?

La version 17.2 ferme plusieurs voies par lesquelles une commande échappait aux contrôles ou une action risquée passait sans vérification.

• Monitor — qui lance des commandes comme Bash — échappait jusqu'ici aux contrôles de commandes ; il est désormais contrôlé de la même manière.
• Le verrou de suppression — qui contrôle les commandes de suppression risquées — lit désormais aussi le contenu des fichiers de script shell lancés, et non plus seulement le texte de la commande. Il refuse un tel script de plus de 64 kilo-octets ou un script écrit et lancé dans la même commande.
• Si seule la sortie d'une commande détermine la cible de la suppression — entre accents graves ou dans $(…) sans guillemets —, Code Guardian refuse désormais la commande, même sans suppression récursive et pour rmdir, shred et unlink.
• Les commandes de migration pour les bases de données Supabase exigent désormais le même rapport de contrôle que les autres commandes d'écriture sur base de données.
• Si vous copiez un fichier dans le répertoire personnel d'un serveur sans rapport de déploiement validé, Code Guardian refuse désormais au lieu de demander confirmation.
• Le verrou des secrets — qui vérifie les identifiants commités par inadvertance — contrôle désormais toujours l'ensemble du projet lorsqu'il est appelé depuis un sous-dossier, et non plus seulement ce sous-dossier.
• Le SQL est lu dans l'ordre où le client de base de données le lit réellement — ce qui ferme des formes qui passaient jusque-là inaperçues.

Pour vous : vous obtenez désormais un refus plutôt qu'un passage sans contrôle — et il indique souvent directement ce qu'il faut faire.

Quelles fausses alertes disparaissent ?

Plusieurs contrôles posaient jusqu'ici une question alors qu'il n'y avait rien à craindre — ces fausses alertes disparaissent avec la 17.2.

• Le verrou des secrets ne pose plus de question pour les commandes git qui ne commitent rien du tout.
• La clôture de projet — qui limite les modifications à la zone du projet — ne refuse plus les propres fichiers de travail de Code Guardian.
• Un heredoc contenant des trémas ou d'autres caractères spéciaux ne pose plus de question sur la langue du système lorsqu'aucun contrôle n'en dépend.

Pour vous : dans ces trois cas, vous n'avez plus de question là où il y en avait une auparavant.

Où la 17.2 juge-t-elle volontairement plus souplement ?

La 17.2 juge volontairement plus souplement à trois endroits bien délimités.

• La suppression de votre propre environnement virtuel Python sous ~/.venvs/<name> est désormais libre ; les dossiers collectifs eux-mêmes restent verrouillés.
• Un script de déploiement qui n'était considéré comme tel qu'à cause de son nom est désormais lu par la 17.2. S'il ne contient ni transfert, ni appel à distance et ne lance aucun autre programme, il s'exécute sans question.
• L'exception pour les bases de données jetables ne s'applique désormais qu'à une liste fixe d'adresses locales standard, jamais via le réseau.

Pour vous : les assouplissements sont étroitement bornés : tout doute sur le script de déploiement reste un refus, et l'exception pour les bases de données ne vaut jamais via le réseau.

Qu'est-ce qui change pour la couverture de tests ?

Un fichier n'est désormais considéré comme testé que si un test réellement exécuté l'atteint.

Ce qui ne compte plus comme preuve :

• un test ignoré, mis en commentaire ou vide
• un simple import du fichier en tête de fichier, si le nom importé n'est utilisé dans aucun test exécuté

Pour vous : vous voyez désormais plus de fichiers comme non testés — non pas une nouvelle faiblesse de votre code, mais une mesure plus stricte. Le gate de caractérisation (le contrôle avant une modification de code non testé) exige là un test d'épinglage (un test qui fige le comportement existant avant la modification) où il laissait passer auparavant.

Quoi d'autre de nouveau ?

Deux nouvelles capacités concernent la manière dont Code Guardian est lui-même contrôlé et dont plusieurs sessions collaborent.

• Un agent de contrôle supplémentaire lit un diff terminé, mais ne peut rien exécuter, écrire ni supprimer ; ses constats valent comme soupçon tant qu'une exécution ne les a pas prouvés. Cela fait désormais 14 agents de contrôle au lieu de 13.
• Lorsque plusieurs sessions travaillent sur le même projet, Code Guardian propose à partir de trois sessions un synchroniseur de tâches — et vous le demande au préalable. Il compare les tâches ouvertes avec git à intervalle fixe (20 minutes par défaut, réglable) et ne fait que lire.
• Si personne n'est disponible pour répondre à une question, vous pouvez désormais définir par fichier de configuration qu'une question des verrous de commandes devienne un refus accompagné d'une indication d'action. Sans ce réglage, tout reste comme avant.

Pour vous : un agent de contrôle supplémentaire, en lecture seule, peut désormais s'exécuter en parallèle, et à partir de trois sessions Code Guardian propose une synchronisation des tâches.

Qu'est-ce qui change sous Windows ?

Sous Windows, on a mesuré pour la première fois ce que coûte réellement un contrôle : en médiane, environ 1,7 seconde avant et 0,6 seconde après une commande Bash ; la somme par appel est en médiane d'environ 2,4 secondes (mesuré sur GitHub windows-latest). Le démarrage de session mesure en outre le lancement du programme sur votre machine. Pour vous : le démarrage de session vous avertit à l'avance si la limite de temps est trop serrée pour cela.

Qu'est-ce qui change pour les utilisateurs de Codex ?

Pour la CLI OpenAI Codex, la 17.2 ferme ses propres failles et rend le contrôle sous Windows plus complet.

• Avec le réglage par défaut de Codex, le modèle pouvait ouvrir une console et y saisir des commandes ; Codex ne déclenche alors aucun contrôle, et les commandes saisies s'exécutaient donc sans vérification. L'installateur désactive désormais cette voie dans votre config.toml.
• Sous Windows, Code Guardian ne contrôlait jusqu'ici pas certains fichiers lors de gros patchs, car la ligne de commande devenait trop longue. Désormais, aucun fichier d'un patch ne reste sans contrôle.
• La limite de temps pour le contrôle d'un patch expirait jusqu'ici trop tôt ou trop tard selon le moment du démarrage ; elle se termine désormais à l'heure prévue.
• Les verrous de commandes de la sortie Codex reçoivent eux aussi des corrections de sécurité, par exemple la lecture des fichiers de script shell lancés.

Pour vous : sous Windows, Code Guardian contrôle un patch de 10 fichiers en environ 24 secondes ; à partir de 20 fichiers, il s'arrête à la limite de temps, par sécurité sous forme de refus. Répartissez donc les grosses modifications en plusieurs patchs.

Quelles limites restent ouvertes ?

Ces limites subsistent dans la 17.2 :

• La détection de formes du contrôle de sécurité reconnaît des formes, pas une exploitabilité réelle, et ne suit pas les données au-delà des frontières de fonctions et de fichiers.
• Une fausse alerte connue du verrou de suppression pour les fonctions auxiliaires Python de répertoires de test temporaires subsiste : un assouplissement n'a pas passé le propre contrôle en quatre tours et a été retiré.
• Le rapport de migration annoncé pour la 17.2 dans le projet cible sous Windows n'est pas encore inclus ; il viendra dans une version ultérieure.
• Pour la couverture de tests, les méthodes auxiliaires et les préparations de test (fixtures) ne comptent toujours pas comme preuve, même si un test exécuté les appelle ; on n'évalue pas si une condition fait réellement ignorer un test.

Comment la 17.2 a-t-elle été vérifiée ?

La 17.2 a traversé une batterie de contrôles avant sa publication — le tableau donne les chiffres.

Pour situer : quatre niveaux ont été ajoutés, aucun n'a disparu, et aucun verdict n'a changé. Les deux directions d'erreur — un contrôle qui se déclenche à raison, un contrôle qui laisse passer à raison ce qui est autorisé — ont été entièrement réussies.

Que mesure la mesure comparative ?

Une mesure comparative indépendante teste si une mission se déroule différemment avec Code Guardian que sans. Elle ne vérifie pas la technique des contrôles, mais leur effet sur le résultat du travail.

État de la mesure comparative : dans le scénario S1, la 17.2 a été comparée sur 10 essais avec Code Guardian contre 5 essais sans Code Guardian. En moyenne, on obtient 5,60 points contre 5,20 — avec une valeur p de 0,3986, aucun écart n'est donc prouvé.

Bilan sur toutes les comparaisons valides de la v16.116 à la 17.2 (8 mesures) :

• 4 avec écart prouvé
• 3 non tranchables
• 1 sans écart prouvé

Un essai sans écart prouvé est un résultat, pas un défaut — mais pas une preuve que Code Guardian agit.

Plus d'informations sur le produit sur la page produit.

Questions fréquentes sur Code Guardian 17.2

Dois-je écrire immédiatement des tests pour chaque fichier désormais non testé ?

Non. Le gate de caractérisation n'exige un test d'épinglage que lorsque vous voulez modifier un tel fichier.

Où trouver les prérequis et la configuration ?

Dans la documentation technique sur provimedia.de/code-guardian/technik — vous y trouverez les prérequis système, tous les réglages et l'interface de mise à jour.

Comment savoir que Code Guardian aide réellement ?

L'effet est montré par la mesure comparative dans la section ci-dessus, pas par la batterie de contrôles — celle-ci montre seulement que les contrôles fonctionnent comme prévu.

Comment obtenir la version 17.2 ?

Le paquet se trouve dans le portail client. La manière dont Code Guardian se maintient ensuite à jour est expliquée sur provimedia.de/code-guardian/updates.

Que faire si un nouveau refus bloque mon déroulement habituel ?

Lisez le refus : dans de nombreux cas, il nomme la voie qui fonctionne, par exemple en étapes séparées. Les explications de fond figurent dans la documentation technique.

Sources

• Guide de mise à jour publié de la version 17.2 (portail client)
• Justificatif de contrôle de la version 17.2 par rapport à la v17.1 (portail client)

Date : 29.09.2026