Искусственный интеллект меняет не только способ написания кода. Он меняет скорость жизненного цикла программного обеспечения. AI-ассистенты и автономные агенты сокращают время между постановкой задачи, изменением кода, добавлением зависимости и выпуском новой версии. Одновременно снижается стоимость анализа исходного кода, поиска уязвимостей и подготовки исправлений. На этом фоне возникает один из ключевых рисков ближайших лет: скорость производства и потребления программных изменений начинает расти быстрее, чем скорость корпоративного контроля. Разработчик может получить рабочий код за минуты, новая версия библиотеки — появиться за недели, а согласование, тестирование и установка обновления в крупной организации по-прежнему занимают недели или месяцы.

Возникают своеобразные «ножницы скорости»: программная экосистема постепенно переходит на машинный темп, а значительная часть процессов информационной безопасности остается на человеческом. Поэтому мой прогноз состоит не столько в появлении нового класса угроз, сколько в изменении самой временной модели ИБ. В ближайшие годы информационной безопасности придется работать на той же скорости, на которой меняется программный стек. Для этого недостаточно быстрее получать сообщения о CVE. Необходимо перестраивать управление зависимостями, обновлениями и жизненным циклом программного обеспечения.

Современное прикладное ПО в значительной степени состоит из компонентов, которые организация сама не разрабатывала. По данным Open Source Security and Risk Analysis, open source присутствует практически во всех исследуемых коммерческих кодовых базах. В исследовании 2025 года речь шла о 97% кодовых баз, при этом около 70% исследованного кода имело open-source-происхождение, а среднее приложение включало 911 OSS-компонентов. В исследовании 2026 года доля кодовых баз с open source достигла 98%, а среднее количество OSS-компонентов на приложение выросло до 1180. Но для информационной безопасности еще важнее то, как эти компоненты попадают в приложение.

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

Есть и менее очевидная сторона AI-assisted development. Разработчик использует ИИ не только для генерации алгоритмов. Он просит подобрать библиотеку, подготовить Dockerfile, написать конфигурацию, добавить интеграцию, исправить ошибку или обновить существующий проект.

Вместе с кодом AI-ассистент фактически начинает принимать решения о программных зависимостях. И эти решения не обязательно безопасны. Языковая модель обучалась на большом объеме существующего программного кода. Значительная часть этого кода была создана несколько лет назад и использует версии библиотек, актуальные на момент его написания. Поэтому функционально корректный ответ не гарантирует, что предложенная зависимость соответствует текущему состоянию программной экосистемы.

AI-ассистент может предложить знакомую и работоспособную библиотеку, версия которой уже устарела или содержит известную уязвимость. Исследование 2026 года, в котором было проанализировано более 117 тыс. изменений программных зависимостей в семи экосистемах, показало: AI-агенты выбирали версии с уже известными уязвимостями в 2,46% случаев против 1,64% у людей.

Причем ошибки агентов оказались еще и труднее устранимы: 36,8% таких выборов требовали мажорного обновления для исправления против 12,9% у человека. В совокупности агентская работа с зависимостями дала чистый прирост уязвимостей, тогда как работа людей — чистое снижение. Сам по себе этот результат пока не позволяет делать универсальные выводы по всей индустрии, но механизм риска достаточно понятен.

Отраслевые данные 2026 года это подтверждают: анализ около 258 тыс. рекомендаций по зависимостям, сгенерированных семью AI-моделями, показал, что почти 28% предложенных обновлений оказались несуществующими — так называемыми галлюцинированными зависимостями. Проблема не в том, что несуществующий пакет просто не установится. Проблема в том, что здесь появляется отдельный вид атаки — dependency confusion через галлюцинации, или slopsquatting. Злоумышленник заранее регистрирует под таким же именем настоящий пакет в публичном репозитории. Как только другой разработчик или другой AI-агент повторит ту же рекомендацию, зависимость окажется реальной, но контролируемой не автором проекта, а атакующим.

Это принципиально новый класс supply chain attack, специфичный именно для эпохи AI-assisted-разработки: имя пакета из подсказки модели становится потенциальной точкой входа в инфраструктуру раньше, чем сам пакет физически появляется в публичном репозитории.

ИИ способен ускорять не только производство функциональности, но и накопление dependency risk — причем сразу в двух формах: через устаревшие и уязвимые версии реальных библиотек и через несуществующие зависимости, которые становятся реальными по вине атакующего.

