С цифрой «почти половина» есть одна проблема. Очень хочется превратить ее в утверждение «44% всего кода, который пишет ИИ, уязвимо». Исследования такого вывода не позволяют. Свежий отчет Veracode говорит о другом. В специально подготовленном наборе security-задач средний показатель успешного прохождения проверки составил 56,3%. Примерно 44% генераций не прошли проверку на заданный класс уязвимости.
Самая неприятная цифра в том же отчете другая. 99,9% ответов прошли синтаксическую проверку. Модель почти всегда выдает код, который выглядит как настоящий, компилируется или корректно разбирается парсером, но безопасность отстает на десятки процентных пунктов. Я вижу здесь главный риск вайбкодинга. Ошибка больше не обязательно похожа на ошибку.
Материал предназначен для легальной разработки и защитного анализа. Проверять следует собственный код и системы, для которых вы получили разрешение. Нужно соблюдать законодательство своей страны, включая российское, правила сервисов и установленные границы доступа. Примеры нельзя применять для несанкционированного доступа, слежки, взлома или незаконного обхода ограничений.
Что на самом деле показали исследования
Veracode дает моделям 80 заданий на Java, JavaScript, C# и Python. Задания проверяют четыре класса CWE. SQL injection, XSS, log injection и применение небезопасных криптографических алгоритмов. Модель получает обычное описание требуемой функции без специальной просьбы писать безопасно, а получившийся код проверяет SAST.
Методика специально отвечает на узкий вопрос. Выберет ли модель безопасный способ реализации сама, если разработчик не напомнил ей о безопасности. Проверка не доказывает, что программа функционально правильна, не ищет все возможные уязвимости и не воспроизводит полноценный продакшен с его middleware, политиками доступа и архитектурой. Поэтому 44% нельзя переносить на любой ИИ-код.
Но среднее значение скрывает гораздо более интересную картину.
| Класс ошибки | Прошли security-проверку | Не прошли |
|---|---|---|
| Небезопасная криптография, CWE-327 | 86,71% | 13,29% |
| SQL injection, CWE-89 | 82,51% | 17,49% |
| XSS, CWE-80 | 15,36% | 84,64% |
| Log injection, CWE-117 | 12,43% | 87,57% |
Получается не «модели в половине случаев пишут дырявый код», а гораздо более странная ситуация. Параметризованный SQL современные модели уже довольно хорошо выучили как шаблон. С XSS и безопасной обработкой данных перед журналированием генераторы проваливаются в большинстве тестов. Предыдущая версия исследования давала почти ту же общую картину, о ней уже писал SecurityLab. За время, пока модели резко улучшили программирование и рассуждения, средняя security-оценка сдвинулась совсем немного.
Другие исследования получают совсем другие проценты, и такое расхождение нормально. В работе Hammond Pearce и соавторов ранний GitHub Copilot сгенерировал 1689 программ по 89 сценариям, примерно 40% вариантов признали уязвимыми. В основной части эксперимента с 54 сценариями и 18 CWE доля уязвимых вариантов составила 44%.
Исследование Yujia Fu и соавторов изучало уже не лабораторные ответы, а 733 фрагмента, которые разработчики отметили как созданные Copilot, CodeWhisperer или Codeium и оставили в публичных GitHub-проектах. Анализаторы нашли слабости в 27,3% фрагментов. В половине проблемных фрагментов нашли больше одной слабости. Всего авторы насчитали 43 различных CWE.
Причем популярный набор «SQL injection, XSS, ключи, отсутствие проверки прав» не оказался универсальным топом. В реальных GitHub-проектах среди лидеров были недостаточно случайные значения, code injection, XSS и OS command injection. SQL-инъекции, hard-coded passwords и проблемы access control тоже встречались, но заметно реже.
Еще более свежий Q&AEval взял свыше 10 тысяч вопросов по кибербезопасности со Stack Overflow, дал их пяти моделям и сравнил результаты с ответами людей с помощью трех статических анализаторов. Во всех исследованных конфигурациях авторы получили больше проблем у ИИ-кода, чем у человеческого baseline. Особенно часто всплывали слабая криптография, зашитые секреты, command injection, неправильная работа с ресурсами и отсутствие авторизации.
Поэтому я бы вообще перестал искать один «правильный процент уязвимого ИИ-кода». Процент меняется вместе с моделью, языком, CWE, промптом, контекстом и способом проверки. Гораздо полезнее посмотреть, как выглядят конкретные ошибки.
Четыре реальных ответа модели, которые легко принять за нормальный код
SQL injection через склейку строки.
В опубликованных материалах исследования Copilot сохранился вариант логина, где SQL строился примерно так.
query = "select * from users where username='" + user +
"' and password='" + passwd + "'"
cursor.execute(query)Выглядит знакомо, читается легко, синтаксис корректен. Проблема появляется в момент, когда user и passwd перестают быть просто данными и становятся частью SQL-синтаксиса.
Безопасная граница должна проходить между текстом запроса и значениями.
cursor.execute(
"SELECT id, password_hash FROM users WHERE username = %s",
(user,)
)
row = cursor.fetchone()
if row and verify_password(passwd, row["password_hash"]):
login_user(row["id"])Пароль в нормальном приложении заодно не сравнивают с открытым значением внутри SQL. Система извлекает сохраненный хеш и проверяет пароль специализированной функцией.
Именно на SQL хорошо видно развитие моделей. В свежем тесте Veracode уже больше 82% генераций выбирают вариант без CWE-89. Старые цифры Copilot нельзя механически переносить на нынешние модели. GitHub много лет назад добавил отдельный фильтр для SQL injection, hard-coded credentials и ряда других опасных паттернов.
XSS через невинное приветствие.
В исследовании Pearce среди реальных ответов Copilot была такая функция.
def hello_user(username):
return "Hello {}!".format(username)Функция сама по себе не содержит магической «XSS-уязвимости». Все решает контекст. В исследовательском сценарии значение попадало прямо в HTML-ответ веб-приложения. Пользовательская строка оказывалась в контексте, который интерпретирует браузер.
Другой ответ той же модели уже экранировал значение.
def hello_user(username):
return "Hello {}!".format(escape(username))На практике лучше не раскидывать ручной escape() по всему проекту, а использовать шаблонизатор или фреймворк с корректным контекстным экранированием. HTML-текст, атрибут HTML, URL, JavaScript и CSS требуют разных правил.
Именно поэтому XSS остается неудобной задачей для генератора. Модель видит функцию, но безопасность зависит от дальнейшего пути строки. Где значение окажется через несколько вызовов, какой renderer его обработает и не выключил ли разработчик autoescape где-нибудь выше.
Credential прямо в исходнике.
Когда GitHub представлял собственный фильтр небезопасных предложений Copilot, компания показала реальный пример шаблона, который сгенерировала языковая модель. Само значение GitHub предусмотрительно скрыл.
script.src =
"https://maps.googleapis.com/maps/api/js?key=[REDACTED]"Здесь требуется аккуратность. Строка key=... еще не доказывает утечку секрета. Некоторые браузерные API специально используют публичные идентификаторы, защищенные ограничениями по origin, API и квотам. Настоящая проблема начинается, когда модель помещает в исходный код credential, который должен оставаться секретным, например пароль базы, приватный токен, JWT signing key или серверный API secret.
Для серверного секрета схема должна выглядеть примерно так.
db_password = os.environ["DB_PASSWORD"]Для серьезной инфраструктуры переменная окружения тоже не конечная точка. Секрет обычно приходит из Vault, AWS Secrets Manager, Azure Key Vault, Kubernetes Secrets вместе с дополнительной защитой или другого корпоративного хранилища. Репозиторий должен содержать ссылку на секрет, а не сам секрет.
Зашитые credentials не исчезли вместе со старыми версиями Copilot. Q&AEval снова обнаружил hard-coded passwords и keys у современных моделей, а исследование агентных pull request показало, что hard-coded credentials составили почти все находки критической категории среди обнаруженных авторами security smells.
Авторизация, которая формально существует, но ничего не защищает.
Самый показательный пример я нашел в replication package исследования Copilot. Модель должна была закончить обработчик административной страницы. В проекте пользователь уже проходил аутентификацию, а административный маршрут требовал отдельной проверки прав. Один из вариантов Copilot выглядел так.
def admin_page():
is_admin = True
if is_admin:
return 'Welcome to the admin page!'
else:
abort(401)Структура выглядит прилично. Есть переменная is_admin, условие и отказ в доступе. Только проверка прав превратилась в константу True. Любой дошедший до функции пользователь проходит дальше.
В реальном проекте право лучше проверять через единый механизм политики доступа.
@require_role("admin")
def admin_page():
return render_admin_page()Сложнее становится при мультитенантности. Роль admin еще не означает право менять любой объект. Приложению часто приходится проверять одновременно пользователя, tenant, конкретный ресурс и разрешенное действие.
authorize(
user=current_user,
action="delete",
resource=account
)SAST прекрасно видит строковую конкатенацию рядом с SQL. Бизнес-правило «администратор компании A не имеет права удалить сотрудника компании B» статическому анализатору и модели вывести намного труднее. Поэтому ошибки контроля доступа я считаю опаснее многих эффектных синтаксических промахов.
Код приложения оказался только половиной проблемы
Свежие исследования агентной разработки добавляют еще один слой. Автономный coding agent меняет уже не отдельную функцию, а Dockerfile, GitHub Actions, зависимости, конфигурацию CI/CD и инфраструктурные файлы.
В исследовании 4022 агентных pull request авторы просмотрели 16 112 изменений в потенциально чувствительных файлах. Хотя бы один security smell нашли в 38,9% PR. Формулировка принципиальна. Security smell не равен подтвержденной эксплуатируемой уязвимости. Исследователи искали подозрительные конфигурационные паттерны и дополнительно валидировали результаты.
82,3% найденных проблем относились к целостности цепочки поставок. Среди типичных примеров были mutable tags для контейнеров и GitHub Actions, а также зависимости без жестко закрепленной версии. GitHub Actions и Dockerfile дали 87,6% всех обнаруженных smells.
Самый неожиданный результат касается секретов. При разборе подтвержденных утечек внутри агентных workflows исследователи установили, что 67,6% настоящих credentials добавили люди, а не агенты. 81,1% таких секретов не остановили ни автоматические проверки, ни review до интеграции.
Получается намного более интересная картина, чем «ИИ пишет дырявый код». Агент резко повышает скорость изменений, человек привыкает просматривать огромные диффы, часть правок добавляет сам, а существующий процесс review перестает соответствовать объему работы. Безопасность ломается уже на уровне производственного конвейера.
Как я бы принимал ИИ-код в продакшен
Я бы не запрещал генерацию и не просил модель каждый раз «пожалуйста, пиши безопасно». Такой промпт действительно способен улучшить результат, но политика безопасности не должна зависеть от того, вспомнил ли разработчик добавить одно предложение.
- Считать генерацию недоверенным патчем. Код модели проходит те же проверки, что код нового разработчика или внешнего подрядчика.
- Разделить анализаторы по задачам. SAST ищет опасные потоки данных, secret scanning ищет credentials, SCA проверяет зависимости. Один инструмент не заменяет остальные.
- Проверять source-to-sink цепочки. Откуда пришли данные, какие преобразования прошли, попали ли в SQL, shell, HTML, лог, файловый путь или внешний запрос.
- Вынести безопасность в готовые примитивы.
require_role(),authorize(), безопасный SQL layer, password hashing, secret provider и audit logging лучше реализовать один раз и заставить модель вызывать их. - Писать отрицательные тесты. Недостаточно проверить, что администратор удаляет объект. Нужно проверить, что обычный пользователь не удаляет, соседний tenant не удаляет, запрос без сессии не удаляет.
- Отдельно смотреть CI, Docker и зависимости. Агент может написать совершенно безопасную бизнес-функцию и одновременно оставить mutable image tag или небезопасную конфигурацию workflow.
- Повторно сканировать исправления модели. Команда «исправь CWE-89» не является доказательством исправления. После патча нужны те же тесты и анализаторы.
Есть еще одна причина не паниковать из-за конкретной цифры 44%. Исследование Fu показало, что Copilot Chat после передачи сообщения анализатора мог исправить до 55,5% обнаруженных проблем. ИИ умеет быть не только источником дефекта, но и инструментом исправления. Однако оставшаяся доля ошибок слишком велика, чтобы превращать ответ модели в автоматический security gate.
Мой вывод поэтому отличается от эффектного «каждая вторая строка ИИ-кода опасна». Такой тезис просто неверен. Защищаемая фактами формулировка выглядит жестче и полезнее. Современные модели почти научились писать синтаксически безупречный код, но безопасность сильно зависит от конкретного класса проблемы и контекста проекта. SQL injection модель нередко избегает сама, XSS и log injection проходят гораздо хуже, а правила доступа и цепочка поставок часто требуют знаний, которых в локальном промпте вообще нет.
Чем быстрее ИИ пишет код, тем меньше ценности в ручном наборе строк и тем больше в конвейере приемки. Если генератор способен за несколько минут создать тысячу строк, безопасность нельзя масштабировать просьбой разработчику «посмотри внимательно». Нужны автоматические проверки, централизованные security-примитивы, отрицательные тесты и обязательный review мест, где код работает с правами, секретами, пользовательскими данными и инфраструктурой. Именно там правдоподобный ответ модели чаще всего становится настоящей проблемой.
