Google взялась за самую скучную и потому самую опасную часть обновлений браузера: момент, когда патч уже вышел, а пользователь все еще не перезапустил Chrome. Компания хочет сократить это окно не только за счет более быстрого поиска багов, но и за счет обновлений, которые в части сценариев можно применять без полной перезагрузки браузера.
Для ИТ-команд это куда важнее красивых слов про ИИ. Реальный риск часто возникает не в день публикации исправления, а через день-два, когда патч уже доступен, но сотрудники продолжают работать в старой версии.
Google хочет сократить окно между выпуском патча и его применением
По данным 9to5Google и The Verge, Google описала подход, который внутри компании называют dynamic patching. Речь не о волшебной кнопке, а о попытке убрать обязательный полный рестарт Chrome в тех случаях, где это технически безопасно.
Идея опирается на многопроцессную архитектуру браузера. Вместо перезапуска всей сессии Chrome в будущем сможет подменять отдельные фоновые процессы, например Renderer или GPU, на обновленные версии. Для пользователя это почти незаметно. Для корпоративной безопасности выгода еще проще: меньше зависит от того, кто и когда нажмет «Перезапустить».
Пока это не готовая функция, а направление разработки. Но Google уже тестирует более мягкий сценарий. В Chrome 150 на macOS браузер автоматически перезапускается, если обновление уже скачано, а у пользователя не открыто ни одного окна. Для Mac это логично: приложение нередко продолжает висеть в фоне даже после закрытия всех окон.
Контекст здесь тоже понятный. Chrome 149 и 150 вместе принесли 1072 исправления безопасности и багов, и это больше, чем в предыдущих 23 крупных релизах Chrome вместе взятых. На этом фоне Google переводит браузер на двухнедельный цикл релизов с сентября 2026 года. Когда патчи выходят чаще, откладывать перезапуск становится еще дороже.
LLM уже встроены в поиск уязвимостей Chrome
Вторая часть истории интересна не меньше. Google использует большие языковые модели для поиска уязвимостей в кодовой базе Chrome с 2023 года, а в начале 2026 года собрала для этого отдельный агентный контур на базе Gemini и других моделей.
Задача системы проста на словах и неприятна по масштабу: просматривать огромную кодовую базу Chrome точнее и быстрее, чем это делают одни только люди и классические анализаторы. Один из показательных результатов, на который ссылается Google, это баг, проживший в коде 13 лет. Для проекта размера Chromium это не сенсация, а скорее напоминание, что технический долг любит долгую жизнь.
Google отдельно описывает и ограничения. Модели анализируют исходники в изолированной среде, без обычного доступа в интернет. Сетевые запросы режут по жестким спискам разрешений, а сами агенты не могут свободно менять локальную систему или читать файлы вне выделенных директорий с кодом.
Эта схема уже не выглядит лабораторной игрушкой. По данным Google, инструменты Big Sleep и CodeMender встроены в CI и проверяют наборы изменений регулярно. Только в мае 2026 года такие системы помогли остановить более 20 уязвимостей до попадания в рабочие сборки, включая как минимум одну критическую проблему уровня S1+.
Автоматизация дошла до фиксов и тестов
Google автоматизирует не только поиск, но и ремонт. После первичного анализа проблемы агент предлагает несколько вариантов исправления, затем отдельный критик оценивает их и отбрасывает слабые решения. Параллельно система готовит тесты и прогоняет их на поддерживаемых платформах Chrome еще до ревью человеком.
По сути, Google переносит в безопасность типичный инженерный цикл: найти баг, предложить патч, раскритиковать патч, проверить тестами и только потом нести его разработчику. Это уже не генерация отчетов ради галочки, а попытка встроить LLM прямо в secure development lifecycle.
Значение для рынка
Для русскоязычных ИТ-команд вывод довольно приземленный. Если Google доведет dynamic patching до рабочего состояния, безопасность браузера перестанет так сильно зависеть от дисциплины сотрудников. А история с LLM показывает другой сдвиг: крупные платформы начинают использовать модели не для презентаций, а для ежедневного поиска и исправления уязвимостей в реальном коде. Для вендоров браузеров, корпоративных ИБ-команд и разработчиков это плохая новость только в одном смысле: планка снова поднялась.
Следующий шаг теперь очевиден: Google будет одновременно ускорять выпуск патчей и убирать из процесса человека, который все еще надеется перезапустить браузер «чуть позже».
Источники: , , .