На первый взгляд проблема решается просто: достаточно написать AI-ассистенту, что необходимо использовать только актуальные версии библиотек без известных уязвимостей. Для промышленной разработки этого недостаточно. Безопасность не должна зависеть от того, вспомнил ли конкретный разработчик о том, чтобы добавить соответствующее требование в промпт. Кроме того, «последняя версия» не всегда означает «разрешенная версия». В организации могут существовать поддерживаемые ветки, корпоративные репозитории, требования к лицензиям, ограничения по совместимости, внутреннее тестирование и перечни разрешенных компонентов.

Следовательно, AI-ассистенту необходим не только контекст исходного кода. Ему нужен контекст технологической доверенности организации. Какие компоненты разрешены? Какие версии поддерживаются? Какие репозитории являются доверенными? Какие зависимости запрещены? Какие версии уже протестированы? Какие уязвимости являются недопустимыми? Какой компонент необходимо использовать вместо устаревшего? Эти ограничения должны существовать не на уровне отдельного запроса разработчика, а на уровне инфраструктуры разработки.

Показательный пример — Java-экосистема. Здесь важно разделять два разных цикла. Feature-релизы JDK сохраняют шестимесячный цикл. При этом контур обновлений безопасности становится более динамичным: наряду с привычным квартальным циклом критические исправления начинают выпускаться чаще, в том числе ежемесячно.

Это уже не прогноз, а свершившийся факт. В июле 2026 года Oracle официально анонсировала переход на дополнительные ежемесячные Critical Security Patch Updates (CSPU): первый такой релиз был запланирован на 18 августа 2026-го, а начиная с 2027 года компания рассчитывает выпускать по несколько внеплановых обновлений в год в дополнение к квартальным CPU. Показательно и обоснование самой Oracle: ускорение объясняется тем, что ИИ меняет скорость обнаружения и устранения уязвимостей. Практически синхронно, 23 июля 2026 года, о переходе на ежемесячный цикл критических патчей для LTS-версий объявила и Azul, наша компания также перешла на ежемесячный выпуск CSPU-релизов, они выходят одновременно с релизами Oracle.

Речь идет не о том, что вся Java-платформа переходит на ежемесячные релизы. Меняется допустимое окно между обнаружением критической проблемы и выпуском исправления. Рост возможностей AI-инструментов для анализа кода, поиска уязвимостей и подготовки исправлений дополнительно сокращает этот интервал. Для компаний это означает не просто необходимость чаще устанавливать патчи. Потребуется быстрее определять затронутые системы, пересобирать приложения, выполнять тесты совместимости, оценивать влияние изменений и выводить обновления в промышленную эксплуатацию. Ускоряется не один релизный календарь. Ускоряется весь контур принятия решения.

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

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

Необходимо максимально быстро принимать качественное решение: что именно затронуто, насколько критичен риск, можно ли безопасно обновиться и какие компенсирующие меры нужны до установки исправления.

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

Именно поэтому SBOM необходимо рассматривать как часть операционной модели инфраструктуры. Технически это означает работу с машиночитаемыми форматами вроде CycloneDX или SPDX, встроенными в конвейер сборки, а не разовый отчет, сгенерированный перед аудитом. В конечном счете, это смыкается с более широким набором практик доверенной цепочки поставок — SLSA, OpenSSF Scorecard, in-toto, которые описывают не только состав приложения, но и доверенность самого процесса его сборки.

Компонент должен быть связан с конкретным приложением, приложение — с владельцем, владелец — с бизнес-процессом, версия компонента — с известными уязвимостями и сроком поддержки, система — с уровнем критичности. Тогда появление новой уязвимости превращается из исследовательской задачи в запрос к уже существующей модели. Где используется компонент? Какие версии затронуты? Какие системы критичны? Кому принадлежит решение об обновлении?

Отсюда следует основной практический вывод. Если разработка переходит на машинную скорость, информационная безопасность не сможет оставаться преимущественно ручным процессом. Проверка зависимостей должна происходить непосредственно в процессе сборки. SBOM должен формироваться автоматически. Новые компоненты должны проверяться по корпоративной политике до попадания в продукт. Информация о новых уязвимостях должна автоматически сопоставляться с фактическим составом приложений. Обновления должны автоматически попадать в контур тестирования. AI-агент должен выбирать зависимости не из всего доступного Интернета, а из контролируемого пространства разрешенных компонентов и доверенных репозиториев.

