ИИ пишет код и ставит пакеты: 5 проверок перед выпуском приложения в прод

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

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

Для разработчика это повод пересмотреть ревью. Для продакта и основателя — добавить к критерию «демо работает» несколько проверок, без которых выпуск остаётся лотереей.

Начните с чужого профиля

Самые полезные проверки часто выглядят скучно. Может ли пользователь прочитать чужой заказ, заменив идентификатор в запросе? Доступна ли таблица без авторизации? Попадает ли введённое имя прямо в HTML?

В статье приведён пример приложения на Supabase. Публичный ключ во фронтенде сам по себе не означает утечку: доступ к строкам должны ограничивать политики Row Level Security. Ошибка возникает, когда приложение уже подключено к базе, а правила доступа ещё не настроены или допускают лишнее.

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

Статический анализ помогает искать опасные операции и утечки секретов. Но понять, кто вправе читать конкретный заказ, без правил вашего продукта он обычно не сможет. Здесь нужны ревью и проверки авторизации.

Зависимость начинается с проверки имени

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

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

Поэтому каждую новую зависимость стоит сверять с официальной документацией проекта. Затем — фиксировать версию и использовать lock-файл при сборке. Это делает установку воспроизводимой, хотя само по себе не доказывает безопасность выбранного пакета.

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

Агенту нужны границы полномочий

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

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

Перед ближайшим релизом можно выбрать пять проверок: доступ к чужим объектам, происхождение новых пакетов, воспроизводимость установки, секреты в коде и логах, полномочия агента. Это конкретные места, где небольшая ошибка превращается в утечку или выполнение чужого кода.

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