Спонсоровано CloudMosa
Генеральний директор та засновник CloudMosa Шиоупін Шен зазначає, що значна частина витрат на безпеку браузерів у 2026 році була спрямована на вдосконалення контролю над Google Chrome. Однак ці вдосконалення не змінюють того факту, що механізм рендерингу Chrome продовжує виконувати неперевірений веб-код на пристроях працівників.
«Більшість корпоративних рішень для безпеки браузерів побудовані на тому ж коді Chromium, а інструменти на базі ШІ все прискорюють виявлення вразливостей у Chrome», — каже Шен. «Жоден постачальник не запропонував альтернативну архітектуру виконання, на яку могли б перейти підприємства у разі збою цього коду».
У першій половині 2026 року компанії здійснили низку поглинань: CrowdStrike придбала Seraphic, Zscaler — SquareX, а Akamai — LayerX. Ці угоди відбулися після купівлі Talon компанією Palo Alto Networks за 625 мільйонів доларів та оцінки Island у 4,85 мільярда доларів. Продукти, що були придбані, працюють через розширення, накладання політик, інструментарій часу виконання та вдосконалені збірки Chromium, але всі вони продовжують обробляти веб-контент безпосередньо на кінцевому пристрої.
Це становить як технічну, так і управлінську проблему. За словами Шена, придбання продуктів у різних постачальників приховує залежність від одного механізму, який жодне підприємство не контролює.
«Коли гігант падає, ви падаєте разом з ним», — пояснює він. «Chrome є міцною основою. Проблема в тому, що вся галузь будує на одній і тій же основі, не маючи реального плану Б».
Різке зростання кількості помилок безпеки Chrome до 1072 свідчить про ризики браузера
Команда безпеки Google Chrome повідомила наприкінці липня, що виправила 1072 помилки безпеки в оновленнях 149 та 150, що більше, ніж було виправлено за попередні 23 оновлення разом. Google пояснює це зростання впровадженням інструментів на базі ШІ для виявлення вразливостей та генерації виправлень, а також пілотним проєктом, який передбачає два випуски оновлень безпеки на тиждень. Компанія розглядає збільшення кількості виправлень як доказ того, що Chrome стає безпечнішим з кожним оновленням.
Хоча вдосконалені інструменти виявляють більше помилок, зростає занепокоєння щодо того, скільки дефектів ці інструменти продовжують виявляти. Механізм рендерингу браузера повинен обробляти та виконувати контент з усього інтернету, більша частина якого є неперевіреною. Тому, коли нове покоління сканерів раптом виявляє помилки зі значно вищою швидкістю, ніж раніше, виникає питання, скільки вразливого коду ці інструменти виявляють — і чи не можуть зловмисники, оснащені подібними можливостями, знайти його першими.
«Якби ці метрики відстежували концентрацію CO₂ замість програмних помилок, люди б не дивилися на криву і не казали, що все гаразд», — зауважує Шен. «Вони б запитали, про що нас попереджає ця крива».
Зловмисники отримують ті ж інструменти на базі ШІ, що значно скорочує час та експертизу, які раніше були потрібні для пошуку вразливостей у великій кодовій базі. Модель безпеки, яка працює лише тоді, коли захисники першими знаходять кожен дефект, стає все важчою для підтримки, оскільки обидві сторони прискорюються. Кожен продукт, побудований на основі Chrome, успадковує ризики, якщо виявлення помилок випереджає цикл виправлень Google.
Витрати на безпеку корпоративних браузерів знаходяться на один рівень вище
Інвестиції в безпеку корпоративних браузерів переважно поділяються на два напрямки: контроль над діями браузера та архітектура, що визначає, де виконується потенційно вразливий код. Виявлення загроз, фільтрація URL-адрес, запобігання витоку даних та дотримання політик посилюють перший напрямок. Однак вони, як правило, залишають середовище рендерингу браузера, що працює на кінцевому пристрої.
«Частину цих коштів слід витратити на зменшення кількості потенційно вразливого коду, який досягає пристрою, шляхом виявлення, виправлення та застосування політик поверх архітектури, розробленої для обмеження збитків у разі невдачі запобігання», — зазначає Шен. «Вибір полягає в тому, чи варто перевершувати конкурентів зі старою архітектурою, чи перехитрувати їх за допомогою нової».
Ізоляція браузера обмежує атаки нульового дня до випуску виправлення
У проміжок часу до того, як захисники напишуть сигнатуру або випустять виправлення, архітектура, яка утримує вразливий код поза пристроєм, обмежує те, що може отримати зловмисник від помилки, про яку ще ніхто не знає. CloudMosa дотримується такого підходу з Puffin Cloud Security, який виконує веб-контент віддалено, а не на кінцевому пристрої.
«Уявіть собі вразливий код як небезпечного в’язня», — каже Шен. «Перше запитання, яке ставлять люди: наскільки міцна в’язниця. Більш фундаментальне запитання: де ви будуєте в’язницю. Puffin Cloud Security розміщує в’язницю там, де в’язень не може дістатися до пристрою користувача, його даних чи програм».
Як працює архітектура розділеного браузера Puffin Cloud Security
Архітектура розділеного браузера Puffin існує з 2010 року і була використана більш ніж у 200 мільйонах завантажень. Спочатку вона була розроблена для вирішення проблеми продуктивності на пристроях з обмеженими ресурсами, а не для проблем безпеки браузера.
«Ми створили Puffin 15 років тому, тому що пристрої були занадто повільними», — каже Шен. «За 15 років ми зрозуміли, що та ж архітектура, яка вирішила проблему продуктивності, також забезпечує принципово інший рівень безпеки, який є критично важливим в епоху ШІ».
Puffin Cloud Security розділяє браузер між двома машинами. Компонент візуалізації відображення на пристрої виконує приблизно 5% роботи браузера. Рендеринг HTML, виконання скриптів та решта 95% виконуються на серверах CloudMosa. Коли користувач відкриває сайт, сторона в хмарі завантажує та рендерить сторінку та надсилає результат на пристрій, який відображає його на екрані. Стандартний браузер Chrome або вдосконалена збірка Chromium з додатковими засобами контролю виконують механізм рендерингу та код сторінки на кінцевому пристрої.
CloudMosa розробила клієнтський компонент як невеликий, захищений вузол з мінімальним кодом і невеликою кількістю функцій, на які може націлитись зловмисник. Рендерер у хмарі містить великий, багатофункціональний код, де концентруються вразливості браузера. Сервер надсилає відрендерений вивід клієнту у форматі на основі PostScript, і CloudMosa розробила цей обмін таким чином, щоб зловмисний код, що працює в хмарному рендерері, не мав прямого шляху для виконання на пристрої.
ШІ-агенти браузерів підвищують ставки для ізоляції браузера
ШІ-агенти змінюють модель безпеки браузера, оскільки вони не просто переглядають веб-контент, а й діють на нього. Браузерний агент може читати електронну пошту, працювати в додатках SaaS, надсилати форми та використовувати збережені облікові дані, часто переходячи між різними етапами без запиту дозволу від користувача на кожному кроці. Якщо зловмисник отримує контроль над цим середовищем, приз не обмежується лише сеансом браузера. Він може включати повноваження, які підприємство надало агенту.
Це робить ізоляцію між користувачами, агентами та окремими завданнями все більш важливою. Облікові дані, необхідні для одного завдання, не повинні залишатися доступними для наступного, а компрометація одного сеансу агента не повинна надавати зловмиснику постійний доступ до всього, що було авторизовано користувачем. Одноразові середовища виконання можуть обмежити масштаби розповсюдження компрометації.
Значна частина корпоративних обговорень щодо безпеки агентів зосереджена на дозволах: що агент повинен і не повинен робити. Але ці засоби контролю залежать від надійності середовища, яке їх застосовує. Оскільки агенти отримують все більше повноважень, Шен стверджує, що підприємства також повинні розглянути, де їхні браузери обробляють неперевірений веб-контент, з яким стикаються ці агенти.
«Політика може визначати, що агент може робити, але політика передбачає, що середовище, яке інтерпретує та застосовує ці правила, залишається надійним», — говорить він. «Якщо саме середовище виконання браузера скомпрометоване, зловмисник більше не є просто іншим користувачем, який повинен дотримуватися правил підприємства».
Оскільки ШІ-агенти отримують більше повноважень у браузері, підприємства мають більше ризиків, ніж просто перегони за пошуком та виправленням вразливостей. Вони також повинні вирішити, скільки неперевіреного коду взагалі має виконуватися на пристроях працівників. Шен стверджує, що це повертає на розгляд питання, яке здебільшого відсутнє в інвестиціях у безпеку браузерів: чи потрібна підприємствам альтернатива до домінуючої моделі виконання.
Спонсоровані статті — це контент, створений компанією, яка або платить за публікацію, або має ділові стосунки з VentureBeat, і вони завжди чітко позначені. Для отримання додаткової інформації звертайтесь за адресою [email protected].
За матеріалами: venturebeat.com