Конфігураційні файли для ШІ-асистентів стали вектором атак на розробників

Зловмисники дедалі частіше використовують конфігураційні файли для ШІ-асистентів та редакторів коду для атак на робочі станції розробників. Додавання таких файлів у pull request зазвичай позиціонується як покращення досвіду розробки (developer experience), не зачіпає вихідний код додатку, однак може містити інструкції для автоматичного виконання сторонніх команд під час відкриття проєкту.

Загроза виконання коду під час відкриття папки

Аналіз кампанії Miasma, проведений компанією StepSecurity, продемонстрував випадок, коли конфігураційні файли для ШІ-інструментів та редакторів було розміщено у репозиторії Microsoft без модифікації коду програми. Метою атаки було збирання облікових даних інженерів через інструменти розробника. Комміт мав прапорець пропуску CI (skip-CI) та змінену дату, а сам вектор запуску коду змістився зі стадії встановлення пакета на момент простого відкриття каталогу в середовищі розробки. Звичайні перевірки у пайплайнах збірки подібні шляхи виконання ігнорують.

Конфігураційні файли та інструкції несуть різні ризики залежно від їхнього призначення:

• Файли у форматі Markdown (наприклад, SKILL.md) часто сприймаються під час ревʼю як документація, проте можуть надавати ШІ-агенту доступ до списку інструментів через поле allowed-tools без запиту підтвердження користувача під час виклику навички (skill).
• Документація Claude Code зазначає, що механізм workspace trust не обмежує це поле.
• Хуки команд, згідно з документацією Anthropic, виконуються з правами користувача. Ба більше, у неінтерактивних сесіях хуки з файлів налаштувань репозиторію можуть спрацьовувати без показу діалогового вікна довіри (workspace trust dialog), яке виводиться інтерактивному користувачеві.

Захисні заходи та перевірка хуків

Для мінімізації ризиків неінтерактивного виконання над неперевіреним кодом документація Anthropic рекомендує попередньо переглядати файли налаштувань .claude, запускати сесії у голому режимі (bare mode) або вимикати хуки. Адміністратори також можуть застосовувати параметр managed-hooks-only, який блокує користувацькі, проєктні, локальні хуки та хуки плагінів.

Також зазначається, що режим Restricted Mode у Visual Studio Code обмежує функції, здатні виконувати вміст робочого простору, але шкідливі розширення можуть ігнорувати ці межі.

Організація ревʼю та контроль власників коду

Експерти радять запровадити обов'язкові маршрути перевірки для файлів конфігурації ШІ-інструментів:

• Призначити відповідальних власників (наприклад, команди engineering productivity), тоді як команди безпеки мають визначати критерії для залучення додаткових ревʼюверів (додавання хуків, розширення доступу до мережі чи нові зовнішні інструменти).
• Використовувати CODEOWNERS у зв'язці із захистом гілок на GitHub. Сам по собі файл CODEOWNERS не робить апрув обов'язковим без увімкненого правила branch protection. Захист повинен поширюватися як на сам файл конфігурації, так і на допоміжні скрипти, які він викликає.
• Запускати підозрілі репозиторії в ізольованому середовищі без автоматично підмонтованих продакшн-секретів.