Отдельного внимания здесь заслуживает инфраструктура, через которую сами AI-агенты получают доступ к внешним сервисам и инструментам, — протокол MCP (Model Context Protocol) и экосистема MCP-серверов. За немногим более года публичная экосистема выросла от нескольких десятков до более чем 10 тыс. активных серверов, значительная часть которых не проходит сколько-нибудь системной проверки доверия. Это уже не гипотетический риск: отраслевые оценки фиксируют тысячи MCP-серверов, открыто доступных из Интернета без должного контроля, а профильные организации — в частности OWASP в Top 10 for Agentic Applications — уже выделяют компрометацию цепочки поставок агентных инструментов в отдельную категорию риска.

Фактически возникает новая архитектура software supply chain. Машины создают изменения и выполняют первичный контроль. Человек управляет политиками, исключениями и критическими решениями.

Речь не идет о передаче ИИ полномочий принимать решения в критических системах. Наоборот, автоматизация должна освободить специалиста от рутинного сбора технического контекста и позволить сосредоточиться на оценке последствий для эксплуатации.

Для российских организаций этот глобальный процесс имеет дополнительное измерение. Open-source-экосистема остается мировой, но доступ к части зарубежных коммерческих сервисов, технической поддержки, threat intelligence и инструментов разработки может быть ограничен.

Возникает риск не только технологической зависимости, но и задержки технологического контекста. Организация может получить номер CVE, но позже узнать о практической эксплуатации. Может использовать международный open-source-проект, но не иметь гарантированного канала поддержки. Может получить новую версию компонента, но не располагать достаточной локальной экспертизой для быстрой оценки последствий миграции. Когда security-циклы измерялись кварталами, подобную задержку еще можно было частично компенсировать временем. При переходе отдельных контуров к месячному циклу этот резерв сокращается.

Для субъектов КИИ контроль open-source-компонентов становится не только задачей разработки, но и частью технологической устойчивости. Российский нормативный контур уже связывает эксплуатацию критических систем с технологической независимостью, российским программным обеспечением, доверенными программно-аппаратными комплексами и реагированием на компьютерные инциденты. Поэтому импортозамещение само по себе проблему не решает. Замена одного продукта другим не обеспечивает устойчивость, если организация по-прежнему не контролирует его зависимости, сроки поддержки и механизм выпуска исправлений.

Ответом не может быть отказ от глобального open source. Необходим собственный контур наблюдения за критическими технологиями. Если от Linux, Java, PostgreSQL, Kubernetes или другого базового компонента зависят значимые системы, организация должна понимать не только установленную сегодня версию. Необходимо отслеживать развитие upstream-проекта, сроки поддержки веток, изменение архитектуры, новые зависимости, релизную политику и существенные уязвимости.

Для критических компонентов такой мониторинг должен стать постоянной функцией — технологической разведкой в инженерном смысле. Ее задача состоит не в сборе максимального количества технологических новостей, а в раннем определении изменений, способных повлиять на используемый инфраструктурный контур. Это позволяет перейти от реактивной модели «вышло обновление — что теперь делать?» к управляемому жизненному циклу.

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

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

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

ИИ одновременно ускоряет обе стороны software supply chain. Он ускоряет производство open source и одновременно его потребление внутри компаний. Та же автоматизация снижает стоимость анализа исходного кода, поиска уязвимостей и масштабирования атак.

В результате основным показателем зрелости становится время от появления нового риска до управленческого решения. Где находится компонент? Какие системы затронуты? Насколько существенен риск? Можно ли обновиться? Как быстро проверить обновление? Какие компенсирующие меры применить? Кто принимает решение? Если ответы на эти вопросы требуют нескольких недель ручной работы, организация неизбежно будет проигрывать скорости программной экосистемы.

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

Для мировых компаний это означает автоматизацию software supply chain, постоянный SBOM, управляемые репозитории компонентов и risk-based vulnerability management. Для российских организаций к этому добавляется необходимость создавать собственный технологический контекст: локальную экспертизу, контролируемые репозитории, мониторинг upstream-проектов и возможность сопровождать критические компоненты независимо от доступности внешней поддержки.