Каждый вендор AI-инструментов для разработки рассказывает одну и ту же историю: «Ваши разработчики будут работать в разы быстрее». И они не врут — скорость действительно растёт. Код генерируется за секунды, рутинные задачи автоматизируются, боилерплейт исчезает. По данным Apiiro, разработчики, использующие AI-ассистенты, делают в 3–4 раза больше коммитов, чем их коллеги, работающие без ИИ.
Но ни один вендор не говорит о побочном эффекте этого ускорения. В сентябре 2025 года компания Apiiro — разработчик платформы анализа рисков в коде (ASPM) — опубликовала исследование «4x Velocity, 10x Vulnerabilities». Его методология: собственный движок Deep Code Analysis проанализировал десятки тысяч репозиториев и коммиты нескольких тысяч разработчиков в компаниях из Fortune 50, сравнивая декабрь 2024 и июнь 2025 года; «находкой» (finding) считается любая зафиксированная движком проблема безопасности — от небезопасных паттернов кода и утёкших секретов до уязвимых open-source-зависимостей и ошибок конфигурации облака. Результат: к июню 2025 года AI-сгенерированный код приносил более 10 000 новых security-находок в месяц против примерно 1 000 в декабре 2024-го — десятикратный рост за шесть месяцев. Важная оговорка: Apiiro продаёт инструменты для решения именно этой проблемы, поэтому цифры вендорского исследования корректно рассматривать вместе с независимыми данными — например, Veracode и GitClear (см. источники).
Самое тревожное в данных Apiiro — не абсолютные цифры, а пропорция. Объём генерируемого кода вырос в 3–4 раза (по числу коммитов), а количество security-находок — в 10 раз. Это означает, что каждая новая строка AI-кода в среднем несёт больше риска, чем строка, написанная человеком. ИИ не просто генерирует код быстрее — он генерирует небезопасный код быстрее.
Математика здесь безжалостна. Если команда из 10 разработчиков производила 1000 строк кода в день с 10 уязвимостями, то с AI она производит 4000 строк с 100 уязвимостями. Плотность уязвимостей выросла в 2.5 раза, а абсолютное количество — в 10 раз. Команда безопасности, которая с трудом справлялась с прежним потоком, теперь физически не способна обработать десятикратный объём.
Apiiro описывает и второй механизм роста риска: разработчики с ассистентами упаковывают изменения в меньшее число более крупных pull request — общее количество PR упало почти на треть, зато каждый стал затрагивать больше файлов и сервисов. Крупные PR дольше проверяются, размывают внимание ревьюера и повышают шанс, что тонкая ошибка проскользнёт в продакшен.
Исследование Apiiro не ограничилось общими цифрами — оно показало, какие именно типы уязвимостей растут быстрее всего при использовании AI-ассистентов.
Секреты и облачные учётные данные — почти в 2 раза чаще. По данным Apiiro, разработчики с AI-ассистентами оставляют в коде облачные учётные данные (Azure Service Principals, ключи доступа к хранилищам) почти вдвое чаще, чем коллеги без ИИ. Картину подтверждает GitGuardian: в выборке из ~20 000 репозиториев с включённым GitHub Copilot секреты утекали на 40% чаще среднего по GitHub — 6.4% репозиториев против 4.6%. AI-модели, стремясь сгенерировать «рабочий» пример, вставляют учётные данные прямо в код — строки вида db_password = "P@ssw0rd", — а разработчики часто не заменяют заглушки: код работает, тесты проходят.
Пути эскалации привилегий — рост на 322%. Самый резкий скачок Apiiro зафиксировала в глубоких архитектурных проблемах: путей эскалации привилегий в AI-коде стало больше на 322%, архитектурных дефектов проектирования — на 153%. Сюда же примыкает более раннее наблюдение Apiiro (февраль 2025): десятикратный рост числа репозиториев с API без авторизации и валидации входных данных. К этому классу относится и небезопасная прямая ссылка на объект (Insecure Direct Object Reference, IDOR) — уязвимость, при которой пользователь получает доступ к чужим объектам, просто изменив идентификатор в запросе. AI-модели создают функциональный код, который «делает то, что просили», но почти никогда сами не добавляют проверки прав на уровне объектов — без учёта того, кто именно это просит.
При этом мелких дефектов стало меньше: синтаксических ошибок в AI-коде — на 76%, логических багов — более чем на 60%. Находки сместились в сторону системных слабостей, которые сканеры пропускают, а ревьюеры не успевают заметить; сама Apiiro описывает это как «ИИ чинит опечатки — и создаёт мины замедленного действия». Все эти проблемы объединяет одно: AI-модели не понимают бизнес-контекст приложения и генерируют код без учёта модели угроз.
Одна из ключевых причин, по которой AI-уязвимости попадают в продакшен — когнитивное искажение, известное как предвзятость автоматизации (automation bias). Люди склонны доверять выводам автоматических систем больше, чем собственному суждению. Это хорошо изучено в авиации, медицине и финансах — а теперь проявляется в разработке ПО.
Когда разработчик видит код, сгенерированный AI, происходит интересная подмена: он воспринимает его как проверенный, как будто это код из официальной документации или от опытного коллеги. Code review AI-сгенерированного кода нередко проходит менее тщательно, чем ревью кода от джуниора. Это парадоксально: к коду джуниора разработчик относится скептически, а к коду ИИ — с незаслуженным доверием.
Данные GitClear — 211 млн изменённых строк кода за 2020–2024 годы — показывают родственную тенденцию: доля скопированного кода (copy/paste) выросла с 8.3% до 12.3%, а доля перемещённых строк (moved code — маркер рефакторинга) упала с 25% в 2021 году до менее чем 10% в 2024-м; скопированные строки впервые за время наблюдений превысили перемещённые. Разработчики всё чаще просто принимают AI-сгенерированный код без переработки — и без проверки на безопасность.
Многие компании скажут: «У нас есть SAST, он поймает уязвимости». И год назад это было бы разумным аргументом. Но десятикратный рост объёма кода ломает привычные процессы.
Традиционные инструменты статического анализа спроектированы для работы с кодом, который растёт постепенно — на проценты и десятки процентов в год, а не в разы за полгода. Когда объём нового кода увеличивается в разы за полгода, возникают три проблемы. Во-первых, время сканирования: полный SAST-анализ большого проекта может занимать часы, а с ростом кодовой базы — ещё дольше. Во-вторых, количество false positives: больше кода означает больше ложных срабатываний, команда безопасности тонет в шуме. В-третьих, приоритизация: когда находок тысячи, невозможно исправить все, а алгоритмы приоритизации не учитывают специфику AI-сгенерированного кода.
Необходимы новые подходы: контекстный анализ, который понимает, какой код сгенерирован AI, real-time сканирование в IDE, и приоритизация на основе фактической достижимости уязвимости, а не только её теоретической серьёзности.
Есть ещё один аспект, который часто упускают из виду: AI увеличивает не только количество уязвимостей, но и общую площадь атаки (attack surface) приложения. Когда разработчик генерирует код с помощью AI, он часто получает больше функциональности, чем запрашивал — дополнительные эндпоинты, обработчики, конфигурации. Каждый из них — потенциальная точка входа для атакующего.
AI также увеличивает разнообразие используемых библиотек и зависимостей. Модель может предложить библиотеку, которую разработчик никогда бы не выбрал сам — менее популярную, хуже поддерживаемую, с известными уязвимостями. В итоге поверхность атаки через цепочку поставок (supply chain attack surface) растёт вместе с количеством собственных уязвимостей: находки в уязвимых open-source-зависимостях Apiiro выделяет как одну из основных категорий.
Данные Apiiro дополняются результатами Veracode: в тестах «2025 GenAI Code Security Report» (80 задач, 100+ моделей) 45% образцов AI-сгенерированного кода содержали уязвимости из OWASP Top 10. Вместе они указывают на необходимость фундаментального пересмотра подхода к безопасности при использовании AI-ассистентов. Честная оговорка: первые два пункта ниже — «guardrails, а не ворота» и контекстный анализ — совпадают с тезисами самой Apiiro, вендора ASPM-платформы; учитывайте её коммерческий интерес, хотя сами принципы шире одного продукта.
AI-ассистенты — не враги безопасности. Они — мощные инструменты, которые при правильном использовании действительно ускоряют разработку. Но «правильное использование» включает осознание рисков и выстраивание процессов, которые компенсируют слабые стороны AI-генерации.
Каждая принятая без проверки уязвимость — это технический долг по безопасности. Он накапливается незаметно, но платить по нему придётся — в виде взломов, утечек, штрафов, потери репутации. Данные Apiiro показывают: этот долг растёт в 10 раз быстрее, чем раньше. Время выстраивать процессы — сейчас, пока масштаб проблемы ещё управляем.
Методология SAID основана на принципе «контроль пропорционален скорости»: чем быстрее команда генерирует код, тем больше автоматизированных проверок безопасности должно быть встроено в процесс. SAID предусматривает guardrails на каждом этапе — от IDE до деплоя, контекстный анализ AI-кода и отдельные метрики безопасности для AI-сгенерированных фрагментов. Цель — сохранить ускорение, устранив диспропорцию рисков.