ИИ ускоряет выпуск кода, а команды не успевают закрывать уязвимости

Компании ускоряют разработку с помощью искусственного интеллекта, но вместе с объёмом кода растёт и очередь нерешённых проблем безопасности. Речь идёт не только об ошибках в сгенерированных фрагментах, но и о сторонних пакетах, которые ИИ-инструменты добавляют в проекты.

24 августа 2026 года The Hacker News опубликовал партнёрский материал ActiveState о так называемом долге исправлений. Под этим термином понимают накопившийся объём задач по проверке, обновлению и удалению небезопасных компонентов, который команды не успевают закрывать до выхода продукта в эксплуатацию.

Как формируется долг исправлений

При использовании ИИ разработчик может за несколько минут получить готовую функцию вместе с новыми зависимостями. Каждая из них требует отдельной проверки: специалисты должны установить происхождение пакета, наличие известных уязвимостей, актуальность поддержки, лицензионные ограничения и необходимость компонента для работы приложения.

Если такие проверки не встроены в процесс разработки, уязвимые библиотеки переходят из экспериментов в тестовые среды, а затем и в рабочие системы. В результате скорость написания кода повышается быстрее, чем способность служб безопасности оценивать и устранять риски.

ActiveState опросила 300 руководителей в сфере безопасности и разработки из технологического сектора, финансовых услуг, здравоохранения, промышленности и государственного управления. Исследование посвящено тому, как организации управляют рисками открытого кода, связанными с ИИ, и как накопившиеся задачи отражаются на аудитах, частоте инцидентов и производительности.

Независимые данные подтверждают проблему

Отчёт Veracode за 2026 год показывает, что примерно в 44% проверенных заданий по генерации кода модели создавали код с известной уязвимостью. Средний показатель безопасного результата составил около 56% и почти не изменился по сравнению с началом наблюдений. В компаниях, которые уже используют ИИ-помощников, такие инструменты, по оценке Veracode, участвуют примерно в создании половины закоммиченного кода.

Другой показатель приводит IT Pro со ссылкой на исследование Stack Overflow за 2025 год: ИИ-инструменты уже используют 84% разработчиков. Из этого следует, что проблема перестала быть экспериментальной. Сгенерированный код всё чаще попадает в обычные корпоративные процессы, где его должны сопровождать те же проверки, что и код, написанный человеком.

TechRadar в мае 2026 года отмечал, что разработчики сталкиваются не столько с нехваткой средств обнаружения, сколько с избытком результатов сканирования. Издание ссылалось на оценку, согласно которой уязвимости встречаются примерно в 45% фрагментов, созданных ИИ, а запросы на изменения с участием генеративных моделей содержат в среднем в 1,7 раза больше проблем, чем изменения, подготовленные без них.

Почему одного показателя критичности недостаточно

Традиционная модель управления уязвимостями часто строится вокруг оценок серьёзности. Однако одинаковый балл не означает одинаковую опасность для разных систем. Значение имеют доступность компонента из интернета, путь до конфиденциальных данных, фактическое использование уязвимой функции и наличие публичного эксплойта.

Поэтому приоритет следует отдавать не самому длинному списку находок, а подтверждённым рискам, которые можно использовать в конкретной инфраструктуре. Такой подход помогает направлять ресурсы на уязвимости, способные привести к компрометации данных или нарушению работы сервиса.

Какие меры сокращают очередь

Первый шаг — инвентаризация всех компонентов, включая транзитивные зависимости, которые устанавливаются автоматически вместе с основным пакетом. Для этого компании используют ведомости состава программного обеспечения, известные как SBOM, и связывают их с системами управления уязвимостями.

Второй шаг — автоматические ограничения на этапе сборки. Проверка лицензий, происхождения пакетов, сигнатур, версий и известных CVE должна проходить до попадания изменений в основную ветку или рабочую среду. При этом блокировать необходимо не каждую находку, а только риски, соответствующие заранее установленным критериям.

Третий шаг — перенос проверок в среду разработчика. Уведомление в системе контроля версий или редакторе кода обычно быстрее приводит к исправлению, чем отдельная запись в перегруженной панели безопасности. Для каждой проблемы также должен быть назначен ответственный и установлен срок устранения.

Автоматическое исправление может ускорить обновление зависимостей и подготовку изменений, но не отменяет тестирование. Особенно важна проверка человеком для кода, который отвечает за аутентификацию, права доступа, шифрование, платежи и обработку персональных данных.

Что означает публикация ActiveState

Материал The Hacker News представляет вебинар ActiveState, а не независимое расследование или отчёт государственного регулятора. Его ценность — в постановке практической проблемы, с которой сталкиваются разработчики и службы безопасности: ИИ уменьшает время выпуска кода, но не устраняет последующую работу по проверке и сопровождению.

Вебинар с участием вице-президента ActiveState по работе с клиентами Мориса Чена и старшего менеджера по маркетингу Ребекки Бэнкс посвящён результатам опроса и моделям управления риском. Главный вывод для компаний прост: скорость генерации кода нужно согласовывать с возможностями контроля зависимостей, приоритизации уязвимостей и проверки исправлений. Без этого рост производительности разработчиков будет сопровождаться увеличением технического и операционного долга.