Трудно найти софтверную компанию, которая в 2025 году не использует генеративный AI в разработке. GitHub Copilot, Cursor, Windsurf, Claude Code — инструменты стали стандартом индустрии. По данным опроса Stack Overflow 2025 года, 84% разработчиков используют или планируют использовать AI-инструменты в разработке. При этом влияние на продуктивность не так однозначно, как принято считать: по данным Apiiro, разработчики с AI-ассистентами делают в 3–4 раза больше коммитов, но рандомизированный эксперимент METR (июль 2025) показал обратный эффект — опытные open-source-разработчики выполняли задачи с AI-инструментами на 19% медленнее, хотя сами были уверены, что ускорились.
Однако скорость — не единственная метрика качества кода. В июле 2025 года компания Veracode, один из мировых лидеров в области безопасности приложений, опубликовала результаты масштабного исследования, которое поставило под сомнение безоговорочное доверие к AI-генерируемому коду. Тестирование охватило более 100 различных языковых моделей — от компактных open-source решений до флагманских коммерческих продуктов.
Методология исследования прозрачна: 80 задач на дополнение кода — по пять вариантов для каждой комбинации из четырёх языков (Java, JavaScript, C#, Python) и четырёх классов уязвимостей: SQL-инъекции (CWE-89), межсайтовый скриптинг (CWE-80), инъекции в логи (log injection, CWE-117) и небезопасные криптографические алгоритмы (CWE-327). Каждую задачу можно решить и безопасным, и небезопасным способом; результат проверялся SAST-анализатором Veracode. Важная оговорка: другие категории рисков — например, вшитые в код секреты — в этом отчёте не тестировались.
Результаты исследования Veracode оказались отрезвляющими. В 45% случаев модели выбирали небезопасную реализацию, внося в код обнаруживаемую уязвимость из числа входящих в OWASP Top 10 — список наиболее критических уязвимостей веб-приложений. Иными словами, почти каждый второй фрагмент кода, написанный языковой моделью без явных требований безопасности в промпте, содержит известную уязвимость.
Сравнение с кодом человека даёт другое исследование — отчёт CodeRabbit «State of AI vs Human Code Generation» (декабрь 2025): при анализе 470 реальных pull request'ов в open-source-проектах AI-сгенерированные PR содержали в 2.74 раза больше проблем безопасности и в 1.7 раза больше дефектов в целом, чем написанные людьми. Эти цифры разрушают миф о том, что AI «пишет как senior-разработчик». В реальности AI пишет как начинающий программист, который знает синтаксис, но не понимает контекст безопасности — не задумывается о валидации входных данных, экранировании вывода, безопасном хранении секретов.
Особенно тревожной оказалась ситуация с межсайтовым скриптингом (Cross-Site Scripting, XSS). 86% AI-сгенерированного кода, который должен был обрабатывать пользовательский ввод для отображения на веб-страницах, не содержал адекватной защиты от XSS-атак. Модели последовательно игнорировали необходимость экранирования HTML-сущностей и санитизации данных. Ещё хуже результат у инъекций в логи (log injection, CWE-117): лишь 12% фрагментов корректно санитизировали данные перед записью в лог — худший показатель среди четырёх классов. Причём для XSS и log injection, по данным Veracode, результаты моделей со временем не улучшаются, а ухудшаются.
Почему XSS и log injection оказались такой проблемой? Исследователи Veracode объясняют: ключевая сложность — определить, какие переменные содержат недоверенные пользовательские данные и потому требуют санитизации. Для этого нужен межпроцедурный анализ потоков данных, который языковой модели недоступен, — в итоге модели санитизируют данные лишь эпизодически, например реагируя на «знакомое» имя переменной вроде username. Вносит вклад и обучающая выборка: значительная часть публичного кода сама содержит неисправленные уязвимости, и модель усваивает небезопасные реализации как равноправный способ решения задачи.
Вшитые в код секреты — API-ключи, пароли, токены аутентификации — Veracode в этом отчёте не проверяла, однако эту категорию рисков фиксируют другие исследования. По данным GitGuardian («The State of Secrets Sprawl 2025»), публичные репозитории с включённым GitHub Copilot допускают утечки секретов на 40% чаще среднего (6.4% против 4.6%). Apiiro на данных крупных предприятий отмечает, что разработчики с AI-ассистентами раскрывают облачные учётные данные почти вдвое чаще коллег, работающих без AI-инструментов. Механика знакомая: языковые модели, стремясь сгенерировать «работающий» пример, часто вставляют заглушки вида password = "admin123" или api_key = "sk-...", а разработчик, использующий такой код как основу, может забыть заменить заглушку на безопасное решение (переменные окружения, vault, менеджер секретов).
Проблема усугубляется тем, что многие AI-ассистенты генерируют код «для немедленного запуска»: он компилируется, проходит тесты, выполняет задачу — но делает это небезопасно. Разработчик получает ощущение завершённости, хотя код требует серьёзной доработки с точки зрения безопасности.
Одно из самых неожиданных открытий исследования: размер и новизна модели практически не коррелируют с безопасностью генерируемого кода. Новые, более крупные модели не показали значимого улучшения по сравнению со старыми. Это разрушает надежду на то, что проблема «решится сама» с выходом следующего поколения моделей.
Причина кроется в самой природе обучения. Модели оптимизированы на генерацию «корректного» кода — того, который компилируется, проходит юнит-тесты и решает функциональную задачу. Безопасность не является явной целью оптимизации при обучении большинства моделей. Гипотеза Veracode: обучающие данные — публичный код из интернета — почти всегда синтаксически корректны (разработчики редко коммитят некомпилируемый код), но при этом содержат массу неисправленных уязвимостей и никак не размечены на «безопасное» и «небезопасное». Поэтому от поколения к поколению у моделей улучшается синтаксис, но не безопасность.
Исследование выявило существенную разницу в безопасности кода в зависимости от языка программирования. Java оказалась лидером по доле небезопасного кода: 72% AI-сгенерированных фрагментов на Java содержали уязвимости. Для сравнения: у Python, JavaScript и C# доля провалов составила от 38% до 45%. Гипотеза Veracode: Java десятилетиями используется как серверный язык и получила распространение раньше, чем SQL-инъекции были осознаны как класс уязвимостей, поэтому в обучающих данных на Java заметно больше небезопасных примеров, чем на других языках.
Показательно, что на Java модели проваливали даже те задачи, которые в целом даются им легко, — например, параметризацию SQL-запросов. При этом сгенерированный код выглядит профессионально и идиоматично — что делает уязвимости особенно коварными, ведь их труднее заметить при code review.
На фоне мрачной общей картины есть и позитивные наблюдения. SQL injection — одна из старейших и наиболее известных уязвимостей — показала 80% pass rate, а выбор криптографических алгоритмов (CWE-327) — 86%, лучший результат среди четырёх классов. Модели относительно хорошо справляются с генерацией параметризованных SQL-запросов вместо конкатенации строк, и для этих двух классов результаты со временем улучшаются.
Объяснение, которое дают исследователи: для этих классов безопасная реализация корректна всегда, независимо от контекста. Prepared statement безопасен вне зависимости от того, попадают ли в запрос недоверенные данные; надёжный криптоалгоритм не требует знания архитектуры приложения. Модели не нужно понимать, откуда пришли данные, — достаточно воспроизвести хорошо документированный безопасный паттерн, которых в обучающей выборке много.
Ключевой практический вывод из данных Veracode прост и неприятен: AI-сгенерированный код следует рассматривать как недоверенный код. Точно так же, как компании проверяют код из open-source библиотек или от внешних подрядчиков, код от AI-ассистентов требует обязательной проверки статическим анализом (SAST) перед попаданием в продакшен.
Для многих компаний это означает пересмотр процессов. Если раньше SAST использовался как «финальная проверка» перед деплоем, то теперь он должен быть интегрирован максимально рано — в IDE, в pre-commit hooks, в CI/CD pipeline на этапе pull request. Каждая строка AI-кода должна пройти проверку до того, как попадёт в основную ветку.
На основании данных исследования можно сформулировать конкретные рекомендации для команд разработки:
Генеративный AI — мощный инструмент, который уже изменил повседневную практику разработки. Но ускорение без контроля — это ускорение в сторону катастрофы. Данные Veracode недвусмысленно показывают: модели не понимают безопасность, они воспроизводят статистические паттерны. И пока в этих паттернах доминирует небезопасный код, результат будет соответствующим.
Компании, которые хотят использовать преимущества AI-кодинга без сопутствующих рисков, должны выстроить многоуровневую систему контроля: от обучения разработчиков до автоматизированного сканирования на каждом этапе CI/CD. Скорость и безопасность — не взаимоисключающие понятия, но одно без другого приводит к предсказуемо плохим результатам.
SAID включает правило «Каждая строка — на проверку»: весь AI-сгенерированный код рассматривается как недоверенный и проходит обязательный SAST-анализ до мержа. Методология предусматривает интеграцию сканеров в IDE и CI/CD, библиотеку безопасных шаблонов для контекста AI-ассистентов, а также метрики отслеживания доли AI-кода и связанных с ним уязвимостей. Цель — использовать скорость AI без компромиссов в безопасности.