Новость Google о безопасности Chrome хороша не потому, что AI якобы заменил инженеров. Она хороша потому, что показывает более приземлённую и полезную модель: AI как усилитель security-процесса внутри зрелой инженерной системы.

AI-assisted pipeline безопасности браузера со сканированием кода и выпуском patches

30 июля Chrome Security Team сообщила, что в milestones 149 и 150 исправлено 1,072 security bugs, больше, чем за предыдущие 23 milestones вместе. Google также пишет, что Big Sleep и CodeMender теперь каждые 24 часа работают в Chrome CI, а в мае заблокировали больше 20 vulnerabilities до production, включая critical S1+ issue.

Это конкретнее обычных рассказов об AI productivity, но к цифрам нужны оговорки. Google не опубликовала полную цену: false positives, reverts, regressions, объём ручной работы и изменения staffing. HN заметил это сразу: thread набрал 547 points и 576 comments, и значительная часть обсуждения была скептичной.

Что именно заявлено

Google описывает не разовый chatbot-трюк, а цепочку нескольких лет. В 2023 команда использовала LLMs для улучшения fuzzing coverage and performance. В 2024 вместе с Project Zero появился Naptime, где LLM получили инструменты для vulnerability research. В 2025 DeepMind и Project Zero работали над Big Sleep, AI vulnerability discovery agent для V8 и graphics stack.

В начале 2026 Chrome построил agent harness на Gemini для широкой проверки codebase. Один пример, по словам Google, был sandbox escape, проживший больше 13 лет и позволявший compromised renderer заставить browser читать local files. Harness использует model interoperability, knowledge base из прошлых CVEs и git history, SECURITY.md для trust boundaries, critic agent и repeated scans.

Важно не число само по себе, а структура. Это не "попросили модель защитить Chrome". Это pipeline: ограниченные задачи, богатый контекст, повторные прогоны, critics, CI, human review и старые security tools вокруг модели.

Почему это good tech news

Браузерная безопасность обычно невидима. Пользователь видит restart prompt или новость об exploit, когда что-то уже пошло плохо. Но browser — часть повседневной инфраструктуры. Если путь от discovery до fix короче, выигрывают домашние пользователи, школы, бизнес и госорганизации.

Google также хочет уменьшить patch gap: время после появления fix в open source code до момента, когда люди реально запускают обновлённый browser. Компания говорит о двухнедельном cadence для Chrome milestones, weekly security updates, пилоте two security releases per week и research в dynamic patching, чтобы менять background child processes без полного restart в большинстве случаев.

Это звучит скучно, пока не становится exploit window. Люди откладывают restart, потому что работают. Компании откладывают его из-за policy, testing и коммуникаций. Если Chrome уменьшит эту задержку, это практическое улучшение безопасности.

Где скепсис оправдан

HN задавал правильные вопросы: сколько automated fixes откатили, сколько новых bugs они создали, каков false positive rate, сколько результата объясняется тем, что менеджмент выделил больше людей на security.

Это не придирки. Именно эти метрики отделяют полезный AI pipeline от шумной фабрики сигналов. Найти тысячу подозрительных мест бесполезно, если инженеры потом неделями отклоняют большую часть. Исправить сотни bugs не победа, если часть fixes создаёт тонкие regressions.

Есть и vendor incentive. Google много вложила в AI и заинтересована показать, что Gemini и внутренние tools работают. Поэтому self-reported success story заслуживает и внимания, и давления. Нужны независимые сигналы: public CVEs, crash data, revert rates, external researcher feedback and exploit-in-the-wild trends.

Почему здесь AI выглядит зрелее

Плохие истории про AI coding часто начинаются с широкой задачи: построить app, сделать большой refactor, решить плохо описанную product problem. Security scanning уже. Его проще проверять tests, reproducers, severity rules, crashes and code review.

LLMs полезны как дорогие, упрямые linters с контекстом. Они могут проследить dependency, сравнить code path со старыми CVEs, набросать reproducer, объяснить boundary risk или предложить test. Но они всё ещё hallucinate, путают системное поведение и иногда чинят symptom instead of root cause.

Поэтому важны guardrails. Google пишет, что source analysis идёт at rest на locked-down machines без general internet access, network requests перехватываются и проверяются allowlists, unrestricted mode не используется, subagents не могут свободно менять system или читать файлы вне designated source directories.

Это главный урок для других команд: сначала клетка, контекст, узкие artifacts, review и измерения. Не автономная магия.

C++ никуда не исчез

AI headline не должен закрывать старую проблему: Chrome остаётся огромной C++ codebase, а многие browser bugs связаны с memory safety. Google отдельно говорит о MiraclePtr и MiracleObject против use-after-free, spanification против out-of-bounds, checked math, heap partitioning и Rust для замены участков с высокой плотностью bugs.

Сканер, который находит больше unsafe patterns, полезен. Архитектура, которая не даёт писать целый класс unsafe patterns, полезнее. Правильный вывод: большим unsafe codebases нужны fuzzing, AI-assisted analysis и постепенная миграция к safer primitives and languages одновременно.

Что взять другим командам

Начинайте с ограниченных задач: security triage, duplicate detection, severity metadata, dependency tracing, test suggestions, crash analysis and candidate patch review. Дайте модели реальную историю проекта: CVEs, bug tracker decisions, SECURITY.md, coding rules, known false positives.

Не выбрасывайте fuzzing. Google прямо пишет, что AI detection дополняет fuzzing, а не заменяет его. Fuzzers по-прежнему отлично находят bugs из странных последовательностей операций и дальних взаимодействий в коде.

Считайте неприятные метрики: false positives, rejected reports, reverts, regressions, review time and time from report to protected users. Если tool экономит часы, это можно показать. Если создаёт noise, это тоже нужно знать.

Для enterprise IT вывод простой: быстрые vendor fixes помогают только если fleet обновляется. Нужны version visibility, relaunch policies, понятный Extended Stable trade-off и контроль, что пользователи действительно переходят на защищённую версию.

Хорошая новость здесь не в том, что AI решил безопасность. Хорошая новость в том, что одна из самых сложных security-команд web нашла ограниченный, измеримый способ ускорить defenders. Это уже достаточно важно.