Обновление программного обеспечения: почему растет число патчей

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

Отсюда и раздражение пользователей: почему программы часто обновляются, почему Windows требует перезагрузку в неподходящий момент, почему офисный пакет меняет номер сборки чаще, чем бухгалтерия закрывает месяц. Популярное объяснение — «разработчики стали писать хуже». Оно удобное, короткое и в целом бесполезное.

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

Обновление программного обеспечения перестало быть «улучшением функций». Всё чаще это операция по сокращению чужого времени до компрометации.

Patch Tuesday больше не выглядит исключением

В 2025 году Microsoft устранила от 1 130 до 1 275 CVE — разные подсчёты дают разные итоговые значения в зависимости от методики учёта. Среди них было 41 уязвимость нулевого дня; 24, по оценкам исследователей, уже применялись в реальных атаках. Это существенная цифра, но не повод записывать каждую запись CVE в готовый эксплойт.

CVE — идентификатор публично описанной уязвимости, а не приговор инфраструктуре. Часть дефектов требует локального доступа. Часть работает только в экзотической конфигурации. Для части нет публичного кода эксплуатации. Некоторые исправляются вместе с компонентом, который в конкретной компании вообще не используется.

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

Каталог CISA KEV — перечень уязвимостей, которые действительно замечены в эксплуатации, — пополнился в 2025 году 241 позицией. Это на 30% больше, чем годом ранее, когда добавили 186. И 39% новых записей относились к CVE 2024 года и более ранних периодов. Цифра особенно показательна: опасность не исчезает, когда заканчивается квартал или выходит новая версия продукта. Она лежит в среде годами, пока кто-то держит сервер на старой сборке, потому что «оно же работает».

Пользовательский интерфейс здесь почти ни при чём. Самые неприятные баги часто живут не в кнопках, а в парсере архивов, обработчике шрифтов, сетевом стеке, службе удалённого доступа или библиотеке, которую продукт получил через пять уровней зависимостей. Красивой иконки для такого исправления не будет. Будет номер KB, скучное описание и закрытая дыра, через которую вчера можно было запустить код от имени системы.

ИИ резко удешевил поиск ошибок

Количество зарегистрированных CVE в мире выросло с 40 009 в 2024 году до 48 196 в 2025-м. В среднем — около 132 новых записей в день. Это не означает, что каждое утро появляется 132 новых способов взломать компанию. Но означает, что поток найденных дефектов давно перерос ручной режим обработки.

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

Microsoft применяет мультимодельную систему MDASH для сканирования Windows. CISA использует модель Fable от Anthropic при проверке государственного программного обеспечения США. Публичного числа дефектов, найденных Fable, нет — и делать из отсутствующей цифры рекламную легенду не нужно. Сам факт внедрения таких систем важнее: вендоры получили возможность методично прочёсывать код, который раньше десятилетиями лежал под слоем предположений и старых тестов.

Механика выглядит так:

1. Модель или анализатор выделяет подозрительный участок. Например, обработчик входных данных, где длина буфера проверяется не на всех ветках исполнения, или привилегированная служба с неочевидным путём повышения прав.

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

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

4. Разработчик готовит патч. Здесь часто выясняется, что «маленькое исправление» ломает совместимость с древним драйвером, корпоративным макросом или внешним API.

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

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

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

CVE растут, а патчи не всегда выходят быстро

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

По данным Sonatype, частота релизов в открытом ПО за 2014–2023 годы выросла на 1 466%. Код выпускают быстрее, библиотек становится больше, зависимостей — ещё больше. При этом средний срок исправления уязвимостей низкой и средней критичности в 2024 году доходил до 500–700 и более дней. Картина неприятная, но логичная: разработчики завалены входящими задачами, а критические пожары съедают ресурс, который мог бы уйти на старые дефекты.

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

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

Цепочка поставки делает патчинг многослойным

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

Каждый слой добавляет риски:

• у основного продукта может быть актуальная версия, а у встроенного компонента — старая библиотека с известной CVE;
• обновление одной зависимости способно нарушить работу плагина, который никто не сопровождал с 2021 года;
• корпоративная сборка может блокировать штатный апдейтер и месяцами ждать ручной раскатки;
• репозиторий пакетов способен стать точкой компрометации, если контроль происхождения и подписи реализован формально;
• подрядчик может принести в продукт SDK, который расширяет сборку быстрее, чем служба безопасности успевает его инвентаризировать.

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

Самый опасный патч — не тот, что вышел с ошибкой. Самый опасный — тот, который одобрили, положили в план и не развернули.

Бумажная критичность и реальная эксплуатация — не одно и то же

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

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

Для ИТ-службы нормальная последовательность выглядит жёстко и без шаманства:

1. Сначала проверять активную эксплуатацию. Уязвимости из каталогов наподобие CISA KEV и подтверждённые атаки получают приоритет выше, чем просто громкий CVE.

2. Затем смотреть на внешнюю доступность. Почтовые шлюзы, VPN, веб-серверы, удалённое администрирование, системы идентификации и облачные консоли нельзя отправлять в бесконечную очередь согласования.

3. Сопоставлять CVE с реальным инвентарём. Если организация не знает точные версии Windows, офисных пакетов, браузеров, Java-рантаймов и сторонних утилит, у неё нет управления патчами. Есть надежда.

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

5. Фиксировать исключения по сроку. «Не обновляем, потому что может сломаться» — не решение. Нужны владелец риска, обоснование, временная защита и дата пересмотра. Иначе исключение становится постоянным бэкдором, согласованным на совещании.

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

При этом не стоит превращать ежемесячный релиз в русскую рулетку для рабочего контура. Массовая установка обновлений без тестирования — плохая практика. Но «мы не ставим патчи, пока кто-то другой не проверит» ещё хуже, если это означает месяцы ожидания. Нужны кольца развёртывания: пилотная группа, критичные, но контролируемые системы, затем основная масса устройств. Для серверов — подтверждённые резервные копии, план отката, проверка зависимых сервисов. Не героизм. Обычная инженерия.

Почему автообновление стало базовым механизмом защиты

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

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

Автообновления разумно включать для:

• браузеров и их движков;
• операционных систем на пользовательских устройствах;
• офисных пакетов, почтовых клиентов и средств совместной работы;
• средств удалённого доступа;
• антивирусов, EDR-агентов и компонентов защиты;
• популярных рантаймов и утилит, если они поддерживаются централизованно.

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

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

Патчей будет больше, а терпения — меньше

В 2025 году появилось 48 196 CVE. В июле 2026-го один Microsoft закрыл 570 уязвимостей за месяц. ИИ-системы ускоряют аудит, кодовые базы разрастаются, цепочки поставки усложняются. Оснований ждать, что поток исправлений внезапно сократится, нет.

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

Практический минимум для компаний выглядит безжалостно просто:

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

2. Завести полный инвентарь ПО и версий. Без него нельзя отличить закрытую CVE от красивого отчёта о закрытой CVE.

3. Разделить патчи по риску: активно эксплуатируемые и внешне доступные системы — вне очереди; остальное — по утверждённому циклу.

4. Создать тестовое кольцо и контролировать раскатку, а не проверять совместимость на рабочих местах бухгалтерии.

5. Убирать неподдерживаемые продукты из критичных процессов. Не «когда будет бюджет», а по плану с конкретной датой.

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

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