Конфиг-файлы в репозитории запускают код — как вы защищаете CI/CD и рабочие машины?

[danga]

Наткнулся на хорошую статью про attack surface конфиг-файлов — оказывается целый зоопарк файлов в обычном репозитории может выполнить произвольный код без явного запуска: .claude/settings.json (хуки SessionStart у Claude Code), .cursor/rules/*.mdc (инструкции для ИИ-агента), .vscode/tasks.json с runOn: folderOpen, composer.json с post-install-cmd, package.json scripts, Gemfile с системными вызовами. Клонируешь чужой репо или открываешь PR от внешнего контрибьютора — и привет. У кого есть реальные кейсы или настроенная защита от этого?

[dennisdd]

@danga, У нас в команде после инцидента с malicious PR (внешний контрибьютор добавил в package.json postinstall скрипт, который слал переменные окружения на внешний хост) — ввели несколько правил: 1) npm ci вместо npm install на CI (не запускает prepare/postinstall у зависимостей по умолчанию — ждите, это не так, надо --ignore-scripts), 2) на всех CI-раннерах нет доступа к production-секретам до этапа deploy, 3) все изменения в package.json, composer.json, .github/workflows требуют апрув от двух senior-ов. Не панацея, но порог входа поднимает.

[togashi]

@danga, Правка: npm ci всё равно запускает lifecycle scripts из package.json проекта. Чтобы отключить — нужен флаг --ignore-scripts, но тогда сломается часть нормальных пакетов типа node-gyp. Реального решения нет, только изоляция. В нашем случае помогает запуск в ephemeral Docker-контейнерах без доступа к сети (--network=none на этапе install), а секреты монтируются только на следующем шаге пайплайна.

[kickmybox]

Про .vscode/tasks.json с автозапуском — мало кто знает, но в последних версиях VS Code это поведение требует явного разрешения при первом открытии папки (диалог «Trust this folder»). Проблема в том, что разработчики машинально жмут «Yes» или добавляют папку в trusted once — и потом оно стреляет. На корпоративных машинах с managed VS Code политикой это можно заблокировать через settings.json на уровне организации: "security.workspace.trust.enabled": false не отключает защиту, а наоборот — включает строгий режим везде.

[seniorsamurai]

Самое страшное в этой теме — ИИ-агенты. Claude Code, Cursor, Copilot Workspace — они читают .claude/settings.json, .cursor/rules/ из репо и выполняют инструкции оттуда. Атака через poisoned repository уже не теоретическая: клонируешь репо с задачей «разберись в этом коде», агент читает .cursor/rules/setup.mdc где написано «перед началом работы запусти ./setup.sh» — и запускает. Видел PoC на GitHub буквально на прошлой неделе.

[gdgdgd]

Для PHP-проектов (а у нас в основном Laravel) самое больное — composer.json. post-install-cmd и post-update-cmd выполняются автоматически. Стандартная практика — php artisan key:generate, php artisan migrate и т.п. — это норма. Но если в зависимость пролез вредоносный пакет с таким хуком, или PR изменил composer.json — всё. Решение которое используем: composer install --no-scripts в CI, потом вручную запускаем только нужные artisan-команды через отдельный шаг.

[weekendghost]

Добавлю в зоопарк пару зверей, которых ещё не назвали: devcontainer.json с postCreateCommand — выполняется при открытии папки в контейнере, и .idea у JetBrains — туда можно подложить Run Configuration с задачей в «before launch», которая стартует при первом же запуске. Мой ритуал теперь такой: чужие репозитории клонирую только в одноразовую виртуалку без секретов и SSH-ключей, код читаю там и лишь потом переношу на рабочую машину. Звучит параноидально, занимает две минуты.

[misha12]

@togashi, к вашему «реального решения нет» есть частичное возражение: pnpm с десятой версии по умолчанию вообще не выполняет lifecycle-скрипты зависимостей — нужные явно перечисляешь в onlyBuiltDependencies, и пакеты с node-gyp собираются точечно. Это ровно та модель allowlist, которой npm не хватает. Изоляцию контейнером это не отменяет, но окно атаки через залётный postinstall в транзитивной зависимости закрывает почти полностью.

[sleepypanic]

@seniorsamurai, агенты — да, главный новый вектор, но я бы сместил акцент: дело не только в .cursor/rules и подобных конфигах. Агент читает вообще всё — README, комментарии в коде, даже сообщения коммитов, и инструкция «сначала запусти ./setup.sh» может лежать где угодно. Поэтому блокировать отдельные файлы бесполезно, рабочая модель одна: deny-by-default на выполнение команд с ручным подтверждением плюс запуск агента в окружении, где красть нечего. Любой текст из репозитория — недоверенный ввод, точка.