70% разработчиков считают ИИ-код дырявым, при этом 30% всех опрошенных деплоят его в прод

Если вы думаете, что ИИ пишет код лучше вас — пересмотрите свои ожидания. 70% разработчиков убеждены: код, сгенерированный нейросетями, содержит больше уязвимостей, чем человеческий. Ещё более шокирующая цифра — 30% всех опрошенных признаются, что сознательно деплоят этот дырявый код в продакшен.

Таковы результаты ежегодного исследования компании Checkmarx — вендора инструментов для анализа безопасности приложений. В опросе участвовали 2350 разработчиков, CISO (Chief Information Security Officer) и AppSec-менеджеров (application security) по всему миру. Выборка выросла на 54% по сравнению с прошлым годом, что делает данные ещё более репрезентативными.

ИИ пишет половину кода — и это проблема

По данным Checkmarx, сегодня примерно 49% кода в продакшене создаётся с помощью ИИ. Это немного меньше, чем 54% в прошлом году, но всё ещё колоссальная цифра. Почти каждая вторая строка в вашем приложении может быть рождена нейросетью, которая обучалась на публичных репозиториях — со всеми их багами, устаревшими паттернами и скрытыми уязвимостями.

Причина проста: языковые модели обучаются на огромных массивах существующего кода, включая устаревшие практики и известные CVE (Common Vulnerabilities and Exposures). Исследователи из University of Central Florida и Birzeit University в 2025 году провели сравнительный анализ безопасности кода, сгенерированного разными LLM для Java, Python, C и C++. C-код оказался самым дырявым, Python — относительно чистым. Но ключевой вывод исследования шире: модели «недоиспользуют современные языковые и компиляторные возможности, предпочитая устаревшие практики более безопасным альтернативам». Сами исследователи оговаривают: LLM эволюционируют быстро, и их выводы — это «снимок во времени» (time-stamped view), а не вечная истина.

Почему разработчики деплоят то, что не доверяют

Вот в чём парадокс: разработчики видят проблему, но не чувствуют ответственности за её решение. Основные причины, по которым уязвимый код попадает в прод, выглядят так:

• Давление сроков и необходимость быстро деплоить фичи.
• Уязвимости слишком сложно или дорого исправлять постфактум.
• Надежда на то, что «другие инструменты безопасности подхватят» на поздних этапах.
• Нормализация риска: когда все вокруг деплоят с багами, это перестаёт восприниматься как катастрофа.

Checkmarx прямо констатирует: «Risk is normalized» — риск стал нормой. 93% респондентов сообщили о как минимум одной бреши в безопасности, связанном с уязвимыми приложениями. В прошлом году это было 98% — статистика чуть улучшилась, но не кардинально. Когда девять из десяти компаний регулярно взламывают, инцидент перестаёт быть новостью и становится рутиной.

Объём ИИ-кода напрямую коррелирует с частотой деплоя уязвимого кода, которая, в свою очередь, коррелирует с частотой инцидентов безопасности.

Исследователи CheckmarxОтчёт Checkmarx

Самая тревожная цифра: организации, где 81–100% кода генерируется ИИ, деплоят уязвимый код в 3,4 раза чаще, чем компании с умеренным использованием ИИ (1–20%). Это прямая корреляция: чем выше доля ИИ-генерации, тем чаще в прод попадают уязвимости. Причина не только в самом коде, но и в том, что высокая скорость разработки часто сопровождается слабыми процессами безопасности.

Open source как фундамент — и фундамент трещит

Ещё один слой проблемы — open source. По оценкам респондентов, 59% кода в продакшене приходится на открытые библиотеки. Это самооценки, но они отражают реальность: современный проект без node_modules, requirements.txt или Cargo.toml немыслим. Проблема в том, что мейнтейнеры этих библиотек часто не успевают закрывать уязвимости, а злоумышленники активно внедряют вредоносные пакеты в npm, PyPI и другие репозитории.

ИИ-инструменты ускоряют разработку, но не ускоряют аудит безопасности. Veracode в своём отчёте предупреждает: скорость ИИ-разработки делает безопасность недостижимой, если процессы не перестраиваются соответствующим образом. Инструменты статического анализа и сканеры на базе ИИ уязвимостей существуют, но организации не умеют встраивать их в процесс. «Инструменты делают работу, но компании не умеют переводить это в процесс» — констатируют в Checkmarx.

Например, вот типичная разница между ИИ-сгенерированным кодом и безопасной альтернативой. Copilot или аналогичные инструменты часто предлагают устаревший pickle.load для десериализации данных:

			# Уязвимый вариант (часто предлагает ИИ)
import pickle

def load_user_data(filename):
    with open(filename, "rb") as f:
        return pickle.load(f)  # опасно: выполняет произвольный код

# Безопасная альтернатива
import json

def load_user_data_safe(filename):
    with open(filename, "r", encoding="utf-8") as f:
        return json.load(f)  # безопасно: только парсинг данных
		

pickle.load выполняет произвольный Python-код при десериализации — классическая уязвимость из списка OWASP Top 10. Аналогичные проблемы часто встречаются в SQL-запросах без параметризации, использовании eval() и устаревших криптографических функциях. Проверяйте каждый snippet перед мержем.

Как не превратить ИИ-ускорение в ИИ-катастрофу

Отказываться от ИИ в разработке бессмысленно — это уже не инструмент будущего, а повседневная реальность. Но можно и нужно менять подход:

1. Проверяйте ИИ-код так же тщательно, как человеческий. Не предполагайте, что нейросеть знает лучше.
2. Автоматизируйте сканирование уязвимостей в CI/CD. SAST (Static Application Security Testing) и DAST (Dynamic Application Security Testing) должны быть обязательным шагом пайплайна, а не опцией.
3. Аудитируйте зависимости. Используйте инструменты вроде npm audit, Snyk или OWASP Dependency-Check.
4. Обучайте команду безопасности. Разработчики должны понимать, какие уязвимости чаще всего генерирует ИИ для вашего стека.
5. Не жертвуйте безопасностью ради скорости. Если уязвимость критична — отложите релиз. Технический долг в безопасности обходится в разы дороже, чем в производительности.

Выводы

ИИ — это не замена разработчику, а ускоритель. Как любой ускоритель, он требует тормозов. Когда 30% всех опрошенных сознательно деплоят код, в котором сами признают уязвимости, проблема не в технологиях — а в отсутствии дисциплины. Не верьте нейросети на слово: проверяйте зависимости, сканируйте код, требуйте ревью. Ускорение без контроля — это не оптимизация, а авария в замедленной съёмке.

Источник: The Register — Devs know AI code is riddled with holes, but ship it anyway