70% разработчиков считают, что уязвимый AI-код встречается чаще, чем код, написанный вручную, а 30% признают: они осознанно отправляли такой код в продакшен. Для русскоязычной IT-аудитории это не абстрактная страшилка про «плохой ИИ», а вполне прикладной сигнал: скорость релизов уже давно побеждает базовую дисциплину безопасности, и генеративные инструменты только усилили этот перекос.
Об этом сообщает The Register со ссылкой на исследование Checkmarx. Компания опросила 2350 специалистов по всему миру: разработчиков, CISO и менеджеров AppSec. Главный вывод неприятно прямолинеен: разработчики видят риски, понимают, что AI-подсказки и AI-генерация приносят больше уязвимостей, но бизнесовый и продуктовый прессинг заставляет выпускать код все равно. В итоге безопасность все чаще работает не как обязательное условие релиза, а как факультатив, который пытаются догнать уже после выката.
В цифрах картина выглядит жестко. Доля AI-сгенерированного кода в продакшене, по самооценке участников опроса, составила 49%. Годом раньше Checkmarx фиксировала 54%, но авторы материала оговаривают важную деталь: в этом году выборка стала на 54% больше, так что небольшое снижение не обязательно означает реальное охлаждение к генеративной разработке. Почти половина продакшен-кода с участием ИИ уже сама по себе выглядит как новая норма. На этом фоне особенно показательно другое число: 59% кода в производственных приложениях приходится на open source-компоненты. То есть типичный современный стек собирается из генерации, библиотек и зависимостей, в которых уязвимости могут прятаться слоями.
Из этого и складывается тревожная логика. AI-инструменты учатся на существующем публичном коде, а значит, наследуют не только полезные паттерны, но и старые плохие привычки. The Register отдельно напоминает о прошлогоднем академическом исследовании Университета Центральной Флориды и Университета Бирзейт в Палестине: ученые сравнивали безопасность кода, который генерируют LLM для Java, Python, C и C++. Тогда выяснилось, что результаты сильно зависят и от языка, и от модели; больше всего проблем было у C, меньше всего у Python. Но важнее даже не рейтинг языков, а наблюдение по сути: LLM часто недоиспользуют современные возможности языков и компиляторов, предпочитая устаревшие практики более безопасным альтернативам. Причина банальна и оттого еще неприятнее: именно такого кода в обучающих данных слишком много.
Еще один симптом, который сложно списать на погрешность опроса, касается уже не теории, а последствий. 93% респондентов сообщили как минимум об одном инциденте безопасности, связанном с уязвимыми приложениями. В прошлом году Checkmarx приводила еще более высокий показатель, 98%, но даже после снижения число выглядит почти как статистическая капитуляция отрасли. Причины тоже знакомые до боли: давление на команды из-за сроков, сложность исправления уязвимостей и надежда на то, что «остальные контроли подстрахуют». По сути, речь уже не о единичных промахах, а о нормализации риска. Если перевести это с корпоративного на человеческий язык, получается простая формула: все знают, что дыра есть, но релиз горит сильнее.
Checkmarx прямо пишет, что проблема не в отсутствии инструментов. Статический анализ, сканеры зависимостей, AI-помощники для поиска и исправления уязвимостей существуют и в целом умеют делать свою работу. Узкое место в другом: компании не превращают возможности инструментов в обязательный процесс. Это особенно хорошо совпадает с тем, о чем ранее говорила Veracode: AI резко разгоняет темп разработки, а практики безопасности за этим темпом не успевают. Иными словами, вопрос уже не в том, может ли команда найти уязвимость, а в том, есть ли у нее право задержать релиз ради исправления.
Для разработчиков здесь мало нового на уровне ощущений, но много важного на уровне подтвержденных цифр. Если почти половина продакшен-кода создается с участием ИИ, то обсуждать генеративные инструменты как «эксперимент для отдельных команд» уже бессмысленно. Это инфраструктурный слой повседневной разработки. А значит, и требования к нему должны быть соответствующие: обязательная проверка AI-генерации, контроль зависимостей, нормальный review, понятные правила, где генерация уместна, а где нет. Иначе уязвимый AI-код будет восприниматься как естественная плата за производительность, хотя на практике эта «плата» быстро превращается в инциденты, простой, внеплановые фиксы и неприятные разговоры с безопасниками.
Для бизнеса вывод еще проще и жестче. Ускорение поставки действительно работает: AI помогает писать больше кода быстрее. Но исследование Checkmarx утверждает и вторую часть уравнения: чем выше доля AI-генерации, тем чаще уязвимый AI-код доезжает до продакшена, а вместе с ним растет и частота инцидентов. Самая показательная цифра в отчете именно здесь: организации, где 81-100% кода генерируется ИИ, отправляют уязвимый код в прод в 3,4 раза чаще, чем компании с уровнем использования AI в диапазоне 1-20%. Это уже не философский спор про будущее профессии, а конкретная метрика операционного риска.
Главный вопрос теперь не в том, будут ли команды писать с ИИ, а в том, кто первым перестанет считать безопасность тормозом для скорости. Пока рынок выглядит так, будто генерация кода стала обязательной, а зрелый AppSec-процесс по-прежнему остается опцией. В такой конфигурации выиграют не те, кто быстрее всех подключил AI-ассистента, а те, кто сумел встроить его в процесс без привычки выпускать в прод все, что успело скомпилироваться.