Безопасность вайбкодинга: чек-лист перед деплоем кода от ИИ

Представьте: вы попросили агента подключить базу к боту, он дописал сервис в docker-compose, бот ответил на первую команду – и проект уехал на VPS. Раз всё работает, кажется, что всё в порядке. Но безопасность вайбкодинга чаще всего подводит не в хитрой логике, а в одной строке конфигурации и одной команде установки.

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

Одна строка в docker-compose: как бот от ИИ привёл к взлому сервера

Вот показательный случай из 2026 года. Пет-проект – личный проект для себя, весь код которого написал ИИ-агент, – работал на VPS. В docker-compose порт PostgreSQL оказался открыт наружу – к базе можно было подключиться из любой точки интернета. А вместе с базой получить доступ к данным на сервере и потенциально к управлению им.

Владелец проверил то, что казалось главным: бот стартует и отвечает на команды. Проверка честно показала, что приложение работает. Что база при этом открыта для внешних подключений, она показать не могла. Это просто не её вопрос.

Дальше всё сложилось из штатных возможностей. В официальном образе PostgreSQL учётная запись, которую создают через переменную POSTGRES_USER, получает права суперпользователя. С такими правами встроенные средства самой СУБД позволяют выполнять команды внутри контейнера – никакая уязвимость для этого не нужна. Атакующий так и поступил: загрузил в контейнер майнер, и сервер ушёл в постоянную перегрузку.

Схема простая: опубликованный порт → вход в базу → права суперпользователя → команды в контейнере → майнер. Разорвать цепочку можно на любом звене, но дешевле всего – на первом. Порт, которого не видно снаружи, эту цепочку скорее всего даже не запустит.

Почему агент открывает лишнее: задание без границ

Агент не вредит нарочно: он решает ту задачу, которую получил. Запрос в духе «добавь PostgreSQL, чтобы бот запускался» описывает желаемый результат, но молчит о сетевых границах, правах приложения и обращении с данными. Эти пробелы агент заполняет сам, и заполняет так, чтобы всё заработало. Опубликованный порт для этой цели подходит идеально: база гарантированно доступна, бот отвечает, задача выполнена.

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

Вторая привычка – не давать агенту сразу править файлы. Сначала пусть изучит текущую конфигурацию и предложит план изменений. План читается быстрее готового diff – списка правок в файлах, – и спорные решения вроде лишнего порта всплывают до того, как попадут на сервер.

Если агент работает прямо на сервере, его доступ стоит ограничить ещё на этапе установки – как поставить Claude Code на VPS и войти в аккаунт, разбирается отдельно.

Выдуманные пакеты: как часто ИИ советует несуществующее

Вторая ошибка выглядит ещё безобиднее: строка установки зависимости в начале ответа. Код аккуратный, имя пакета звучит солидно. Только пакета может не быть.

Исследование, представленное на конференции USENIX Security в 2025 году, проверило 576 000 примеров кода от 16 моделей и показало: 19,7% пакетов, которые рекомендовали модели, на самом деле не существовали. Это почти каждый пятый. Новые модели ошибаются заметно реже – повторная проверка в 2026 году дала долю около 4,6–6,1%. Ошибок меньше, но не ноль. В проекте с десятками зависимостей это всё ещё заметный риск.

Само по себе несуществующее имя – просто упавшая установка. Опасным его делает предсказуемость. В том же исследовании 2025 года 43% выдуманных имён появлялись снова при каждом повторе того же запроса. А в 2026 году нашли 127 несуществующих пакетов, которые одинаково придумывали пять разных моделей.

Для атакующего это готовый список целей. Гадать не нужно: достаточно собрать устойчивые выдумки популярных моделей, заранее зарегистрировать эти имена в реестре и положить туда вредоносный код. Такую атаку называют слопсквоттингом – от английского slop, «мусорный контент», и squatting, «захват чужого имени».

Почему привычная защита не ловит выдуманные пакеты

Защита от тайпсквоттинга – регистрации имён-опечаток – ищет имена, которые отличаются от популярных пакетов на одну-две буквы. Против выдуманных имён она почти бесполезна: только около 13% из них похожи на опечатки реальных пакетов. Остальные звучат правдоподобно, но ни на что существующее не похожи, и сравнение по сходству их пропускает.

Угроза не теоретическая. На февраль 2026 года один вредоносный пакет, зарегистрированный под выдуманным именем, всё ещё скачивали примерно 233 раза в неделю. Кто-то продолжал ставить его – вручную или руками агента.

Самое уязвимое место – агент, который сам выполняет команды установки. Человек хотя бы может задержаться взглядом на незнакомом имени. Агент без ограничений подтянет вредоносный пакет сам, без участия человека, и продолжит работу. Поэтому его установки нужно пропускать через проверку или ручное подтверждение.

Порты в docker-compose: что можно открыть наружу и как это проверить

