безопасность

ИИ-агенты атакуют разработчиков через тестовые задания

Новый риск для разработчиков: фейковая вакансия, приватный репозиторий и автозапуск кода через IDE. Разбираем схему и защиту.

По состоянию на 20 апреля 2026 года ИИ-агенты атаки на разработчиков уже не выглядят как абстрактный риск из будущего. На Habr вышел свежий кейс: разработчику написали от имени рекрутера, предложили тестовое задание, добавили в приватный GitHub-репозиторий, а вредоносная логика была спрятана в настройках VS Code.

Важная оговорка: мы не можем независимо проверить все детали конкретного репозитория из Habr, поэтому читаем его как публичный технический разбор очевидца. Но сама схема сходится с тем, что уже видно в безопасности AI-разработки: агент масштабирует доверительный контакт, а IDE, package scripts, workflow-файлы и agent skills становятся частью цепочки поставки.

Что случилось

Автор Habr описывает классический рекрутинговый заход, усиленный ИИ. Сообщение пришло от пользователя Хабр Карьеры, аккаунт после репорта был заблокирован. Диалог выглядел достаточно живым: не мгновенные ответы, рабочие часы, небольшие ошибки в стиле человека. Когда автор попросил подробнее рассказать о проекте, описание стало слишком гладким и общим.

После согласия посмотреть тестовое задание разработчика добавили в приватный репозиторий. Внутри, по описанию автора, был обычный на вид fullstack-проект: React, Node.js/Express, PostgreSQL, Firebase Auth, Stripe. Ловушка лежала не в бизнес-логике приложения, а в папке .vscode.

В файле .vscode/tasks.json была задача с runOn: "folderOpen". В исходном кейсе она запускала разные команды для Linux/macOS и Windows: для Unix-подобных систем скачивание скрипта с удалённого сервера и запуск через shell, для Windows загрузку архива, распаковку локальным бинарником и запуск VBScript. Точный payload автор не установил, потому что вредоносный скрипт отдавался с удалённого сервера и мог меняться.

Почему это не просто новый фишинг

Фейковые вакансии были и до ИИ. Новая часть схемы не в самом обмане, а в цене персонализации. Если агент может быстро прочитать профиль разработчика, подобрать стек, вести переписку и выдавать правдоподобное описание проекта, атакующий получает конвейер доверительных контактов. Это уже ближе к supply-chain атаке на рабочую машину разработчика, чем к обычному спаму.

Приватный репозиторий тоже работает на доверие. Публичный код быстрее попадает в индексы, сканеры и обсуждения. Приватный репозиторий выглядит как «тестовое специально для вас» и снижает вероятность, что кто-то посторонний заметит вредоносные файлы.

Похожий сдвиг мы уже видели в других историях. Во взломе Vercel через AI-инструмент точкой входа стал сторонний инструмент и рабочие доступы. В MuleRun AI swarm агентная автоматизация масштабировала злоупотребление аккаунтами и бесплатными ресурсами. В этой истории фокус уже на разработчике как цели: его IDE, ключах, токенах, кошельках и локальных проектах.

Где была техническая ловушка

У VS Code действительно есть режим запуска задач при открытии папки. В официальной документации runOptions.runOn поддерживает значение folderOpen: задача запускается, когда открывается папка с такой задачей. Документация также уточняет, что при первом открытии папки с такой задачей VS Code спрашивает, разрешать ли автоматические задачи, и это решение можно поменять через Manage Automatic Tasks.

То есть корректнее говорить не «VS Code всегда молча запускает всё», а иначе: репозиторий может принести с собой задачу, которая рассчитана на автозапуск при открытии папки. Если пользователь уже доверяет проекту, ранее разрешал автоматические задачи или не читает предупреждения IDE, это превращается в рабочий канал выполнения кода.

VS Code предупреждает, что listing and running tasks требует выполнения части файлов workspace как кода. Источник: Microsoft VS Code Docs.

Workspace Trust как раз закрывает часть этой проблемы. В документации Microsoft сказано, что Restricted Mode пытается предотвратить автоматическое выполнение кода и ограничивает AI agents, tasks, debugging, workspace settings и extensions. Там же прямо написано: task definitions лежат в папке .vscode, попадают в исходный код репозитория и могут быть запущены любым, кто этот репозиторий клонировал.

Почему агентные инструменты расширяют риск

Схема с tasks.json не требует ИИ, но ИИ делает её дешевле и убедительнее. Агент может подготовить много персонализированных сообщений, поддерживать переписку, менять легенду под стек кандидата и быстро генерировать «обычный» проект вокруг вредоносного ядра.

На уровне инструментов разработки проблема шире. Snyk в феврале 2026 года опубликовал исследование ToxicSkills: компания просканировала 3 984 agent skills из ClawHub и skills.sh и нашла критические проблемы в 534 skills, то есть 13,4%. При расширении до любых security issues доля выросла до 36,82%, или 1 467 skills. Snyk также подтвердил 76 malicious payloads через human-in-the-loop проверку.

