Microsoft подвела итоги полугода поиска уязвимостей с помощью ИИ

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

В Microsoft работает лаборатория FORGE. Она занимается поиском уязвимостей с помощью ИИ-агентов. Руководит ей Тэсу Ким, профессор Georgia Tech, чья команда выиграла конкурс DARPA AI Cyber Challenge.

Что удалось сделать с мая по сентябрь 2026 года:
• 140 CVE в Windows, 52 из них закрыты в сентябрьском обновлении;
• 155 проверенных отчётов по 23 open-source проектам, включая Linux, curl, FFmpeg, Node.js, SQLite и llama.cpp;
• 93 отчёта мейнтейнеры уже подтвердили;
• один из отчётов стал первым патчем в ядре Linux, прошедшим через Akrites, инициативу Linux Foundation по согласованному раскрытию уязвимостей.

Авторы делают из этого три вывода.

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

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

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

Отдельно приведены расходы. В ядре Linux агенты собрали доказательства по 627 находкам. На 182 подтверждённых случаях генерация PoC стоила в среднем $3.61 и занимала около 21 минуты. Проверка возможности повышения привилегий обходилась примерно в $8.56 и 25 минут. Авторы считают, что дальнейшее удешевление заметно расширит круг находок, которые экономически имеет смысл проверять.

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

🔗Источник: Microsoft Security Blog, «3 lessons from frontier AI vulnerability research».

Если вдруг вы считаете себя сильным сесурити ресерчером, можете им заслать своё резюме))

🌚 @poxek_ai / Чат канала / 📲 MAX

Harness² от Google Research: агент правит свою обвязку без эталонных ответов

Harness² (arXiv:2610.14224) не трогает веса модели и правит восемь компонентов harness вокруг нее, от системного промпта и guardrails до skills и плагинов.

Шаг Propose–Probe–Compose предлагает правки, прогоняет кандидатов на той же задаче и собирает итоговый harness из различий в поведении запусков. Эталонные ответы не нужны. Принятые правки и выводы копятся в постоянном harness улучшений для следующих задач. По статье один шаг дает GLM-5 и Gemini 3.5 Flash до +11,5 пункта на WorkBuddy-Bench, +4,5 на JobBench и +11,8 п.п. частичного прохождения на LAB.

➡️Что придумали. Два приема.
• Сравнивать варианты между собой, а не с эталоном (Propose–Probe–Compose). Агент предлагает несколько правок своей обвязки и запускает каждый вариант на той же задаче. Потом смотрит, чем поведение отличалось: где один вариант проверил данные, а другой нет, где один застрял, а другой дошел до конца. Из удачных отличий он собирает итоговую обвязку. По сути это A/B-тест, где судья оценивает разницу в поведении, а не правильность ответа.
• Запоминать уроки между задачами. После каждой задачи удачная обвязка и выводы, подтвержденные этими сравнениями, сохраняются в отдельную «память об улучшениях». На следующей, уже другой задаче агент правит себя быстрее и точнее. Так улучшения не пропадают после одной задачи, а накапливаются.

Насколько это помогает. Один такой цикл добавляет GLM-5 и Gemini 3.5 Flash до 4,5–12 пунктов на трех бенчмарках с профессиональными задачами: офисная работа, юридические задачи, задачи по вакансиям. Если циклов больше, прирост растет.

🌚 @poxek_ai / Чат канала / 📲 MAX

Вторая LLM safeguard, перед основной моделью тоже ломается prompt injection. Это один из тезисов нового выпуска с Александром Кельчиным, CTO/CISO Medici Lab.

Схема «одна модель проверяет вход другой» упирается в две проблемы: обе модели рано или поздно галлюцинируют, и проверяющая читает тот же недоверенный текст, что и основная. Поэтому разбирали подходы, которые отделяют недоверенные данные от управления на уровне архитектуры: CaMeL и Dual LLM, плюс работу про внедрение CaMeL.

Что ещё в выпуске:
— свой SIEM с ИИ: события обрабатываются прямо на хостах агентом на 60 КБ, коллектор на двух ядрах CPU держал 150 хостов
— Qwen, дообученный под правила корреляции: модель получает около 200 токенов контекста, корректных ответов 96–97% (это внутренняя задача команды, не публичный бенчмарк)
— AI SOC: почему 60% правильно обработанных событий на L2 — плохой результат; рядом ExCyTIn-Bench про LLM-агентов в расследовании инцидентов
— поиск бэкдоров в весах моделей (DFBScanner) и LLM firewall против DLP
— кто размечает данные для ИИ

Тестовый разбора выпуска вы можете прочитать на Хабре (1 часть)

📺 YouTube | RuTube | VK Видео
🎧 Mave | Apple Podcasts | Яндекс Музыка — скоро

🌚 @poxek_ai / Чат канала / 📲 MAX / ❤️ merch.shop