Впервые за всю историю этого цикла исследований показатели сдвинулись с мертвой точки. С тех пор как мы начали отслеживать безопасность кода, созданного с помощью ИИ, средний показатель успешного прохождения тестов едва превышал 55–56%. Четыре замера, более 100 моделей, огромный прогресс в возможностях… а средний показатель оставался прежним. В прошлом квартале мы отмечали, что максимальная планка даже снизилась: с 72% (GPT-5 Mini, октябрь 2025 г.) до 68% (GPT-5.5, лето 2026 г.). Главным выводом было то, что «планку пробить не удается».
В этом квартале она сдвинулась. Средний показатель успешного прохождения тестов на безопасность подскочил с 56% до 62%. Это первое значимое движение за все время исследований. Частота уязвимостей снизилась примерно с 44% до ~38%. Новый максимум составляет 73%, его делят две модели. Десять моделей теперь преодолевают отметку в 60% по сравнению с четырьмя ранее, а межсайтовый скриптинг (CWE-80) наконец-то демонстрирует рост.
Но прежде чем называть это прорывом, к полученным результатам стоит присмотреться ближе. Улучшение реально, но оно неравномерно и сосредоточено на самых простых задачах в наборе данных.
Таблица лидеров осени 2026 года
Мы протестировали 18 моделей на четырех языках программирования (Python, C#, JavaScript, Java) и в четырех категориях CWE (CWE-89, CWE-327, CWE-80, CWE-117). Вот какие позиции они заняли:
Несколько моментов сразу бросаются в глаза.
Новые лидеры. Claude Opus 5.5 и GPT-6-Sol разделили первое место с результатом 73%, сместив GPT-5.5, которая возглавляла летний рейтинг 2026 года с 68%. Anthropic и OpenAI представляют по три модели в первой семерке.
Середина подтягивается. В июле шесть из одиннадцати моделей находились в диапазоне от 50% до 53%. В текущем квартале в этом диапазоне застряли лишь две модели. Десять моделей преодолевают рубеж в 60%. Среда расслаивается, и середина смещается вверх.
Нижняя граница практически не изменилась. Аутсайдеры рейтинга по-прежнему находятся на уровне 44–50%. Выбор модели остается вопросом безопасности: разница между моделью, которая ошибается в одной из трех задач по безопасности, и той, которая ошибается в каждой второй, определяет объем уязвимостей, попадающих в ваш кодовый базис.
Цена прогресса
У этого улучшения есть обратная сторона, которую таблица лидеров не отражает: модели на вершине требуют значительных затрат на вычисления. Claude Opus 5.5 ($4/$20 за миллион токенов ввода/вывода) и GPT-6-Sol ($2/$10) — это модели передового уровня с соответствующей стоимостью. Примечательно, что обе они дешевле своих предшественников, и ни одна из них не является самой дорогой на рынке. Данные показывают, что производительность напрямую связана с размером модели: у крупных моделей средний показатель составляет 55% против 51% у малых, что образует разрыв в 3,5 пункта и меняет прошлогодний результат. Безопасность улучшается, но прирост сосредоточен в сегменте более крупных моделей.
Для большинства организаций это создает непростую реальность. Модели, создающие наиболее безопасный код, обходятся дороже всего при масштабировании, и тем не менее они совершают ошибки более чем в одной из четырех задач безопасности. Организация, которая направляет всю генерацию кода через самые дорогие передовые модели в погоне за незначительным приростом безопасности, тратит вычислительный бюджет ради показателя успешности в 73%, которого можно добиться более экономично и надежно с помощью менее дорогих моделей и очистки результатов специализированными инструментами безопасности.
Арифметика проста: модель среднего уровня с показателем успешности 60% плюс сканирование Veracode работает точнее, экономичнее и масштабируемую, чем передовая модель с показателем 73% без верификации. Токены, потраченные на самую дорогую модель — это токены, не направленные на устранение уязвимостей. Мы ищем такую комбинацию модели и верификации, которая обеспечивает наилучший результат безопасности при минимальных затратах. Этот ответ почти никогда не звучит как «используйте самую дорогую модель и надейтесь на лучшее».
Что изменилось: CWE-80 обеспечивает весь прирост
И вот здесь история становится интереснее… и требует оговорки.
Общее улучшение показателей безопасности распределено по типам уязвимостей неравномерно. Оно в значительной степени сосредоточено в одной категории: CWE-80, cross-site scripting (XSS).CWE-80[[/L1]}.
В июле показатель XSS держался на среднем уровне 15. Мы списали это со счетов: «XSS демонстрирует скромный рост в самых последних моделях, но с настолько низкой базы, что его едва заметно».
Ситуация изменилась. Данные за осень 2026 года показывают резкую тенденцию CWE-80 к росту, а среднее значение увеличилось до 18%. Это самое крупное изменение во всем наборе данных, на которое приходится непропорционально большая доля видимого прогресса.
Между тем остальные три категории CWE практически не изменились:
Две сильные категории (криптография и SQL-инъекции) уже находились близко к своему потолку и остались там же. Две слабые категории разделились: XSS подскочила, внедрение данных в логи — нет.
Почему именно CWE-80 сдвигает показатель с мертвой точки
XSS — это самый простой класс уязвимостей для исправления с помощью распознавания образов, и именно этот механизм лежит в основе совершенствования языковых моделей (LLM).
Это простой и часто встречающийся паттерн. Базовые XSS сводятся к одному правилу: не помещайте ненадежные данные в контекст HTML без их кодирования или экранирования. Как только модель начинает стабильно предпочитать textContent использованию innerHTML или обращается к шаблонному движку фреймворка с автоматическим экранированием, частота сбоев резко падает. Для LLM это гораздо более простой паттерн для усвоения, чем правильная обработка символов перевода строки в логах, разделение заголовков ответа или тонкие целочисленные переполнения.
Данные для обучения сместились в сторону безопасных значений по умолчанию. Современные веб-фреймворки делают безопасный путь стандартным или путем наименьшего сопротивления. Общедоступный код, учебные пособия и репозитории на GitHub все чаще демонстрируют безопасный шаблон. Модели, обученные на более свежих данных, видят гораздо больше примеров «просто используйте экранирование фреймворка», чем сырую конкатенацию строк в HTML. Более старые модели обучались на большей доле небезопасного устаревшего стиля.
XSS — это наиболее подробно документированная и преподаваемая уязвимость. Существует огромное количество положительных и отрицательных примеров: статьи в блогах, разборы CTF-соревнований, материалы OWASP, курсы по безопасности, фрагменты кода с описанием того, как исправить XSS. Настройка согласованности и безопасности несоразмерно сильно затрагивает классические проблемы веб-инъекций, поскольку их легко генерировать, легко оценивать и они обладают высокой заметностью. Внедрение данных в логи и разделение заголовков получают гораздо меньше такого внимания.
Безопасный API прост и очевиден. В языках, которые мы тестируем, обычно есть четкая и хорошо известная безопасная функция для кодирования вывода. Модели склонны следовать кратчайшему пути, предлагаемому языком или предполагаемыми библиотеками. Для XSS этот путь стал более безопасным. Для внедрения в логи кратчайший путь часто по-прежнему остается уязвимым.
Чувствительность оценки. Тесты безопасности рассматривают CWE-80 по простому принципу «прошел/не прошел»: попадают ли ненадежные данные в HTML-приемник без нейтрализации? Модель, которая начинает регулярно выбирать безопасный приемник, дает большой измеримый скачок. Более сложные CWE требуют более глубокого анализа потока данных, контекста или побочных каналов, поэтому они развиваются медленнее.
Кратко говоря: показатели безопасности выглядят лучше во многом потому, что модели стали намного лучше справляться с самым простым, наиболее часто иллюстрируемым и поддерживаемым фреймворками классом уязвимостей.
Почему сложные случаи остаются на прежнем уровне
CWE-117 (внедрение записей в лог) остается на прежнем уровне ~12% и не показывает никаких признаков восстановления ни в одном срезе этой серии. Причина носит структурный характер: внедрение в лог требует анализа потоков данных — отслеживания пользовательского ввода через преобразования, хранение и рендеринг в нескольких функциях, чтобы определить, попадает ли он в приемник лога в не нейтрализованном виде. Здесь нет какого-то одного «безопасного API», к которому можно было бы обратиться. Уязвимость носит контекстуальный, а не основанный на шаблонах характер, и именно с этим LLM продолжают испытывать трудности.
Это та же динамика, которую мы отмечали в июльском отчете о Java: улучшение заканчивается ровно там, где заканчивается распознавание образов. XSS поддается распознаванию по шаблонам. Внедрение в лог — нет. Модели совершенствуются в первом и буксуют во втором.
Чтобы подробнее узнать о важности контекста и рисках использования ИИ-агентов для написания кода, посмотрите наш разбор: Риски ИИ-агентов для написания кода.
Сфера разделяется по-новому
Помимо таблицы лидеров, тенденции на уровне категорий выявляют несколько заслуживающих внимания сдвигов.
Модели общего назначения все сильнее опережают модели, ориентированные на написание кода. Универсальные модели показывают в среднем 54% в задачах безопасности; специализированные на коде модели — 51%. В июле этот разрыв составлял около 1 процентного пункта. Он увеличился до 3. Оптимизация под более быстрое написание кода не означает его более безопасное написание — и этот разрыв растет, а не сокращается.
Размер модели теперь имеет значение. В обновлении за октябрь 2025 года мы сообщали, что размер модели «практически не влияет» на показатели безопасности. Это изменилось. Крупные модели теперь в среднем достигают 55%, средние — 52%, а малые — 51% (разброс составляет 4 пункта). Масштабирование не решает проблему безопасности, но оно уже не выглядит для нее совершенно неважным.
Java все еще буксует. Java остается резким исключением на уровне ~31%, едва поднявшись с 30% в июле. Это единственный язык с четкой восходящей траекторией на протяжении всей серии, но ему же предстоит пройти и самый долгий путь. В некоторой степени это может быть ситуация, когда Java медленно приближается к среднему значению — улучшаясь из-за того, что начинала с очень низких показателей, и вероятно, выйдет на плато, когда достигнет уровня 50–60%. На данный момент разрыв между Java и остальными тремя языками по-прежнему составляет 26–33 процентных пункта.
Ширше взгляд: что это на самом деле исправляет
Стоит честно оценить, что на самом деле означает улучшение безопасности кода с помощью ИИ с 56% до 62% в контексте вашей общей поверхности рисков.
Улучшение в этом наборе данных сосредоточено на базовом XSS: это единственный класс уязвимостей и один из самых простых для обнаружения и устранения. Между тем, сложные случаи (внедрение в лог, уязвимости контекстного потока данных) остаются неизменными. Java остается неизменной. Разрыв между функциональностью и безопасностью остается неизменным. Лучшая модель по-прежнему дает сбой более чем в одном из четырех заданий по безопасности.
Теперь перенесемся от сгенерированного ИИ кода к более широкой картине безопасности программного обеспечения. Согласно отчету Veracode 2026 State of Software Security, 82% организаций в настоящее время имеют долговые обязательства по безопасности — известные уязвимости, которые остаются неисправленными более года. По сравнению с 2025 годом (74%) и 2024 годом (71%). Критический долг по безопасности — недостатки, которые одновременно имеют высокую степень серьезности и высокую степень эксплуатируемости и остаются неисправленными более года — теперь затрагивает 60% организаций, что означает рост на 20% за один год. Среднее время устранения дефекта составляет 243 дня.
И вот что позволяет взглянуть на безопасность ИИ-кода в перспективе: 66% наиболее опасных и долгоживущих уязвимостей происходят из стороннего кода. Это библиотеки, зависимости и компоненты с открытым исходным кодом, которые данный бенчмарк безопасности ИИ-кода не тестирует. Устранение этих дефектов занимает в среднем 358 дней.
Улучшение предотвращения XSS в сгенерированном ИИ коде — это реальный прогресс. Но оно залечивает лишь малый уголок гораздо большей раны. Самые большие риски в вашем программном стеке (те, которые сохраняются месяцами, наиболее вероятны для эксплуатации и находятся в вашей цепочке поставок) — это не те, которые улучшились в этом наборе данных или которые он вообще может измерить.
Что не изменилось
Синтаксис по-прежнему остается решенной проблемой, составляя почти 100% по всем направлениям. Частота уязвимостей снизилась с ~44% до ~38%. Это существенно, но все же означает, что примерно 4 из 10 задач по генерации кода с помощью ИИ в этом тесте создали код с известной уязвимостью. Разрыв между функциональностью и безопасностью по-прежнему существует и не устранен ни одной моделью. Парадокс производительности и безопасности сохраняется: модели, которые умеют рассуждать над сложными проблемами, писать беглый код на четырех языках и почти на 100% проходить синтаксические проверки, все равно привносят обнаруживаемые уязвимости примерно в 4 задачах из 10, если им не давать никаких специфических для безопасности указаний.
Суть дела
Улучшение реально! Мы видим, что новые модели создают больше кода, который одновременно функционален и безопасен. Но это не значит, что разрыв устранен или что вы можете перестать относиться к выводам LLM как к недоверенным. Прирост неравномерен: некоторые CWE остаются на прежнем уровне, а имеющийся прогресс сосредоточен в самом легком классе уязвимостей. Реальное влияние на практике по-прежнему зависит от окружающего приложения, такого как обработка вывода, CSP, настройки фреймворка по умолчанию. Модель, генерирующая более безопасные фрагменты, все равно может создать XSS, если приложение впоследствии отобразит результат небезопасным образом.
Вывод заключается не в том, что проблемы безопасности решены. Он в том, что безопасность улучшается там, где ее проще всего улучшить, а сложные проблемы остаются ровно там, где они были всегда. Наиболее эффективная стратегия — не погоня за самой дорогой моделью ради незначительного прироста. Это сочетание генерации кода с помощью ИИ с непрерывной независимой проверкой безопасности, которая улавливает то, что пропускает модель, и охватывает всю поверхность риска: от кода собственной разработки до сторонних зависимостей.
Полную методологию, исторический контекст по четырем срезам и более глубокий анализ каждого CWE, языка и категории моделей читайте в отчете 2026 GenAI Code Security Report.
Чтобы получить более полное представление о рисках безопасности программного обеспечения, включая долги по безопасности, тенденции в отношении сторонних уязвимостей и эталоны исправления, читайте отчет 2026 State of Software Security Report.