Рост числа Agent Skills в исследовании Snyk ToxicSkills. Быстрый рост каталога делает ручную проверку слабым барьером. Источник: Snyk.

В марте 2026 года на arXiv вышла работа «Are AI-assisted Development Tools Immune to Prompt Injection?». Авторы проверяли MCP-клиенты для разработки, включая Claude Desktop, Claude Code, Cursor, Cline, Continue, Gemini CLI и Langflow, и пришли к выводу, что между инструментами есть большой разброс по защите: где-то есть guardrails, где-то остаётся высокая восприимчивость к cross-tool poisoning, hidden parameters и несанкционированным вызовам инструментов.

Иными словами, вредоносный репозиторий теперь может атаковать не только shell или package manager. Он может влиять на агента через инструкции, rules, skills, MCP-описания, README, тесты, комментарии и конфигурацию. Для модели всё это контекст. Для атакующего — поверхность управления.

Что проверять до открытия чужого репозитория

Если вам прислали тестовое задание из неизвестного источника, не начинайте с git clone и открытия папки в IDE. Сначала смотрите репозиторий в веб-интерфейсе. Да, это медленнее. Зато вы не запускаете чужие hooks, tasks и расширения на своей машине.

Проверьте .vscode/tasks.json, .vscode/settings.json, launch.json и рекомендации расширений. Любой runOn: "folderOpen" в тестовом задании требует жёсткого объяснения.
Откройте package.json. В npm lifecycle scripts есть preinstall, install, postinstall, prepare и другие события, которые выполняются при npm install или npm ci.
Посмотрите .github/workflows. GitHub Actions workflows определяются YAML-файлами в репозитории и запускают jobs на событиях, вручную или по расписанию.
Проверьте Dockerfile, docker-compose.yml, devcontainer.json и скрипты в scripts/. Вредоносная логика часто выглядит как «подготовка окружения».
Ищите бинарники в неожиданных местах: .vscode/, snippets/, assets/, public/. Для тестового задания это почти всегда лишнее.
Проверьте agent-файлы: CLAUDE.md, .cursor/rules, skills, MCP-конфиги и похожие инструкции. Мы отдельно разбирали как настраивать проект для AI-агентов; теперь эти файлы надо считать частью trust boundary.

Как безопаснее разбирать тестовые задания

Минимальная защита: открыть неизвестный проект в Restricted Mode и не разрешать automatic tasks до ручной проверки. В настройках VS Code отдельно проверьте task.allowAutomaticTasks. Если вы не используете автозадачи осознанно, безопаснее держать их выключенными и разрешать только точечно.

Второй слой — изоляция. Для сомнительных тестовых заданий лучше иметь отдельную виртуальную машину или контейнер без доступов к вашим SSH-ключам, облачным токенам, браузерным cookies и рабочим .env. Нельзя проверять чужой репозиторий в той же среде, где лежат ключи от продакшена, кошельки и клиентские проекты.

Третий слой — отдельная учётная запись. Если приватный репозиторий требует GitHub-доступ, не отдавайте основной аккаунт с рабочими организациями и токенами. Для первичного просмотра достаточно отдельного аккаунта без доступов к вашим проектам.

Четвёртый слой — правило «нет конкретики, нет запуска». Если рекрутер или «агент» не может назвать компанию, юридическое лицо, продукт, команду, стек, процесс оплаты и контакт в нормальном домене, техническое тестовое не должно попадать в вашу IDE.

Что не стоит преувеличивать

ИИ-агент сам по себе никого не взламывает. За схемой стоит оператор, инфраструктура, вредоносный репозиторий и расчёт на доверие разработчика. Агент здесь важен как усилитель: он удешевляет персонализацию, поддерживает диалог и помогает масштабировать контакт.

Не каждое тестовое в приватном репозитории вредоносно. Иногда приватность нужна из-за коммерческой логики или данных. Но в нормальном процессе компания объяснит, кто она, зачем нужен приватный доступ и почему в тестовом есть автозадачи или нестандартные бинарники. Молчание и уклончивые ответы — это уже сигнал.

И ещё одно: не превращайте проверку в охоту только за .vscode/tasks.json. Сегодня сработал этот механизм, завтра это будет postinstall, poisoned MCP server, Cursor rules, devcontainer feature или GitHub workflow. Проверять нужно не один файл, а все места, где данные превращаются в инструкции.

Главный вывод

ИИ-агенты атаки на разработчиков делают дешевле не потому, что модели стали «хакерами», а потому что они хорошо обслуживают социальную часть атаки. Они пишут, ждут, уточняют, подстраивают легенду, а потом ведут человека к старой технической ловушке: запусти чужой код у себя.

Новая привычка для 2026 года проста: чужой репозиторий — это исполняемая среда, даже если вы ещё не нажали Run. Пока вы не проверили IDE tasks, package scripts, workflows, devcontainer и agent-инструкции, открывайте его как недоверенный. Для разработчика это такая же базовая гигиена, как не вставлять неизвестный токен в терминал.