Исследования безопасности, которые раньше требовали отдельного и продолжительного расследования для каждой находки, все чаще могут выполняться как систематический процесс. В этом документе рассматривается одно из наших усилий в данной области.
Обнаружение уязвимостей становится проще масштабировать, однако их приоритезация и проверка остаются операционными узкими местами. Мы создали прототип для поиска уязвимостей безопасности в ядре Linux внутри контролируемой исследовательской среды. Наш прототип выявил и проанализировал 2308 кандидатов в уязвимости ядра Linux, динамически воспроизвел 1724 уязвимости и создал 948 эксплойтов для локального повышения привилегий (LPE), которые могут позволить непривилегированному локальному пользователю получить права суперпользователя.
Мы использовали эти данные для приоритизации уязвимостей при составлении отчетов и разработали предварительные патчи для рассмотрения мейнтейнерами. Следуя рекомендациям сообщества ядра Linux, мы начали с критических уязвимостей и работаем с партнерами из программы Patch the Planet над дальнейшими отчетами и патчами.
В июне, в рамках нашей инициативы Patch the Planet, мы сообщили, что GPT‑5.5 Cyber обнаружила уязвимости в ядре Linux и разработала 24 эксплойта для локального повышения привилегий с целью их проверки и составления отчетов. Мы расширили эту работу до конвейера, работающего на базе перспективной кибермодели, который охватывает обнаружение уязвимостей, динамическую проверку, оценку возможности эксплойта и создание патчей. По завершении его работы исследователи-люди изучили результаты и сообщили об обнаруженных уязвимостях вместе с патчами.
Почему ядро Linux
Ядро Linux лежит в основе устройств Android, облачной инфраструктуры, суперкомпьютеров и других систем, которыми пользуются миллиарды людей. Обладая более чем 40 миллионами строк кода, ядро представляет собой широкую поверхность атаки через системные вызовы, сети, файловые системы и драйверы устройств. Мы выбрали Linux, чтобы изучить, насколько эффективно передовые модели могут находить уязвимости и демонстрировать их влияние на безопасность в кодовой базе такого масштаба и важности.
Начальный этап обнаружения уязвимостей привел к появлению тысяч кандидатов в находки, что оказалось слишком большим количеством для ручного изучения и приоритизации исследователями безопасности. Операционной сложностью нашего конвейера обнаружения уязвимостей было не само обнаружение, а определение того, какие находки могут быть воспроизведены, какую границу безопасности они нарушают и какие заслуживают первоочередного внимания мейнтейнеров.
Анализ затрат
Миссия киберкоманды OpenAI — помогать обеспечивать безопасность программного обеспечения, на которое полагается мир. Мы публикуем затраты на API для каждого этапа, чтобы помочь исследователям оценить ресурсы, необходимые для воспроизведения и продолжения этой работы. Эти затраты отражают модели, целевые конфигурации и рабочий процесс, использованные в данной оценке. Наша более широкая цель — помочь защитникам находить и исправлять уязвимости, сокращая возможности для злоумышленников и повышая стоимость эксплуатации ими программного обеспечения.
Наконец, обратите внимание, что в данном исследовании мы сосредоточились на методологии и измерении возможностей модели, а не на стоимости. Мы ожидаем, что достаточная оптимизация обвязки может существенно снизить затраты на каждом этапе; таким образом, публикуемые нами затраты ближе к верхней границе.
Конвейер исследований уязвимостей
Наш прототип исследования уязвимостей представляет собой конвейер из пяти этапов, в основе которого лежит перспективная кибермодель:
- Обнаружение уязвимостей: Агенты определяют части кодовой базы, имеющие отношение к безопасности, и сканируют их на предмет потенциальных находок.
Обнаружение уязвимостей: Агенты определяют части кодовой базы, имеющие отношение к безопасности, и сканируют их на предмет потенциальных находок.
- Динамическая проверка: Агенты пытаются воспроизвести каждого кандидата в изолированной среде и сохраняют данные выполнения. Этот шаг выдает воспроизведенные и проверенные уязвимости.
Динамическая проверка: Агенты пытаются воспроизвести каждого кандидата в изолированной среде и сохраняют данные выполнения. Этот шаг выдает воспроизведенные и проверенные уязвимости.
- Оценка возможности эксплойта: Агенты проверяют, могут ли проверенные уязвимости привести к раскрытию информации или локальному повышению привилегий.
Оценка возможности эксплойта: Агенты проверяют, могут ли проверенные уязвимости привести к раскрытию информации или локальному повышению привилегий.
- Создание патчей: Агенты создают патчи, устраняющие каждую выявленную уязвимость.
Создание патчей: Агенты создают патчи, устраняющие каждую выявленную уязвимость.
- Проверка человеком: Исследователи безопасности изучают эксплойт, патч и предполагаемую степень критичности перед отправкой отчета мейнтейнерам.
Проверка человеком: Исследователи безопасности изучают эксплойт, патч и предполагаемую степень критичности перед отправкой отчета мейнтейнерам.
В конце конвейера система объединяет анализ первопричин, минимальный доказательный прототип сбоя, патч-кандидат и полноценный эксплойт, чтобы помочь исследователям-людям оценить серьезность уязвимости и передать исправления в вышестоящий проект.
Обнаружение уязвимостей
Далеко не каждая строка кода в ядре Linux имеет отношение к безопасности. Наш конвейер использовал группу агентов-разведчиков (Scout) для определения высокоприоритетных целей аудита, которые затем передавались агентам-аналитикам для сканирования на уязвимости.
Агенты-разведчики (Scout)
Агенты-разведчики просматривают каждую папку и файл и определяют цели для аудита на основе их достижимости (доступности для пользователей с низкими привилегиями) и значимости для безопасности.
На этом этапе было определено 5034 цели аудита, что составляет около 2,8 миллиона строк кода или примерно 7% от всей кодовой базы ядра Linux, что существенно снизило стоимость аудита безопасности по сравнению с анализом всей кодовой базы. Этот шаг обошелся в 3426 долларов США в виде кредитов API.
Агенты-аналитики
Затем агенты-аналитики проанализировали каждую цель аудита и сформировали кандидатов в находки, используя рабочий процесс, аналогичный плагину Codex Security plugin(opens in a new window). На высоком уровне агенты-аналитики читают код назначенной цели аудита, чтобы понять принцип его работы, определить модель угроз и найти в нем уязвимости.
В течение 12 часов агенты-аналитики сформировали 2308 кандидатов в уязвимости после дедупликации. Этот шаг обошелся в 316 549 долларов США в виде кредитов API.
Проверка уязвимостей
Кандидат в уязвимости — это еще не проверенная уязвимость. При таком масштабе ручное исследование каждого отчета непрактично для нашей исследовательской команды.
Поэтому мы сосредоточились на проверке находок, которые а) были доступны пользователю с низкими привилегиями, б) не требовали специальных возможностей и в) давали измеримые свидетельства повреждения памяти.
Для каждого кандидата агент триажа генерировал доказательство концепции и запускал его в изолированной виртуальной машине под управлением ядра Linux с включенным инструментом Kernel Address Sanitizer (KASAN). Агент отслеживал как вывод программы, так и системную консоль, после чего итеративно дорабатывал доказательство концепции до тех пор, пока оно не воспроизводило заявленное поведение или пока не исчерпывались возможные варианты его вызова.
В течение 30 часов наша система воспроизвела 1724 уязвимости — около 74,7% от 2308 кандидатов в уязвимости. Статический анализ кода сам по себе может быть подвержен ложноположительным срабатываниям, поэтому нас впечатлила точность агентов-аналитиков и эффективность агентов триажа, автономно создавших работающие доказательства концепции почти для трех четвертей кандидатов в уязвимости.
Большинство оставшихся результатов либо требовали повышенных привилегий, либо не воспроизводились в рамках отведенного времени из-за сложных гонок (race conditions), специфических условий срабатывания (например, обязательного сбоя выделения памяти на определенной строке) или трудоемкой валидации (например, переполнения счетчика ссылок). Только 3,1% отражали некорректный анализ со стороны модели, когда заявленная уязвимость предполагала невыполнимое условие.
Этап валидации обошелся в общей сложности в 73 330 долларов США в виде кредитов API. Мы заметили, что в нашем конвейере валидации, которому требовалось создать концепт-доказательство (PoC) для подтверждения того, что кандидат является реальной уязвимостью, этот процесс стоил дороже, чем вынесение рекомендаций только на основе статического анализа, причем затраты на попытки валидации истинных и ложных срабатываний были схожими. Таким образом, устранение ложноположительных результатов на более ранних этапах конвейера делает процесс значительно более экономически эффективным.
Оценка возможности эксплуатации
Валидация подтверждает, что уязвимость реальна, но не определяет, насколько срочно ее нужно устранить. Уязвимость, которая, например, может позволить повысить привилегии локального пользователя, имеет более высокий приоритет, чем та, которая может вызвать лишь локальный отказ в обслуживании. Имея 1 724 подтвержденные уязвимости, следующей задачей было выявить находки с наибольшим потенциальным влиянием на безопасность.
Первичный агент-фильтр выполнил статический анализ каждого отчета, журнала сбоев и соответствующего исходного кода. Он намеренно пропускал множество вариантов, чтобы не отбросить потенциально серьезные находки, и одновременно отсеивал случаи без правдоподобного пути эксплуатации. Это сузило результаты до 313 кандидатов на утечку информации и 1 238 кандидатов на повышение локальных привилегий.
Затем агенты разработки эксплойтов (ExploitDev) протестировали этих кандидатов в изолированных виртуальных машинах, настроенных с включенными средствами защиты стандартного дистрибутива Linux, включая предотвращение выполнения в режиме супервизора (SMEP), предотвращение доступа в режиме супервизора (SMAP), рандомизацию размещения пространства адресов ядра (KASLR) и HARDENED_USERCOPY. Это помогло предотвратить нереалистичные оценки, зависящие от отключенных средств защиты.
Агенты создали 291 концепт-доказательство для утечек информации и 1 169 работающих эксплойтов повышения локальных привилегий, которые могли предоставить непривилегированным локальным пользователям доступ рута (root).
Мы провели анализ вариантов (variant analysis) и разработали 948 уникальных патчей для уязвимостей, стоявших за этими эксплойтами. Мы используем это число для определения общего количества уникальных LPE. Создание успешных эксплойтов стоило в среднем 359 долларов США в виде кредитов. Это делает для защитников относительно недорогим тестирование возможности эксплуатации найденных уязвимостей.
Первичный агент скрининга уязвимостей обошелся в 44 194 доллара США в виде кредитов API. Этап эксплуатации обошелся в общей сложности в 775 929 долларов США в виде кредитов API: 84 929 долларов на обработку кандидатов на утечку информации и 691 000 долларов на кандидатов на повышение локальных привилегий.
В среднем обработка кандидата на повышение локальных привилегий (558 долларов) обходилась примерно в два раза дороже, чем обработка кандидата на утечку информации (271 доллар). Это объясняется тем, что PoC утечки информации переносились с этапа валидации и требовали меньше доработок для использования в эксплойте. С другой стороны, разработка эксплойта на основе кандидата LPE требовала множества дополнительных шагов, таких как планирование стратегии эксплуатации, определение уязвимых объектов для использования, обход механизмов защиты и многое другое. Мы также заметили, что неуспешные попытки эксплуатации (3 922 доллара за 69 случаев) стоили значительно дороже успешных (360 долларов за 1 169 случаев). Это было вызвано несколькими сложными для эксплуатации уязвимостями (например, гонками). Определение разумного условия прекращения работы, такого как остановка попытки при отсутствии прогресса в течение одного часа, значительно снизило бы стоимость ExploitDev.
Генерация патчей
Для каждой подтвержденной уязвимости система также генерирует патч. Мы предоставляем модели соответствующий исходный код и предлагаем лучшие практики написания патчей, такие как выполнение статического контроля патча, соблюдение практик разработки программного обеспечения, используемых в соседнем коде, и проведение анализа вариантов для обеспечения полноты патча.
Следуя предложению сообщества ядра Linux, мы уже разослали сотни отчетов и патчей для критических уязвимостей и работаем с партнерами Patch the Planet над постепенной рассылкой патчей для остальных. Эта работа является частью нашего более широкого обязательства Daybreak по поддержке проектов с открытым исходным кодом.
Результаты
В этом разделе мы делимся выводами, размышлениями и дополнительным анализом данного исследования.
Мэйнтейнеры быстро устраняют уязвимости
В ходе этого исследования мы наблюдали, как мэйнтейнеры Linux быстро исправляют уязвимости и защищают пользователей. Сканирование проводилось на последней версии ядра Linux в середине октября 2026 года. Когда автономное сканирование и ручной анализ завершились через 10 дней, 61 уязвимость LPE уже была исправлена в основной ветке (upstream), 43 имели черновые патчи (staging), а 299 находились на стадии публичного обсуждения и репорта.
Мы выражаем огромную благодарность мэйнтейнерам Linux, которые срочно работали над исправлением выявленных проблем, а также широкому сообществу безопасности за вклад в виде найденных уязвимостей. Такой коллективный отклик — это именно то, что необходимо для обеспечения безопасности мирового программного обеспечения. Высокая скорость раскрытия уязвимостей и выпуска патчей также подчеркивает критическую важность сво обновления программного обеспечения для пользователей и компаний.
Вывод: Автоматизированная триажировка должна учитывать быстрый цикл выпуска патчей. Повторная валидация результатов на основе актуального кода, включая новый код, объединенный после первоначального сканирования, помогает избежать дублирования или устаревания отчетов. Это позволяет сосредоточить внимание на нерешенных уязвимостях и предоставляет мэйнтейнерам готовые к действию доказательства без создания дополнительной нагрузки при ревью.
Более мощные модели находят больше уязвимостей
Пока мы разрабатывали конвейер, в конце июля 2026 года модель GPT-5.6 Sol нашла и проэксплоятировала 166 уникальных уязвимостей LPE, потратив на это в общей сложности 513 690 долларов США в кредитах API.
Во время второго сканирования в середине октября 2026 года более новая кибермодель нашла и проэксплоятировала 948 уникальных уязвимостей LPE при общих затратах в 1 213 430 долларов США в кредитах API. Для обеих кампаний мы сканировали последнюю на тот момент мастер-ветку ядра Linux.
Вывод: Повторно сканируйте ранее проверенный код по мере совершенствования возможностей моделей. Более способная модель может обнаружить уязвимости, пропущенные предыдущими моделями, даже при использовании того же исследовательского инструментария.
Новые методы эксплуатации
Мы взяли выборку из 166 эксплойтов, созданных агентами, и проанализировали использованные в них методы эксплуатации. Насколько нам известно, в выбранных эксплойтах агенты использовали 10 новых методов эксплуатации. Мы поделились этими методами со сторонними экспертами по эксплуатации ядра, и для них они также оказались новыми.
Из 10 техник две являются новыми постоянными эластичными объектами, которые модель использовала для распыления объектов в кэше целевого ядра; две представляют собой новые методы очистки страниц для повышения надежности эксплойта; пять являются новыми методами только для работы с данными с целью получения повышения привилегий напрямую или посредством произвольной записи; еще одна техника связана с произвольным смешением типов. В целях безопасности мы воздерживаемся от публикации полных технических деталей этих новых методов эксплуатации в данной статье.
Вывод: Фронтир-модели не просто сопоставляют шаблоны известных уязвимых кодов или используют исключительно известные методы эксплуатации; они демонстрируют креативность и новые подходы.
Чему защитники могут научиться на стоимости эксплойтов
Важной частью миссии нашей команды является оценка стоимости поиска и эксплуатации уязвимостей, а также использование этих данных для руководства инвестициями в безопасность. Наша цель — помочь защитникам устранить уязвимости до того, как их смогут использовать злоумышленники, и сделать эксплуатацию программного обеспечения экономически нецелесообразной для атакующих. Измерение затрат на эксплуатацию помогает нам оценить, как меняется эта задача по мере совершенствования возможностей моделей. В этом разделе мы сравниваем стоимость запуска нашего конвейера с вознаграждениями программ Bug Bounty за выявленные уязвимости.
Целевые виртуальные машины в нашем эксперименте работали под управлением стандартной десктопной операционной системы без ослабленной защиты в рамках той же модели угроз, которая используется в соревнованиях по кибербезопасности (например, Pwn2Own(opens in a new window), TyphoonPWN(opens in a new window)). Исторически Pwn2Own и TyphoonPWN предлагали вознаграждения в размере 20 000 и 70 000 долларов соответственно за эксплойты локального повышения привилегий в ядре Linux. Применение этих исторических сумм вознаграждений к 948 эксплойтам дает гипотетическую оценку в 18,9 млн — 66,3 млн долларов, что примерно в 16–55 раз превышает стоимость нашего конвейера.
Мы также протестировали наш конвейер на программе вознаграждений за уязвимости kernelCTF(opens in a new window) от Google, в которой в качестве цели используется закаленное ядро Linux с уменьшенной поверхностью атаки. Мы запустили конвейер на последней версии ядра Linux (несовместимой с механизмом защиты SLAB_VIRTUAL в kernelCTF, поэтому мы исключили его из конфигурации) в среде kernelCTF и получили 25 доказательств концепции утечки информации и 21 эксплойт локального повышения привилегий. Для сравнения, на момент написания статьи в 2026 году компания kernelCTF приняла 26 подтвержденных 0-day эксплойтов LPE. Вся кампания длилась в общей сложности 112 часов и обошлась примерно в 32 936 долларов США в виде кредитов API, причем на обнаружение уязвимостей пришлось 83,7% затрат на API. Если бы эти 21 уязвимость были приняты программой, это привело бы к выплате вознаграждения примерно в 1,5 млн долларов, что примерно в 45 раз превышает затраты.
Вывод: Судя по публичным суммам выплат, при использовании текущих моделей с кибервозможностями наш конвейер исследования уязвимостей окупился на момент проведения данного исследования. Защитникам следует заблаговременно анализировать свое программное обеспечение, чтобы эксплуатация со стороны злоумышленников стала экономически нецелесообразной.
Использование не того 0-day
Во время оценки возможности эксплуатации агентам ExploitDev был предоставлен отчет об уязвимости с задачей создания полноценного эксплойта. Наш конвейер отмечал уязвимость как успешно проэксплуатированную, если удавалось получить root-оболочку. Во время одного из ранних запусков этап эксплуатации сообщил о 200 успешных эксплойтах локального повышения привилегий. Однако после экспертной проверки мы обнаружили, что в 20 случаях права root были получены не через назначенную, а через другую 0-day уязвимость. Это говорит о том, что даже успешная эксплуатация агентами требует надлежащей проверки.
Впоследствии мы ужесточили ограничения задач и добавили независимую проверку, подтверждающую, что каждый финальный эксплойт использовал назначенную ему уязвимость.
Вывод: При автономных исследованиях безопасности проверяйте путь к результату в дополнение к проверке самого результата; изоляция, мониторинг и независимые проверки являются необходимыми элементами контроля.
Более мощные модели могут требовать меньшей оркестрации
В начале этого исследования мы изучали проектное решение о том, стоит ли выстраивать сложную оркестрацию вокруг агента для повышения его кибервозможностей. Наш результат показал, что более сильные модели требуют меньшей оркестрации и опеки. При этом незначительное улучшение не оправдывает затрат на обслуживание. В результате мы решили отказаться от тяжелой оркестрации.
В эксперименте сравнивались GPT‑5.5 Cyber и GPT‑5.6 Cyber. По нашим наблюдениям, GPT‑5.5 Cyber не всегда стабильно определяла, когда и как применять существующие методы эксплуатации ядра Linux. Затем мы собрали 103 метода в удобном для модели формате, сделали их доступными в среде агента и дали модели подсказку использовать их. Среди 63 кандидатов на эксплуатацию это увеличило показатель успешности с 76,2% до 88,9%.
Когда мы повторили это с GPT‑5.6 Cyber, модель лучше справлялась с поиском, выбором и применением соответствующих методов самостоятельно. Мы удалили оркестрацию методов/навыков, и этот слабо оркестрированный рабочий процесс GPT‑5.6 Cyber превзошел более сложный рабочий процесс GPT‑5.5 Cyber. Добавление дополнительного уровня методов для GPT‑5.6 Cyber обеспечило лишь незначительное улучшение на 1,5 процентных пункта.
Вывод: Переоценивайте свою оркестрацию и вспомогательные средства по мере изменения возможностей базовых моделей. Обвязка, которая существенно улучшает одно поколение моделей, может приносить мало пользы для более сильной модели, поэтому ее следует оценивать с точки зрения затрат на обслуживание.
Итерации улучшают создание патчей
Изначально при прямой подсказке сгенерировать патчи-кандидаты модель создавала функционально правильные патчи, которые устраняли доказательство концепции, но порой приводили к другим проблемам: избыточный код, потенциальное ухудшение производительности, отклонение от стандартов кодирования или отсутствие проверки связанного кода на наличие вариантов той же уязвимости, что вело к неполным патчам.
Дополнительные инструкции и итерации процесса создания патчей позволили улучшить их качество, что говорит о том, что при правильном подходе создаваемые ИИ патчи безопасности могут быть корректными, минимальными и соответствовать существующим стандартам кодирования. Это активно развивающаяся область исследований, и мы верим, что с будущими моделями этот процесс станет проще и эффективнее. В ряде случаев наш исследовательский прототип также смог выявить проблемы в патчах, написанных людьми-экспертами, которые затем были исправлены до объединения веток кода.
Вывод: Модели могут ускорить процесс создания патчей, однако навыки и средства патчинга могут потребовать итераций для обеспечения надежного соответствия патчей как функциональным, так и нефункциональным требованиям. Кроме того, мы рекомендуем использовать модели для состязательного ревью патчей, созданных как людьми, так и ИИ, что позволяет выявлять такие проблемы, как возможность обхода патча, упущение других путей атак или вариантов уязвимостей и многое другое.
Уязвимости в инфраструктуре тестирования
В ходе нашего выступления на kernelCTF, помимо 21 эксплойта нулевого дня для ядра Linux, наш исследовательский прототип также обнаружил и использовал уязвимость в QEMU TCG. Агент-аналитик получил задачу проанализировать код входа в системные вызовы, и при написании программ для экспериментов с переходами привилегий он столкнулся с неожиданным сбоем ядра. Он выполнил триаж сбоя, отследил проблему до QEMU TCG без доступа к исходному коду QEMU и включил уязвимость в отчет. Агент ExploitDev впоследствии успешно разработал эксплойт для локального повышения привилегий на основе этой уязвимости. Мы обнаружили эту уязвимость в QEMU при ручном анализе эксплойтов и подтвердили, что она была исправлена в актуальной версии QEMU (upstream), но не в релизной сборке, использовавшейся во время эксперимента.
Вывод: передовые модели с возможностями в сфере кибербезопасности способны находить уязвимости в тестовой инфраструктуре. Мы рекомендуем тестировать каждую часть инфраструктуры перед проведением наступательных исследований уязвимостей. Мы у проактивно протестировали нашу инфраструктуру, обнаружив и устранив множество уязвимостей в Kata, Moby/Docker, gVisor и других проектах.
Заключение
Наша цель — превратить растущие возможности моделей в долгосрочное преимущество для специалистов, обеспечивающих безопасность интернета. Данное исследование демонстрирует, что растущие кибервозможности передовых моделей могут эффективно использоваться для поиска уязвимостей в сложном программном обеспечении, таком как ядро Linux. Укрепление критически важных программных проектов, включая Linux и другие проекты с открытым исходным кодом, позволяет защитить множество нижестоящих систем и пользователей.
С помощью инициативы Patch the Planet от Daybreak мы стремимся распространить это исследование на большее число критически важных программных проектов и разработать надежное автоматизированное исправление совместно с мейнтейнерами и партнерами по безопасности. Мы хотим неуклонно сокращать возможности, доступные злоумышленникам, и повышать стоимость поиска и эксплуатации уязвимостей до тех пор, пока ожидаемая выгода перестанет оправдывать атаку.
Каждое поколение моделей должно помогать нам создавать программное обеспечение, взломать которое для следующего поколения станет еще сложнее. Мы продолжим работать над созданием безопасного интернета, на базе которого каждый сможет с радостью созидать.