Вернемся к первой ошибке. По общему правилу внутренние службы из интернета видно быть не должно. Боту база нужна внутри сервера, а не снаружи.

Второе правило касается проверки. Доступность портов смотрят снаружи, из другой сети – например, с домашнего компьютера, если сервер в облаке. Проверка с самого сервера покажет, что слушает машина, но не то, что видит интернет. Для базы правильный результат один: подключение к её порту снаружи не проходит.

Файрвол разумно настроить один раз при подготовке сервера, а не после инцидента. Как закрыть VPS ключами, отдельным пользователем и файрволом, показано в курсе по установке Claude Code на свой компьютер и VPS.

Чек-лист безопасности перед деплоем проекта от ИИ

Обе ошибки объединяет одно: они не мешают проекту работать. Поэтому искать их нужно отдельно, по списку, а не ждать, что они проявятся сами. Прогоняйте этот список перед каждым деплоем, особенно если агент трогал docker-compose или зависимости.

Сеть и права:

• Изменения инфраструктуры агент сначала описал планом, и вы прочитали его до правок.
• В docker-compose порты базы, кэша и очереди не опубликованы на хосте.
• Приложение работает с базой не под учётной записью из POSTGRES_USER, у которой права суперпользователя.
• Файрвол не пропускает к внутренним службам; если доступ нужен, он открыт только для конкретного IP.
• SSH и админ-панели доступны только с вашего IP.
• Порты проверены снаружи, из другой сети, а не с самого сервера.

Зависимости:

• Каждый новый пакет найден в реестре: он существует, у него понятный возраст и число загрузок.
• Зависимости зафиксированы lock-файлом (файлом с точными версиями всех пакетов) и версиями, а где возможно – проверкой хешей.
• Агент не может устанавливать пакеты без проверки или вашего подтверждения.

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

Если сервер уже взломали

Первое желание – убить подозрительные процессы или сразу переустановить систему. Переустановка действительно возвращает контроль, но вместе со старым диском исчезают и следы атаки. Поэтому порядок другой.

Сначала изолируйте затронутое окружение и, если получится, сохраните журналы и снимок диска – по ним потом можно понять, как именно вошли. Затем отзовите секреты, к которым мог дотянуться атакующий: пароли, ключи, токены. Только после этого поднимайте сервер заново и прогоняйте чек-лист выше, чтобы та же дыра не появилась во второй раз.

Ключевые термины

• Вайбкодинг – Разработка, при которой код целиком пишет ИИ-агент, а человек задаёт направление и проверяет результат.
• Slopsquatting – Атака, при которой злоумышленник регистрирует в публичном реестре вредоносный пакет под именем, которое языковые модели выдумывают и советуют установить.
• Тайпсквоттинг – Регистрация вредоносного пакета с именем, похожим на популярный пакет, в расчёте на опечатку человека.
• Публикация порта – Настройка Docker, которая делает порт контейнера доступным на хосте и, без файрвола, из интернета.
• Lock-файл – Файл, фиксирующий точные версии всех зависимостей проекта, чтобы в сборку не попало ничего непроверенного.
• Суперпользователь базы данных – Учётная запись с полными правами в базе, которая в PostgreSQL может в том числе запускать команды на сервере.

Итог

Проверьте себя

1. Агент добавил в docker-compose строку ports: "5432:5432" для базы, которой пользуется только бот в той же сети Compose. Что правильно?

• А. Убрать публикацию порта: бот подключается к базе по имени сервиса во внутренней сети
• Б. Оставить как есть: раз бот работает, конфигурация верна
• В. Оставить порт, но поставить сложный пароль

2. ИИ предложил выполнить pip install aws-helper-sdk. Что нужно сделать до установки?

• А. Ничего: если пакета нет, установка просто не пройдёт
• Б. Достаточно убедиться, что имя не похоже на опечатку популярного пакета
• В. Проверить, что пакет существует, когда он появился, сколько у него загрузок и есть ли реальный репозиторий

3. Почему атаки на выдуманные имена пакетов работают, хотя моделей много и имён сотни тысяч?

• А. Модели повторяют одни и те же выдуманные имена, и их можно заранее зарегистрировать
• Б. Модели специально обучены рекомендовать вредоносные пакеты
• В. Атакующие регистрируют все возможные имена подряд

4. Вы записали в правила проекта «не устанавливай пакеты без объяснения». Агент может сам запускать команды на сервере. Защищён ли проект?

• А. Нет: правила задают поведение, но не ограничивают технические права – установки нужно пропускать через подтверждение
• Б. Да, агент всегда соблюдает правила проекта
• В. Да, если правила лежат в корне репозитория

5. Как убедиться, что порт базы закрыт для интернета?

• А. Спросить агента, закрыт ли порт
• Б. Подключиться к базе с самого сервера и убедиться, что всё работает
• В. Проверить подключение к порту с компьютера в другой сети