Действительно ли код, созданный ИИ, безопасен? Вопросы и ответы для разработчиков

Тот или иной вариант этого вопроса я слышу почти на каждом онбординг-звонке, обычно сформулированный осторожно, как будто человек наполовину ждёт, что его отговорят волноваться. Отговаривать не стоит. Безопасность — одна из немногих областей, где здоровая доля паранойи вполне оправдана, независимо от того, кто писал код — человек или модель. Ниже — вопросы, которые мне реально задают, с максимально прямыми ответами.

Менее ли безопасен код, написанный ИИ, чем код, написанный человеком?

В среднем и без контроля — да, слегка. Исследование Стэнфорда несколькими годами ранее (Perry и др., часто цитируется как первый серьёзный взгляд на этот вопрос) показало, что разработчики, использующие ИИ-ассистента для написания кода, создавали менее безопасный код, чем контрольная группа, и — это должно вас беспокоить сильнее — оценивали свой код как более безопасный, чем он был на самом деле. Уверенность росла, качество падало. Более свежие сканирования безопасности GenAI-кода от Veracode дают примерную цифру: около 4 из 10 протестированных образцов кода, сгенерированного ИИ, содержали хотя бы одну эксплуатируемую уязвимость — обычно что-то обыденное вроде отсутствующей проверки входных данных или слабых значений по умолчанию. Это не значит, что код, написанный ИИ, обречён по своей природе. Это значит, что непроверенный код, написанный ИИ, несёт тот же риск, что и непроверенный код человека, а опасность кроется именно в слове «непроверенный». Модель, которая пишет быстро и никогда не проходит проверку, допустит те же ошибки, что и junior-разработчик в пятницу вечером — просто быстрее и в большем количестве.

Что происходит с моими API-ключами и секретами?

Это тот вопрос, из-за которого я реально теряю сон, потому что ошибка здесь невидима до тех пор, пока не станет заметной. Сценарий провала не драматичен — сервер никто не взламывает в стиле фильмов про хакеров. Ключ просто вставляется в чат, отражается обратно в сгенерированном файле, попадает в коммит и спокойно лежит открытым текстом в репозитории полгода спустя, когда кто-то запускает сканер секретов из любопытства. В нашей платформе секреты вообще никогда не попадают в сгенерированный исходный код — они внедряются во время выполнения из зашифрованного хранилища, привязанного к вашему тенанту, а сборочные агенты получают инструкцию ссылаться на них по имени, а не по значению. Но если вы разрабатываете где-то ещё, или вставляете учётные данные напрямую в окно чата любого инструмента, считайте, что этот текст теперь где-то хранится в связанных с обучением логах, если провайдер прямо не заявляет обратное. Ротируйте всё, что когда-либо вводили в окно чата — из принципа, в тот же день, когда закончите тестирование.

Может ли кто-то взломать мой сайт через промпт, например, атакой prompt injection?

Здесь смешивают две разные вещи, и различие важно. Prompt injection против билдера — когда кого-то обманом заставляют ИИ, создающий ваше приложение, сделать то, о чём вы не просили — это реальный, изученный риск, и именно поэтому сборочные агенты работают с ограниченными правами на инструменты, а не с неограниченным доступом к shell, и именно поэтому любое действие, затрагивающее вашу файловую систему или пайплайн деплоя, проходит через явный журнал действий, который можно потом проверить. Prompt injection против вашего запущенного приложения — отдельная проблема, которая касается только тех случаев, когда ваше приложение само встраивает LLM во время выполнения — чат-бот поддержки, ИИ-поиск и подобное. Если это так, относитесь к любому тексту, который может ввести пользователь, как к недоверенным входным данным для этой модели — точно так же, как вы относились бы к недоверенным входным данным для SQL-запроса. Правило старое, новое здесь лишь то, какая система разбирает строку.

Проверяет ли билдер собственный код на уязвимости перед публикацией?

Автоматические проверки надёжно отлавливают скучные, часто встречающиеся вещи: захардкоженные секреты, отсутствие авторизации на эндпоинте, которому она явно нужна, SQL, построенный через конкатенацию строк вместо параметров, зависимости с известным CVE. Что они плохо ловят — это ошибки бизнес-логики, когда каждая отдельная строка кода в порядке, а уязвимость кроется в разрыве между двумя функциями, которые никто не додумался проверить вместе. Промокод, который бесконечно суммируется с реферальным бонусом. Механизм сброса пароля, который раскрывает, существует ли email в системе. Для этого нужен кто-то, кто понимает, для чего предназначено приложение, а не просто что делает код, и ни один сканер — ни ИИ, ни другой — пока не находит такие проблемы надёжно. Автоматическая проверка — это минимальный уровень, а не потолок.

А как насчёт сторонних пакетов, которые он устанавливает — это риск для цепочки поставок?

Да, и честно говоря, это более реальный практический риск, чем сам код, написанный ИИ. Большинство приложений на 80–95% состоят из зависимостей по количеству строк; код, который пишет билдер — это тонкий слой поверх npm, PyPI или любой другой используемой экосистемы. Вредоносный или взломанный пакет может скомпрометировать вас независимо от того, кто или что написал связующий код вокруг него — вспомните инциденты с event-stream и colors.js как пример того, как это происходит в реальности. Меры защиты скучны и эффективны: фиксируйте версии вместо отслеживания последних, отдавайте предпочтение пакетам с реальной историей поддержки, а не опубликованным на прошлой неделе, и проводите аудит зависимостей (`npm audit`, `pip-audit` или что подходит вашему стеку) как постоянную привычку, а не разовый шаг перед запуском.

Кто несёт ответственность в случае утечки?

Вы — с юридической точки зрения, почти всегда, если это ваше приложение и данные ваших клиентов. Это удивляет людей, которые предполагают, что «это написал ИИ» как-то смещает ответственность. Это не так, точно так же, как найм подрядчика не снимает с владельца здания ответственность за нарушение строительных норм. Платформы несут ответственность за инфраструктуру, которую они контролируют: как хранятся секреты, как изолируются данные тенантов, пропатчен ли сам уровень хостинга. Но логика приложения, которую вы задали, данные, которые вы решили собирать, и условия, которые вы предложили своим пользователям — это ваша ответственность. Если вы работаете с чем-то чувствительным — платёжными данными, медицинской информацией, чем-то под GDPR или CCPA — прочитайте реальное соглашение об обработке данных той платформы, на которой вы находитесь, вместо того чтобы предполагать, что «создано ИИ» подразумевает какой-то дополнительный слой юридической защиты. Это не так.

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

Стоит ли платить за настоящий аудит безопасности перед запуском?

Если вы принимаете платежи, храните что-либо, что регулятор назовёт персональными данными, или создаёте продукт для бизнес-клиента, который в любом случае попросит отчёт SOC 2 — да, и не позволяйте стоимости вас отговорить. Целенаправленный аудит небольшого приложения стоит от нескольких сотен до нескольких тысяч долларов в зависимости от объёма — это дёшево по сравнению с письмом-уведомлением об утечке. Если вы создаёте хобби-проект, внутренний инструмент или что-то без реальных пользовательских данных на кону, платный аудит — это избыточно; вместо этого используйте бесплатный и дешёвый уровень защиты — сканирование зависимостей, ручной обход каждой границы авторизации (может ли пользователь A увидеть данные пользователя B, изменив URL?) и взгляд второго человека на всё, что связано с деньгами или паролями.

Какая самая распространённая ошибка безопасности и когда она случается?

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