В среднем AI-сгенерированный код приносит 15 подтвержденных уязвимостей на одну кодовую базу, из них 4,3 относятся к критическому или высокому уровню. Для команд, которые уже встроили генерацию кода в повседневную разработку, цифра неприятная, но еще неприятнее другое: риск зависит не столько от самой модели, сколько от того, с каким фреймворком ее свели в пару.
Об этом сообщает Dark Reading со ссылкой на свежий AI Trust Index от Secure Code Warrior. Компания вместе с RMIT University оценила 1760 полноценных кодовых баз, сгенерированных 16 frontier-моделями от OpenAI, Anthropic, Google и других вендоров. Всего исследователи нашли более 27 тысяч уязвимостей. То есть разговор про безопасность AI-кода уже давно вышел из стадии «ну, Copilot иногда чудит» и перешел в стадию, где риски можно считать, сравнивать и, главное, предсказывать.
Самый заметный вывод отчета выглядит почти контринтуитивно. Универсального победителя среди моделей не нашлось. Да, по общему trust score лучше других выглядели модели семейства Claude, а OpenAI GPT 5 Mini оказался внизу рейтинга с результатом 21,6 по шкале от 0 до 100. Но если смотреть не на среднюю температуру по больнице, а на конкретные технологические стеки, картина резко меняется. Один и тот же инструмент может выглядеть очень прилично в Django и довольно слабо в другом окружении. В материале приводят пример Claude Opus 4.8: для Django он получил 100 баллов, а для C-Basic и C#-Basic результат просел до 57,3 и 28,5 соответственно.
Именно поэтому для бизнеса главный вопрос звучит уже не как «какую LLM купить разработчикам», а как «в каких связках модель плюс фреймворк мы готовы ее пускать в production». Secure Code Warrior проверяла 11 фреймворков и пришла к выводу, что агрегированный рейтинг модели важен меньше, чем конкретная пара модель-стек. Иными словами, закупка дорогого AI-ассистента сама по себе не дает индульгенции. Если команда пишет в среде, где модель системно промахивается по базовым защитным механизмам, красивый логотип вендора мало поможет.
Еще один неприятный, но полезный вывод: уязвимости в AI-коде возникают не как случайный шум, а как повторяемый паттерн. Исследователи пишут, что у каждой модели есть свой «security fingerprint» — то есть устойчивый профиль ошибок по категориям OWASP. На практике это означает, что AppSec-команды могут не просто ругаться на очередной pull request с галлюцинациями, а строить предсказуемые правила контроля. Если конкретная модель в конкретном стеке регулярно забывает про проверки аутентификации или валидацию входных данных, это уже не эксцесс, а характеристика инструмента.
По словам сооснователя и CEO Secure Code Warrior Питера Даньё, разница между самыми безопасными и самыми рискованными фреймворками в исследовании достигала 40 раз. Наибольшую долю риска дали JavaScript и Java EE/JSP, тогда как C# и Java Spring, как он выразился, «едва регистрировались» по уровню проблем. Для технических директоров и руководителей платформенных команд это довольно прямой сигнал: политику использования AI-инструментов стоит завязывать не на общекорпоративный запрет или разрешение, а на профиль риска конкретного стека. Где риск высокий, там нужны обязательные security gate и дополнительные требования к обучению команд до релиза, а не после очередного разбора инцидента.
При этом исследование не подтверждает популярную бытовую теорию, что безопасность можно просто докупить вместе с более дорогой моделью. Secure Code Warrior отдельно отмечает слабую или нулевую корреляцию между стоимостью использования модели и качеством кода с точки зрения безопасности. Более того, самые частые проблемы связаны не с экзотическими exploit-цепочками, а с вещами, которые модель просто забывает сделать: проверить аутентификацию, провалидировать ввод, не утечь чувствительными данными в логи. Исследователи нашли 17 CWE, которые повторялись у всех 16 моделей. В первую очередь они советуют фокусироваться на пяти типах дефектов: утечки чувствительных данных в логах, XSS, hard-coded credentials, предсказуемые токены сессий и коды сброса, а также path traversal.
Для русскоязычной IT-аудитории здесь мало сенсации, но много прикладного смысла. Если у вас уже есть AI-сгенерированный код в репозиториях, спорить о том, «плохая» ли генерация кода как класс, поздно. Полезнее пересобрать процессы: проверять стековые сочетания, метить зоны повышенного риска, пересматривать secure coding training и подключать статический анализ туда, где модель системно ошибается. Главный вопрос на ближайший год, похоже, будет не в том, смогут ли LLM писать больше кода, а в том, научатся ли компании различать, где этот код ускоряет поставку, а где просто быстрее производит технический долг с уязвимостями. Подробности исследования собраны в материале .