Тестовое задание создаёт понятное ожидание: кандидат должен показать, что умеет работать с проектом. Этим можно воспользоваться, подменив проверку навыков просьбой запустить неизвестный код в рабочем окружении.
Такие сценарии описаны исследователями Unit 42 на примере Contagious Interview: злоумышленники выдавали себя за участников процесса найма и предлагали разработчикам заражённое программное обеспечение. Это подтверждает существование вектора, но не позволяет автоматически отнести любой подозрительный репозиторий к той же кампании. [1]
Разумный порядок приёма задания защищает обе стороны. Кандидату не нужно оправдываться за осторожность, а компания получает воспроизводимый результат вместо случайного запуска на чьём-то ноутбуке.
Проверяем связь, а не впечатление
Название известной компании, логотип и убедительная переписка не подтверждают происхождение репозитория. Уместно проверить вакансию и контакт по независимому каналу: через официальный сайт или известного представителя, а не только по ссылкам из того же сообщения.
Это не техническая экспертиза кода. Подтверждённый сотрудник тоже может прислать ошибочный или скомпрометированный материал. Поэтому проверка личности отправителя и проверка артефакта решают разные задачи.
Небольшой или новый репозиторий сам по себе не является уликой. Для обычного тестового задания это может быть нормальным устройством. Более содержательный сигнал — настойчивое требование отключить защиту, разрешить непонятные автоматические действия или использовать личные ключи без объяснимой необходимости.
До запуска нужно определить условия
Для нормального задания достаточно заранее договориться о результате, используемых версиях инструментов, ожидаемых командах и допустимых внешних сервисах. Полезно получить фиксированный снимок проекта: иначе две стороны могут обсуждать разные состояния ветки.
Если проект требует доступа к API, компания предоставляет ограниченную тестовую учётную запись или замену сервиса. Для оценки навыков не должны понадобиться реальные seed-фразы, личные ключи от облака или доступ к рабочей инфраструктуре кандидата.
Со стороны компании стоит стремиться к минимальному явному сценарию запуска. Автоматические задачи при открытии, непрозрачные установочные действия и скачивание исполняемого кода без проверяемого происхождения создают ненужный риск и мешают воспроизводимости задания. Это предлагаемая политика приёма, а не утверждение, что любой установочный хук вредоносен.
Изоляция определяется доступами
Для заведомо подозрительного проекта разумнее отдельная одноразовая виртуальная машина с чистым состоянием. В ней не должно быть рабочих секретов, подключённого домашнего каталога, перенаправленного SSH-agent, профиля основного браузера или свободного доступа во внутреннюю сеть. Обмен папками и буфером обмена включают только при обоснованной необходимости. Для первоначального разбора сеть отключают. Если динамическое исследование требует сетевого обмена, отдельно готовят контролируемую лабораторную сеть с журналированием и подменой внешних сервисов; соединения с адресами из образца не разрешают автоматически.
Контейнер может быть частью такой среды, но слово Docker не даёт гарантии. Проброшенный каталог, доступ к Docker socket и избыточные полномочия способны разрушить ожидаемую изоляцию. В Linux контейнеры обычно используют ядро хоста, поэтому их граница отличается от границы отдельной виртуальной машины. Docker Desktop на macOS запускает контейнеры в виртуальной машине, но разрешённые общие каталоги и доступ к демону остаются существенны. [4] Документация Docker отдельно разбирает последствия этих доступов. [2]
Готовый контейнер, предоставленный отправителем задания, тоже содержит недоверенный код. Проверять нужно и способ его запуска: образ, параметры, тома, сеть, переменные среды. Он не становится доверенным только потому, что его удобно запускать одной командой.
Когда остановиться
Если найден путь от внешнего ответа к исполнению, замаскированный загрузчик или необъяснимый автозапуск, для оценки задания не нужно добиваться заражения. Можно зафиксировать находку, приостановить запуск и предложить безопасную альтернативу: статический разбор, очищенный вариант или заранее подготовленное демо.
Не следует превращать проверку в исследование чужой инфраструктуры без разрешения. Адрес, найденный в коде, — материал для анализа, а не приглашение отправлять запросы на действующий сервер.
Короткий ответ отправителю
Спасибо, проект получил. Сначала проверю его без запуска. Внешние проекты запускаю в отдельной среде без личных и рабочих доступов. Пришлите, пожалуйста, ожидаемый результат задания, версии инструментов и полный сценарий запуска. Если нужны внешние сервисы, потребуется тестовая учётная запись с ограниченными правами.
Формулировка не обвиняет собеседника и не перечисляет случайные «страшные слова». Она устанавливает понятный порядок работы.
Как сообщить о подозрительном репозитории
В сообщении площадке полезны точный адрес объекта, идентификатор исследованного состояния, путь к файлу, минимальный фрагмент, объясняющий поведение, и способ получения доказательств. Отдельно отмечают, был ли это статический анализ и известен ли фактический запуск.
Atlassian принимает сообщения о вредоносном содержимом Bitbucket через поддержку и адрес abuse@atlassian.com. В инструкции предлагается указать ссылку на материал и описание проблемы; отрицательный или неопределённый результат сканирования не препятствует сообщению. [3]
Не нужно публиковать секреты, персональные данные или весь архив только ради убедительности. Наличие eval без контекста — слабый отчёт. Небольшой фрагмент с доказанной цепочкой и аккуратным описанием значительно полезнее.
Задача: что спросить у «рекрутера»?
Вам пишут: «Сначала выполните все команды из README на своём основном компьютере. Виртуальную машину не используйте. Если редактор покажет предупреждение, разрешите всё — иначе тест не работает».
Составьте ответ отправителю. Задайте три вопроса о необходимых разрешениях, причине запрета виртуальной машины и критерии прохождения. Предложите один способ выполнить ту же задачу с меньшим доступом.
Показать разбор
Возможный ответ. «Какие конкретно разрешения нужны и каким шагам? Почему задание не работает в виртуальной машине? По какому результату вы будете оценивать выполнение? Я могу выполнить задание в одноразовой среде без личных данных и предоставить результат и журнал запуска».
По сообщению можно установить, что отправитель требует расширить доступ до объяснения технической необходимости. Для атрибуции или вывода о компрометации нужны отдельные свидетельства.
Что стоит запомнить
Доверие к собеседнику не должно незаметно превращаться в неограниченные полномочия для присланного кода. Хорошо организованное тестовое задание проверяет навыки и допускает понятные границы безопасности.
Источники
[1] Unit 42: Hacking Employers and Seeking Employment — исследование Contagious Interview.
[3] Atlassian: Report malware hosted on Bitbucket Cloud.
[4] Docker Desktop for Mac: разрешения и контейнеры внутри Linux VM.