Кибербезопасность

От обнаружения уязвимостей до их устранения: три урока лаборатории FORGE для исследований в области безопасности при поддержке ИИ

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

2026-10-07
5 мин. чтения
5 просмотров
certi.news Editorial Team
От обнаружения уязвимостей до их устранения: три урока лаборатории FORGE для исследований в области безопасности при поддержке ИИ

Microsoft сообщает, что лаборатория Frontier Offensive Research & Generative Exploitation, известная под сокращением FORGE, перешла от проверки способности искусственного интеллекта находить сложные уязвимости к изучению того, что необходимо для превращения этих находок в готовые к выпуску исправления. В период с мая по сентябрь 2026 года лаборатория помогла обнаружить уязвимости в Windows, которым были присвоены 140 идентификаторов CVE; 52 из них были устранены в рамках обновлений безопасности за сентябрь 2026 года.

Работа также распространилась на программное обеспечение с открытым исходным кодом: команды FORGE представили около 155 отчётов, прошедших внутреннюю проверку, по 23 проектам, включая ядро Linux. По данным Microsoft, на момент подготовки материала 93 отчёта по 14 проектам или семействам проектов получили подтверждение или документированное принятие со стороны сопровождающих. Кроме того, один из отчётов по Linux, представленных через инициативу Akrites фонда Linux, стал первым отчётом этой инициативы, завершившимся включением исправления в ядро Linux.

От максимальной способности к работе в широком масштабе

Первый урок заключается в том, что успех модели в обнаружении сложного дефекта не гарантирует выпуска исправлений с сопоставимой скоростью. Увеличение числа проверяющих может повысить количество кандидатов, но не обязательно увеличивает число подтверждённых результатов или опубликованных исправлений. Если отчёты поступают быстрее, чем Microsoft Security Response Center способен их проверять, образуется очередь, отнимающая время экспертов, особенно когда отчёты дублируются или не содержат воспроизводимых доказательств.

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

Расходы на устранение неопределённости, а не на увеличение объёма текста

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

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

Проверка и исправление как непрерывный цикл обучения

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

В эксперименте с ядром Linux агенты проверки создали подтверждающие доказательства для 627 результатов, а средняя стоимость создания концептуального доказательства для 182 подтверждённых сбоев составила 3,61 доллара модельных затрат и 21,5 минуты на каждый успешный случай. В шести случаях, где локальная возможность повышения привилегий проверялась посредством автоматической генерации эксплойта, средний показатель составил 8,56 доллара и 25,4 минуты. В оценках использовалась GPT-5.5; затраты на первоначальное сканирование, неудачные случаи, расследование человеком и подготовку исправлений не учитывались.

Что это означает для команд безопасности?

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

На практике источник указывает на изменение центра узкого места: способность находить дефект стала лишь частью проблемы, тогда как всё большее значение приобретает связь исследований со средами сборки, бинарными файлами, конфигурациями, инструментами тестирования и системами CI/CD. Ограничения результатов также очевидны: данные о стоимости проверки исключают важные этапы с участием людей, а превращение результатов исследования в приемлемое исправление зависит от сопровождающих и контекста каждого проекта. Поэтому материал не доказывает, что автоматизация заменяет инженерную проверку; напротив, она представлена как средство сокращения повторяющейся работы при сохранении ответственности за оценку безопасности и исправление за людьми.

Источник новости
c
Автор

certi.news Editorial Team

В той же категории

Вам также может понравиться

Все новости