if ( !emtpy($headline_subheadline ) ) : ?>
Les instructions et les hooks du référentiel peuvent modifier les environnements de développement. Les équipes de sécurité ont besoin de processus d’approbation qui suivent les modifications depuis les demandes d’extraction jusqu’à leur exécution.
endif; ?>
Une pull request ajoute une étape de configuration utile pour un assistant de codage IA. Aucune modification de la source de l’application. La description l’appelle une amélioration de l’expérience du développeur, et le réviseur voit un court fichier de configuration à côté de quelques instructions Markdown.
Avant de l’approuver, le réviseur doit répondre à une autre question : que permettra ce changement de s’exécuter sur la machine d’un collègue ?
Le problème va au-delà d’un hypothétique empoisonnement du stockage. Dans une analyse du 8 octobre sur la distribution des compétences des agents, StepSecurity a revisité la campagne June Miasma, qui a implanté la configuration de l’outil d’IA et de l’éditeur dans un référentiel Microsoft sans modifier la source de l’application. La configuration était destinée à déclencher la collecte d’informations d’identification via les outils de développement. La publication d’octobre décrit un produit d’inventaire, mais la campagne sous-jacente illustre un problème opérationnel plus large : la fusion d’un changement de configuration peut distribuer des instructions d’exécution aux personnes travaillant dans ce référentiel.
StepSecurity signale également que la validation portait un indicateur skip-CI et un horodatage antidaté, et qu’elle a déplacé l’exécution du code de l’installation du package vers l’ouverture du dossier. Un contrôle qui s’exécute uniquement dans le pipeline de build ne voit jamais ce chemin. Le premier point de contrôle fiable est la pull request, et elle nécessite une personne qui sait ce que le fichier peut déclencher.
Je recommande de donner à ces modifications un propriétaire nommé et un chemin de révision exécutoire. Une organisation doit être en mesure d’identifier qui a approuvé un hook, ce que couvre l’approbation et où la version approuvée est autorisée à s’exécuter.
Examinez le comportement derrière le nom de fichier
Un fichier de référentiel peut servir à plusieurs fins. Il peut décrire une convention de codage, diriger un agent vers un script, enregistrer un outil ou organiser l’exécution d’une commande lors d’un événement du cycle de vie. Ces différences comptent plus que l’extension.
Une instruction Markdown n’est pas un code automatiquement exécutable. Il peut néanmoins influencer un agent autorisé à exécuter des commandes. Un paramètre JSON peut enregistrer directement une commande shell. L’examen devrait établir le mécanisme, le déclencheur et l’autorité disponible lors du déclenchement.
Les compétences montrent pourquoi le nom de fichier n’est pas un bon guide. StepSecurity note que le champ outils autorisés d’une compétence peut permettre à l’agent d’utiliser les outils répertoriés sans invite d’autorisation pendant le tour qui appelle la compétence, et que la documentation de Claude Code indique que la confiance dans l’espace de travail ne contrôle pas ce champ. Un fichier SKILL.md est Markdown, donc dans une pull request, il a tendance à être examiné comme un README.
La référence actuelle des hooks d’Anthropic indique que les hooks de commande s’exécutent avec les autorisations de l’utilisateur. Il distingue également l’approbation d’un espace de travail interactif du fonctionnement non interactif : les hooks de fichiers de paramètres dans un référentiel peuvent s’exécuter dans une session non interactive sans que la boîte de dialogue de confiance soit affichée à un utilisateur interactif. Le comportement exact dépend de la surface de configuration et du type de session. Un contrôle testé sur le terminal d’un développeur doit donc être retesté dans le workflow automatisé qui utilise le même référentiel.
La même page nomme des mesures d’atténuation pratiques. Avant de créer un script pour une exécution non interactive sur un référentiel que personne dans l’équipe n’a écrit, examinez ses fichiers de paramètres .claude, démarrez l’exécution en mode simple ou désactivez les hooks pour cette exécution. Les administrateurs peuvent également utiliser le paramètre de hooks gérés uniquement afin que les hooks d’utilisateur, de projet, locaux et de plug-in soient bloqués. Laquelle de ces adéquations dépend des outils de l’organisation, et chacune doit être testée plutôt que supposée.
Pour un hook d’installation proposé, le réviseur doit être en mesure de retracer la commande jusqu’à son script et ses dépendances. Si le script télécharge un autre programme, déterminez comment ce programme est sélectionné et vérifié. S’il lit les informations d’identification ou accède au réseau, demandez pourquoi l’étape de configuration a besoin de ces fonctionnalités.
Ces questions doivent accompagner le changement tandis que son auteur peut en expliquer l’intention. Les découvrir après la distribution laisse chaque développeur concerné prendre une décision de confiance individuelle.
Rendre la propriété exécutoire
Les équipes de productivité d’ingénierie sont souvent les mieux placées pour maintenir une configuration partagée d’assistant de codage. La sécurité doit définir les conditions qui nécessitent un deuxième réviseur, comme l’ajout de hooks exécutables, l’élargissement de l’accès au réseau ou l’appel d’un nouvel outil externe. L’équipe d’application reste responsable de savoir si l’intégration appartient à son flux de travail.
Cela ne nécessite pas de créer une file d’attente d’approbation pour chaque préférence de formatage. Définissez les changements de comportement qui méritent un examen minutieux et acheminez ces changements vers les personnes qui comprennent les outils.
La documentation du propriétaire de code de GitHub explique comment les règles de propriété fonctionnent avec les révisions requises. Un dossier CODEOWNERS à lui seul ne rend pas son approbation obligatoire ; la protection de branche correspondante doit l’exiger. GitHub recommande également de protéger le fichier de propriété lui-même.
Appliquez le mécanisme choisi à la configuration de l’agent et aux scripts qu’il appelle. Protéger un fichier de paramètres tout en laissant son script d’assistance référencé en dehors de la règle de révision crée une lacune évidente. Vérifiez la règle efficace avec un exemple de demande d’extraction plutôt que de vous fier à la présence d’un fichier de stratégie.
Permettez aux modifications légitimes de se déplacer rapidement via un chemin connu. L’examinateur doit recevoir une explication concise du déclencheur, de l’accès requis et des effets secondaires attendus. Un hook qui formate des fichiers modifiés ne devrait pas avoir besoin de la même justification qu’un hook qui contacte un service externe ou modifie la configuration globale d’un utilisateur.
Vérifiez ce que l’environnement de développement charge réellement
L’examen du référentiel ne couvre qu’une partie de l’environnement. Les développeurs peuvent également installer des compétences partagées, des plugins et une configuration au niveau utilisateur en dehors d’un projet. Un référentiel approuvé peut donc fonctionner avec des instructions supplémentaires que ses responsables n’ont jamais examinées.
Établissez une base de référence pour les outils pris en charge et les méthodes de lancement. Enregistrez les origines et les versions des ajouts approuvés et fournissez un moyen d’inspecter la configuration effective. Lorsque les copies locales diffèrent, comparez le contenu avant de décider si la différence est malveillante ou inoffensive.
Les conseils Workspace Trust de Microsoft pour Visual Studio Code décrivent le mode restreint, qui limite les fonctionnalités permettant d’exécuter le contenu de l’espace de travail. Il avertit également qu’une extension malveillante peut ignorer cette limite. La confiance dans l’espace de travail est un contrôle utile dans son champ d’application documenté ; elle doit être associée à une politique d’extension délibérée et à un environnement approprié au stockage inspecté.
Utilisez des référentiels inconnus dans un environnement isolé sans informations d’identification de production montées régulièrement. Évitez de traiter un conteneur comme un isolement suffisant s’il hérite des secrets du développeur ou de l’accès à l’hôte. Examinez ces connexions explicitement.
Pour un travail quotidien approuvé, rendez la configuration sécurisée pratique. Publiez les configurations maintenues, expliquez comment demander un ajout et fournissez un flux de travail d’inspection propre. Si la conformité impose aux développeurs de reconstruire manuellement leur environnement chaque matin, elle sera difficile à maintenir.
Testez le chemin d’approbation avant de lui faire confiance
Exécutez un exercice inoffensif dans un référentiel jetable et un environnement isolé. Ajoutez un hook qui écrit un fichier de marqueurs inoffensif. Vérifiez si la demande d’extraction atteint le propriétaire prévu, si une modification non approuvée peut fusionner et si l’outil installé autorise l’action du marqueur dans les conditions de lancement documentées.
Répétez l’exercice via l’itinéraire non interactif si l’organisation en utilise un. Modifiez ensuite uniquement le script d’assistance référencé. Ce deuxième changement teste si la limite de révision couvre le comportement ainsi que la configuration.
Le résultat doit identifier quels contrôles ont empêché l’exécution et lesquels l’ont simplement enregistrée. Une alerte du scanner, une révision requise et une restriction d’exécution effectuent différentes tâches. Enregistrez les lacunes sans en présenter une comme substitut à toutes les autres.
Trois questions constituent un premier examen réalisable. Qui peut fusionner une modification dans les fichiers qui pilotent nos assistants de codage ? Cette règle couvre-t-elle également tous les scripts appelés par ces fichiers ? Lesquelles de nos tâches automatisées exécutent l’assistant sur du code que nous n’avons pas écrit, et appliquent-elles les mêmes contrôles de confiance que le terminal d’un développeur ?
Pour les responsables de la sécurité, la mesure utile est de savoir si les modifications susceptibles de modifier l’exécution parviennent au bon réviseur avant leur distribution et si l’environnement de travail correspond à la portée approuvée. Commencez avec un outil de codage pris en charge et une équipe d’ingénierie. Demandez-leur de démontrer qui peut changer son comportement, comment ce changement est approuvé et ce qui se passe lorsque quelqu’un tente de contourner le processus.
