Pull request добавляет полезный шаг настройки для ИИ-ассистента программирования. Изменения в исходном коде приложения отсутствуют. В описании это названо улучшением пользовательского опыта разработчика, а рецензент видит короткий конфигурационный файл рядом с инструкциями в формате Markdown.
Прежде чем одобрить его, рецензенту необходимо ответить на другой вопрос: что это изменение позволит запустить на машине коллеги?
Проблема вышла за рамки гипотетического отравления репозитория. В анализе от 8 октября о распространении навыков ИИ-агентов StepSecurity вернулся к кампании Miasma в июне, которая внесла конфигурацию ИИ-инструментов и редактора в репозиторий Microsoft без изменения исходного кода приложения. Конфигурация предназначалась для сбора учетных данных через инструменты разработчика. В октябрьской публикации описывается продукт инвентаризации, но лежащая в основе кампания иллюстрирует более широкую операционную проблему: слияние изменения конфигурации может распространить инструкции по выполнению среди людей, работающих в этом репозитории.
StepSecurity также сообщает, что коммит содержал флаг skip-CI и отметку времени с обратной датой, а также что он переместил выполнение кода с этапа установки пакета на этап открытия папки. Контроль, который выполняется только в конвейере сборки, никогда не видит этот путь. Первой надежной контрольной точкой является pull request, и он требует человека, который знает, что может вызвать этот файл.
Я рекомендую назначить этим изменениям ответственного владельца и обязательный путь проверки. Организация должна иметь возможность определить, кто одобрил хук, что покрывало одобрение и где разрешено запускать одобренную версию.
Проанализируйте поведение, стоящее за именем файла
Файл репозитория может служить нескольким целям. Он может описывать соглашение о кодировании, направлять агента к скрипту, регистрировать инструмент или организовывать выполнение команды при событии жизненного цикла. Эти различия важнее расширения файла.
Инструкция в формате Markdown не является автоматически исполняемым кодом. Тем не менее, она может влиять на агента, имеющего разрешение на выполнение команд. Настройка JSON может напрямую регистрировать команду оболочки. Проверка должна установить механизм, триггер и полномочия, доступные при ее срабатывании.
Навыки показывают, почему имя файла является плохим ориентиром. StepSecurity отмечает, что поле allowed-tools (разрешенные инструменты) навыка может позволить агенту использовать перечисленные инструменты без запроса разрешения во время хода, вызывающего навык, и что документация Claude Code гласит, что доверие к рабочей области не ограничивает это поле. Файл SKILL.md является Markdown, поэтому в pull request он обычно рассматривается как README.
В текущей справочной документации по хукам Anthropic указано, что хуки команд выполняются с разрешениями пользователя. Она также различает интерактивное доверие к рабочей области и неинтерактивную работу: хуки файла настроек в репозитории могут выполняться в неинтерактивной сессии без диалогового окна доверия, отображаемого интерактивному пользователю. Точное поведение зависит от поверхности конфигурации и типа сессии. Поэтому контроль, протестированный на терминале разработчика, следует повторно протестировать в автоматизированном рабочем процессе, использующем тот же репозиторий.
На той же странице перечислены практические меры смягчения последствий. Перед написанием скрипта для неинтерактивного запуска в репозитории, который никто из команды не писал, проверьте его файлы настроек .claude, запустите выполнение в минимальном режиме или отключите хуки для этого запуска. Администраторы также могут использовать настройку managed-hooks-only (только управляемые хуки), чтобы блокировать хуки пользователя, проекта, локальные и плагинные хуки. Какой из них подходит, зависит от инструментов организации, и каждый должен быть протестирован, а не предполагаться.
Для предлагаемого установочного хука рецензент должен иметь возможность отследить команду до ее скрипта и зависимостей. Если скрипт загружает другую программу, определите, как эта программа выбирается и проверяется. Если он считывает учетные данные или получает доступ к сети, спросите, почему установочному шагу требуются такие возможности.
Эти вопросы должны сопровождать изменение, пока его автор может объяснить намерение. Обнаружение их после распространения оставляет каждому затронутому разработчику принимать индивидуальное решение о доверии.
Сделайте владение принудительным
Команды по продуктивности инженерии часто лучше всего подходят для поддержания общей конфигурации ИИ-ассистентов. Отдел безопасности должен определять условия, требующие второго рецензента, такие как добавление исполняемых хуков, расширение сетевого доступа или вызов нового внешнего инструмента. Команда приложения остается ответственной за то, принадлежит ли интеграция к ее рабочему процессу.
Это не обязательно должно создавать очередь одобрений для каждого предпочтения форматирования. Определите поведенческие изменения, которые требуют проверки, и направьте эти изменения к людям, которые понимают инструменты.
Документация GitHub по владельцам кода (code-owners) объясняет, как правила владения работают с обязательными проверками. Один только файл CODEOWNERS не делает его одобрение обязательным; соответствующая защита ветки должна требовать его. GitHub также рекомендует защищать сам файл владельцев.
Примените выбранный механизм к конфигурации агента и скриптам, которые он вызывает. Защита файла настроек при оставлении вызываемого им вспомогательного скрипта вне правила проверки создает очевидный пробел. Проверьте действующее правило на примере pull request, а не полагайтесь на наличие файла политики.
Позвольте легитимным изменениям быстро проходить по известному пути. Рецензент должен получить краткое объяснение триггера, необходимого доступа и ожидаемых побочных эффектов. Хук, который форматирует измененные файлы, не должен требовать такого же обоснования, как тот, который связывается с внешним сервисом или изменяет глобальную конфигурацию пользователя.
Проверьте, что на самом деле загружает среда разработчика
Проверка репозитория охватывает только часть среды. Разработчики также могут устанавливать общие навыки, плагины и пользовательскую конфигурацию вне проекта. Таким образом, одобренный репозиторий может работать вместе с дополнительными инструкциями, которые его сопровождающие никогда не проверяли.
Установите базовый уровень для поддерживаемых инструментов и методов запуска. Записывайте источники и версии одобренных дополнений и предоставьте способ проверки фактической конфигурации. Когда локальные копии отличаются, сравните содержимое, прежде чем решить, является ли различие вредоносным или безвредным.
Руководство Microsoft по Workspace Trust для Visual Studio Code описывает Restricted Mode (ограниченный режим), который ограничивает функции, способные выполнять содержимое рабочей области. Оно также предупреждает, что вредоносное расширение может игнорировать эту границу. Workspace trust является полезным контролем в пределах своей документально подтвержденной области; его следует сочетать с продуманной политикой расширений и средой, соответствующей проверяемому репозиторию.
Используйте незнакомые репозитории в изолированной среде без регулярно монтируемых производственных учетных данных. Избегайте рассмотрения контейнера как достаточной изоляции, если он наследует секреты разработчика или доступ к хосту. Явно проверяйте эти соединения.
Для одобренной ежедневной работы сделайте безопасную настройку практичной. Публикуйте поддерживаемые конфигурации, объясняйте, как запросить добавление, и предоставьте чистый рабочий процесс проверки. Если соответствие требованиям требует, чтобы разработчики вручную восстанавливали свою среду каждое утро, это будет трудно поддерживать.
Проверьте путь одобрения, прежде чем доверять ему
Выполните безобидное упражнение в одноразовом репозитории и изолированной среде. Добавьте хук, который записывает безвредный маркерный файл. Проверьте, достигает ли pull request предполагаемого владельца, может ли быть объединен неодобренный изменения, и разрешает ли установленный инструмент действие маркера в соответствии с задокументированными условиями запуска.
Повторите упражнение по неинтерактивному пути, если организация его использует. Затем измените только вызываемый вспомогательный скрипт. Это второе изменение проверяет, охватывает ли граница проверки поведение так же, как и конфигурацию.
Результат должен выявить, какие элементы управления предотвратили выполнение, а какие только зарегистрировали его. Предупреждение сканера, обязательная проверка и ограничение времени выполнения выполняют разные задачи. Записывайте пробелы, не представляя один как замену всем остальным.
Три вопроса составляют рабочий первый обзор. Кто может объединить изменения в файлы, которые управляют нашими ИИ-ассистентами? Распространяется ли это правило также на каждый скрипт, который вызывают эти файлы? Какие из наших автоматизированных заданий запускают ассистента для кода, который мы не писали, и применяют ли они те же проверки доверия, что и терминал разработчика?
Для руководства по безопасности полезной мерой является то, достигают ли изменения, способные повлиять на выполнение, нужного рецензента перед распространением, и соответствует ли рабочая среда одобренной области. Начните с одного поддерживаемого инструмента кодирования и одной инженерной команды. Попросите их продемонстрировать, кто может изменить его поведение, как это изменение утверждается и что происходит, когда кто-то пытается обойти процесс.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Sunil Gentyala
