OpenAI превращает 250‑человеческий спринт по безопасности в непрерывную фабрику ИИ-защиты

OpenAI сообщает, что привлекла более 250 сотрудников для поиска и устранения уязвимостей в сотнях своих систем, используя Codex и специализированные кибермодели для поддержки обнаружения, триажа, исправления и проверки. Теперь компания опубликовала архитектуру и рабочий процесс, выросшие из этого внутреннего спринта по безопасности, назвав получившуюся систему своей «Defense Factory».

Раскрытая информация содержит необычно конкретные операционные результаты. OpenAI сообщает, что команды закрыли 53 срочные или высокоприоритетные проблемы в первый день спринта, достигли 90,6% уровня принятия при маршрутизации находок владельцам, классифицировали 37% находок как дубликаты и снизили уровень ложноположительных результатов после динамической валидации до 0,81%.

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

1. Спринт по безопасности охватил более 100 сервисных областей

OpenAI описывает первоначальную работу как внутренний «code red», объединивший её подразделения Security, Applied и Research. В нём приняли участие более 250 человек, а работа охватила свыше 100 сервисных областей, включающих сотни систем.

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

OpenAI сообщает, что этот процесс обеспечил 90,6% уровень принятого владения. Рецензенты-люди продолжали разрешать неоднозначные случаи, пока срочные исправления выполнялись до завершения инвентаризации. Такой параллельный подход позволил командам закрыть 53 срочные или высокоприоритетные проблемы в первый день.

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

Дедупликация стала ещё одним явным контрольным барьером. OpenAI временно приостановила автоматическую маршрутизацию, пока этот процесс не улучшился, и в итоге определила, что 37% рассмотренных ею находок были дубликатами. Это важно, поскольку агентная система, которая лишь генерирует больше отчётов, может увеличить нагрузку на инженеров по безопасности, не снижая риск.

Динамическая валидация использовалась для отделения воспроизводимых уязвимостей от шума статического анализа. Агенты получали запускаемые версии выбранных сервисов и пытались воспроизвести предполагаемые проблемы в контролируемых средах. OpenAI сообщает о 0,81% уровне ложноположительных результатов после этого этапа, хотя не раскрывает размер или состав валидированной выборки.

2. Defense Factory использует пятиэтапный агентный цикл

Defense Factory представляется не как отдельная модель или сканер уязвимостей. Это эталонная архитектура, соединяющая существующие системы контроля исходного кода, сканеры безопасности, трекеры задач, среды разработки, специфичный для компании контекст и ИИ-агентов.

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

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

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

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

На заключительном этапе Codex готовит патч и проверяет его поведение в воспроизводимой среде. После человеческой проверки и авторизованного развёртывания отдельная проверка повторно тестирует исправление в продакшене. Смёрженный pull request или перемещённый тикет не считаются доказательством устранения; неудачная или неубедительная проверка оставляет проблему открытой.

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

3. Изоляция и контроль доступа входят в границу безопасности

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

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

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

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

Это различие особенно важно во время исправления. OpenAI сообщает, что агенты сгенерировали каждый патч в спринте, описывая исправление как «100% Codex-based», однако люди оставались ответственными за значимую проверку и авторизованное развёртывание. Заявленный уровень отката исправлений составил 0,53%, хотя компания не опубликовала исходное число патчей, представленное этим процентом.

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

4. Переносимый результат — это конвейер валидации, а не численность команды

Главный тезис OpenAI состоит в том, что защитники могут использовать приватный код, контекст развёртывания, записи о владельцах и более сильные передовые модели до того, как злоумышленники получат сопоставимый доступ. Её Defense Factory призвана превратить это преимущество в более короткие циклы между обнаружением и подтверждённым устранением.

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

Эта независимая реализация подтверждает базовый паттерн рабочего процесса, одновременно демонстрируя его издержки. Cloudflare сообщает, что крупные сканирования могут занимать часы, требовать пулов из 50–200 работников и переносить операционное узкое место с поиска дефектов на проверку и безопасное развёртывание исправлений. Непрерывная активность агентов не устраняет потребность во владельцах приложений, надёжных тестовых средах, инженерах релизов или экспертной оценке безопасности.

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

Доступ к базовым моделям также неоднороден. В опубликованной архитектуре OpenAI названы модели общего назначения, включая Astra, Sol, Terra и Luna, наряду с моделями безопасности Daybreak Blue и Daybreak Red. Более разрешительные кибервозможности предлагаются через Daybreak проверенным защитникам, с более строгой верификацией личности, контролем области применения, мониторингом и надзором.

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

Частые вопросы

Реагировала ли OpenAI на подтверждённый внешний взлом?

Нет. OpenAI описывает эту работу как внутренний спринт по безопасности и не утверждает, что анонс Defense Factory касается нового внешнего проникновения.

Что делает Defense Factory?

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

Развёртывали ли ИИ-агенты исправления без человеческого одобрения?

OpenAI сообщает, что Codex генерировал патчи, но значимые изменения оставались предметом человеческой проверки и авторизации развёртывания. Затем исправления в продакшене независимо повторно тестировались.

Сколько уязвимостей нашла OpenAI?

OpenAI не опубликовала общее число. Она сообщает о закрытии 53 срочных или высокоприоритетных проблем в первый день, но не раскрывает полное число или распределение находок по степени серьёзности.

Может ли любая организация использовать те же кибермодели?

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

Источники

• Оригинальный пост OpenAI в X
• OpenAI: Defense Factory
• OpenAI: Daybreak
• OpenAI: доверенный доступ для следующей эры киберзащиты
• Cloudflare: создайте собственную систему для работы с уязвимостями