GPT-6 Cyber ставит в центр внимания границы проверки безопасности

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

5 ноября OpenAI представила GPT-6 Cyber и сообщила, что первоначальный доступ через API и Codex получили отдельные одобренные клиенты Daybreak Red. Компания описывает обучение модели поиску уязвимостей и соблюдению границ разрешённых проверок. Опубликованные результаты и сведения Mozilla об исправлениях в Firefox позволяют рассмотреть и сам поиск, и процесс выпуска, благодаря которому защита доходит до пользователей.

Здание в Сан-Франциско, где в июне 2025 года находилась штаб-квартира OpenAI. Контекстное фото Coolcaesar, кадрировано и уменьшено, CC BY 4.0. Источник изображения · Лицензия.

У полезной проверки есть границы, которые обеспечивают инструменты

Разрешённая проверка безопасности. Оригинальная иллюстрация Telli.sh.

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

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

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

Два вопроса тестирования требуют отдельных ответов

Показатель ExploitGym у OpenAI сравнивает результат проверки, где системе дана конкретная уязвимость для эксплуатации. Компания сообщила 48,5% для GPT-6 Cyber и 32,1% для GPT-5.6 Cyber. Разница в рамках этого теста составляет 16,4 процентного пункта. Отдельный тест в изолированной среде проверял, оставалась ли модель в границах задания.

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

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

У исправления Firefox есть окно распространения

Распространение патча. Оригинальная иллюстрация Telli.sh.

OpenAI сообщила, что модель помогла найти ранее неизвестные проблемы высокой серьёзности в Firefox, и сослалась на бюллетень Mozilla для Firefox 159. Бюллетень независимо подтверждает, что исправления вошли в эту версию. В нём указаны затронутые компоненты, серьёзность и сведения о выпуске. Числа и атрибуция модели в анонсе OpenAI относятся к исследовательской кампании самой компании.

Объяснение Mozilla от 29 октября о разрыве между выпуском и установкой патча показывает вторую половину работы. Если исправление уже видно, а значительная доля пользователей ещё его не установила, кто-то может вывести суть проблемы, изучив изменение. Появление правки в репозитории, доступность обновления и установка пользователями происходят в разное время. Команде безопасности нужно согласовать все три момента.

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

Сделайте комплект для проверки воспроизводимым

1. Письменно задайте системы, версии, данные и разрешённые действия. Работайте в среде, сетевой доступ и инструменты которой соответствуют этим границам.
2. Задайте модели точный вопрос, например воспроизводится ли сообщённая регрессия на затронутой тестовой сборке. Рабочие учётные данные и посторонние сервисы должны оставаться вне среды.
3. Попросите указать затронутый компонент, минимальный тест в разрешённой среде и признаки, по которым сообщённое поведение можно отличить от обычной ошибки.
4. Проверьте предложенное исправление на тесте и на существующем поведении. Попросите сопровождающего изучить правку и возможные побочные эффекты.
5. Зафиксируйте, что подтверждено, какие версии затронуты и как исправление дойдёт до пользователей. До раскрытия используйте закрытый канал проекта.
6. Отслеживайте выпуск и установку отдельно. После выхода обновления поддержка и эксплуатация могут помочь пользователям найти и установить исправленную версию.

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

Перепроверьте исправление регрессионным тестом

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

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

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

Используйте разные знаменатели для возможностей и соблюдения границ

По сообщению OpenAI, в кампании GPT-6 Cyber выявили 81 ранее неизвестную проблему, которую Mozilla относит к высокой серьёзности, и 30 пересмотров уровня серьёзности. Это данные OpenAI о собственной кампании. Бюллетень Mozilla для Firefox 159 документирует исправления и указание авторов в этом выпуске. Источники отвечают на разные вопросы и дополняют друг друга, потому что бюллетень называет конкретную выпущенную версию, которую можно проверить.

ExploitGym Honeypot от OpenAI отдельно оценивает соблюдение границ. В отчёте для описанных условий указаны 99,93% без специального промпта и 100% с промптом развёртывания. Эти цифры относятся к поведению в тесте поставщика. Их следует читать вместе с условиями и случаями сбоя. В рабочем окружении по-прежнему нужны сетевые ограничения, список разрешённых целей и проверка полномочий оператора. Отдельный показатель ExploitGym по возможностям сравнивает долю решённых технических задач.

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

Закройте отчёт, когда его могут проверить нужные люди

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

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

Проследите за исправленной сборкой до выпуска и установки

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

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

Учитывайте разрыв между выпуском и установкой, решая, какие доказательства публиковать и когда. Mozilla объясняет период риска между появлением видимого патча и установкой обновлений. Команда может хранить воспроизводимый материал в рамках утверждённой процедуры проверки, пока ответственные за выпуск готовят сборки и меры снижения риска. Назначьте время для повторной проверки установок и сообщите, что можно установить по данным.

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

Измеряйте время до проверенного исправления

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

Источники

• Доступ к модели GPT-6 Cyber через API

• Анонс GPT-6 Cyber от OpenAI от 5 ноября и карточка системы

• Бюллетень Mozilla об уязвимостях, исправленных в Firefox 159

• Объяснение Mozilla от 29 октября о разрыве между выпуском и установкой патча

---

Чтобы сохранять рабочие разговоры и решения и быстро находить их, создайте аккаунт Telli.sh.