Каждый вендор AI-инструментов для разработки рассказывает одну и ту же историю: «Ваши разработчики будут работать в разы быстрее». И они не врут — скорость действительно растёт. Код генерируется за секунды, рутинные задачи автоматизируются, боилерплейт исчезает. Компании фиксируют ускорение разработки в 3-4 раза по различным метрикам: от количества коммитов до скорости закрытия задач.
Но ни один вендор не говорит о побочном эффекте этого ускорения. В июне 2025 года компания Apiiro — специалист по анализу рисков в коде — опубликовала данные, которые заставляют задуматься. Анализ тысяч репозиториев показал: с ростом использования AI-ассистентов количество security-находок увеличилось в 10 раз — с примерно 1000 до более чем 10000 в месяц — за период менее полугода.
Самое тревожное в данных Apiiro — не абсолютные цифры, а пропорция. Скорость разработки выросла в 4 раза, а количество уязвимостей — в 10 раз. Это означает, что каждая новая строка AI-кода несёт больше риска, чем строка, написанная человеком. AI не просто генерирует код быстрее — он генерирует небезопасный код быстрее.
Математика здесь безжалостна. Если команда из 10 разработчиков производила 1000 строк кода в день с 10 уязвимостями, то с AI она производит 4000 строк с 100 уязвимостями. Плотность уязвимостей выросла в 2.5 раза, а абсолютное количество — в 10 раз. Команда безопасности, которая с трудом справлялась с прежним потоком, теперь физически не способна обработать десятикратный объём.
Исследование Apiiro не ограничилось общими цифрами — оно показало, какие именно типы уязвимостей растут быстрее всего при использовании AI-ассистентов.
Hardcoded passwords — рост в 1.88 раза. AI-модели, стремясь сгенерировать «рабочий» пример, регулярно вставляют пароли прямо в код. Строки вида db_password = "P@ssw0rd" или secret_key = "my-secret-key" стали настоящей эпидемией в репозиториях. Разработчики, получая готовый фрагмент кода, часто не удаляют заглушки — ведь код работает, тесты проходят.
Insecure Direct Object References (IDOR) — рост в 1.91 раза. Это уязвимость, при которой пользователь может получить доступ к объектам другого пользователя, просто изменив идентификатор в запросе. AI-модели почти никогда не генерируют проверки авторизации на уровне объектов — они создают функциональный код, который «делает то, что просили», без учёта того, кто именно это просит.
Помимо этих категорий, значительный рост зафиксирован в уязвимостях, связанных с отсутствием валидации входных данных, небезопасной десериализацией и неправильной конфигурацией CORS. Все эти проблемы объединяет одно: AI-модели не понимают бизнес-контекст приложения и генерируют код без учёта модели угроз.
Одна из ключевых причин, по которой AI-уязвимости попадают в продакшен — когнитивное искажение, известное как automation bias (предвзятость автоматизации). Люди склонны доверять выводам автоматических систем больше, чем собственному суждению. Это хорошо изучено в авиации, медицине и финансах — а теперь проявляется в разработке ПО.
Когда разработчик видит код, сгенерированный AI, происходит интересная подмена: он воспринимает его как проверенный, как будто это код из официальной документации или от опытного коллеги. Code review AI-сгенерированного кода проходит менее тщательно, чем ревью кода от джуниора. Это парадоксально: к коду джуниора разработчик относится скептически, а к коду AI — с незаслуженным доверием.
Исследования GitClear показывают аналогичную тенденцию: доля «moved code» и «copy-pasted code» в репозиториях выросла на десятки процентов. Разработчики всё чаще просто принимают AI-сгенерированный код без модификации — и без проверки на безопасность.
Многие компании скажут: «У нас есть SAST, он поймает уязвимости». И год назад это было бы разумным аргументом. Но десятикратный рост объёма кода ломает привычные процессы.
Традиционные инструменты статического анализа спроектированы для работы с кодом, который растёт линейно — на 10-20% в год. Когда объём нового кода увеличивается в разы за полгода, возникают три проблемы. Во-первых, время сканирования: полный SAST-анализ большого проекта может занимать часы, а с ростом кодовой базы — ещё дольше. Во-вторых, количество false positives: больше кода означает больше ложных срабатываний, команда безопасности тонет в шуме. В-третьих, приоритизация: когда находок тысячи, невозможно исправить все, а алгоритмы приоритизации не учитывают специфику AI-сгенерированного кода.
Необходимы новые подходы: контекстный анализ, который понимает, какой код сгенерирован AI, real-time сканирование в IDE, и приоритизация на основе фактической достижимости уязвимости, а не только её теоретической серьёзности.
Есть ещё один аспект, который часто упускают из виду: AI увеличивает не только количество уязвимостей, но и общую площадь атаки (attack surface) приложения. Когда разработчик генерирует код с помощью AI, он часто получает больше функциональности, чем запрашивал — дополнительные эндпоинты, обработчики, конфигурации. Каждый из них — потенциальная точка входа для атакующего.
AI также увеличивает разнообразие используемых библиотек и зависимостей. Модель может предложить библиотеку, которую разработчик никогда бы не выбрал сам — менее популярную, хуже поддерживаемую, с известными уязвимостями. В итоге supply chain attack surface растёт не менее стремительно, чем количество собственных уязвимостей.
Данные Apiiro и подтверждающие их исследования Veracode указывают на необходимость фундаментального пересмотра подхода к безопасности при использовании AI-ассистентов.
AI-ассистенты — не враги безопасности. Они — мощные инструменты, которые при правильном использовании действительно ускоряют разработку. Но «правильное использование» включает осознание рисков и выстраивание процессов, которые компенсируют слабые стороны AI-генерации.
Каждая принятая без проверки уязвимость — это технический долг по безопасности. Он накапливается незаметно, но платить по нему придётся — в виде взломов, утечек, штрафов, потери репутации. Данные Apiiro показывают: этот долг растёт в 10 раз быстрее, чем раньше. Время выстраивать процессы — сейчас, пока масштаб проблемы ещё управляем.
Методология SAID основана на принципе «контроль пропорционален скорости»: чем быстрее команда генерирует код, тем больше автоматизированных проверок безопасности должно быть встроено в процесс. SAID предусматривает guardrails на каждом этапе — от IDE до деплоя, контекстный анализ AI-кода и отдельные метрики безопасности для AI-сгенерированных фрагментов. Цель — сохранить ускорение, устранив диспропорцию рисков.