Трудно найти софтверную компанию, которая в 2025 году не использует генеративный AI в разработке. GitHub Copilot, Cursor, Windsurf, Claude Code — инструменты стали стандартом индустрии. По различным оценкам, от 60% до 80% разработчиков регулярно используют AI-ассистенты для написания кода. Это логично: скорость разработки возрастает в 3-4 раза, рутинные задачи автоматизируются, а порог входа для новичков снижается.
Однако скорость — не единственная метрика качества кода. В июле 2025 года компания Veracode, один из мировых лидеров в области безопасности приложений, опубликовала результаты масштабного исследования, которое поставило под сомнение безоговорочное доверие к AI-генерируемому коду. Тестирование охватило более 100 различных языковых моделей — от компактных open-source решений до флагманских коммерческих продуктов.
Результаты исследования Veracode оказались отрезвляющими. При проверке AI-сгенерированного кода по стандарту OWASP Top 10 — списку наиболее критических уязвимостей веб-приложений — 45% сгенерированных фрагментов не прошли тест. Это означает, что почти каждый второй фрагмент кода, написанный языковой моделью, содержит хотя бы одну уязвимость из десятки самых распространённых.
Для сравнения: код, написанный квалифицированными разработчиками, содержит в 2.74 раза меньше уязвимостей. Эта цифра разрушает миф о том, что AI «пишет как senior-разработчик». В реальности AI пишет как начинающий программист, который знает синтаксис, но не понимает контекст безопасности — не задумывается о валидации входных данных, экранировании вывода, безопасном хранении секретов.
Особенно тревожной оказалась ситуация с межсайтовым скриптингом (Cross-Site Scripting, XSS). 86% AI-сгенерированного кода, который должен был обрабатывать пользовательский ввод для отображения на веб-страницах, не содержал адекватной защиты от XSS-атак. Модели последовательно игнорировали необходимость экранирования HTML-сущностей, санитизации данных и использования Content Security Policy.
Почему XSS оказался такой проблемой? Защита от XSS требует понимания контекста: где именно данные будут отображаться (HTML, JavaScript, CSS, URL), какой тип экранирования необходим. AI-модели обучались на огромных массивах кода, значительная часть которого сама содержала XSS-уязвимости. Модель воспроизводит паттерны обучающей выборки — и если в выборке XSS встречается часто, модель научится генерировать XSS.
Ещё одна категория уязвимостей, где AI-модели показали стабильно плохие результаты — вшитые в код секреты: API-ключи, пароли, токены аутентификации. Языковые модели, стремясь сгенерировать «работающий» пример, часто вставляют заглушки вида password = "admin123" или api_key = "sk-...". Разработчик, использующий такой код как основу, может забыть заменить заглушку на безопасное решение (переменные окружения, vault, менеджер секретов).
Проблема усугубляется тем, что многие AI-ассистенты генерируют код «для немедленного запуска»: он компилируется, проходит тесты, выполняет задачу — но делает это небезопасно. Разработчик получает ощущение завершённости, хотя код требует серьёзной доработки с точки зрения безопасности.
Одно из самых неожиданных открытий исследования: размер и новизна модели практически не коррелируют с безопасностью генерируемого кода. Новые, более крупные модели не показали значимого улучшения по сравнению со старыми. Это разрушает надежду на то, что проблема «решится сама» с выходом следующего поколения моделей.
Причина кроется в самой природе обучения. Модели оптимизированы на генерацию «корректного» кода — того, который компилируется, проходит юнит-тесты и решает функциональную задачу. Безопасность не является явной целью оптимизации при обучении большинства моделей. Даже модели, прошедшие дополнительное обучение на безопасных паттернах (security-aware fine-tuning), показывают улучшение только на конкретных, знакомых им типах уязвимостей, но проваливаются на нестандартных сценариях.
Исследование выявило существенную разницу в безопасности кода в зависимости от языка программирования. Java оказалась лидером по доле небезопасного кода: 72% AI-сгенерированных фрагментов на Java содержали уязвимости. Это связано с несколькими факторами: сложность экосистемы Java (Spring, Hibernate, Jakarta EE), обилие конфигурационных паттернов, критичность серверных приложений, где Java доминирует.
Java-код, генерируемый AI, часто содержит проблемы с сериализацией (CWE-502), неправильной обработкой исключений, небезопасной конфигурацией JDBC-соединений и отсутствием параметризации SQL-запросов. При этом код выглядит профессионально и идиоматично — что делает уязвимости особенно коварными, ведь их труднее заметить при code review.
На фоне мрачной общей картины есть и позитивные наблюдения. SQL injection — одна из старейших и наиболее известных уязвимостей — показала 80% pass rate. Модели относительно хорошо справляются с генерацией параметризованных SQL-запросов вместо конкатенации строк.
Объяснение простое: SQL injection настолько хорошо документирована, что буквально каждый туториал, учебник и курс программирования явно предупреждает о ней. В обучающих данных AI-моделей примеров безопасной работы с SQL значительно больше, чем примеров защиты от XSS или безопасного управления секретами. Это указывает на путь решения: чем больше безопасных паттернов в обучающих данных, тем лучше модель генерирует безопасный код.
Ключевой вывод исследования 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 без компромиссов в безопасности.