Skip to main content
llmred-teamingcybersecurity

Одна цель, три LLM, разброс в 48 баллов

В авторизованном security-тесте три модели разошлись радикально: Kimi K3 получила 88/100 и 3 живых эксплойта, Claude Opus 4.8 остановилась на 70/100, а GPT-5.5 ушла в ложный сценарий и пришла к 40/100. Вывод простой: одной модели для таких проверок доверять нельзя.

Снаружи у всех паритет, внутри начинается лотерея

Самый важный факт тут неприятно простой: на одном и том же приложении в тот же день модели разошлись на 48 баллов в белом ящике. В исходном отчёте пользователя с тестовыми прогонами это выглядит очень жёстко: Kimi K3 получила 88/100, Claude Opus 4.8 70/100, GPT-5.5 40/100.

При этом во внешней разведке разницы почти не было. Все три модели выдали одинаковый набор: 7 находок, 0 CVE, 5 IP-адресов и 10 портов. То есть базовый recon уже правда стал commodity: сканер нашёл, модель пересказала.

А вот после выдачи доступа начался хаос. Kimi K3, по описанию автора прогона, сначала прочитала фронтенд, вытащила структуру API и прошлась по ней как по карте: 20 шагов, 20 находок, 3 живых эксплойта, 0 сбоев.

Claude Opus 4.8 выглядела стабильнее по поведению, но слабее по покрытию: 11 шагов, 2 находки, 0 сбоев. Подтвердила доступ, прочитала один источник данных и просто остановилась. Такое в red teaming особенно раздражает: формально модель не упала, а по сути недообследовала цель.

GPT-5.5, наоборот, двигалась дольше всех, но уехала не туда. В отчёте сказано, что модель рано решила, будто учётные данные не работают, к этому решению не вернулась, ушла в публичную поверхность и в итоге дала ложный вывод: 18 шагов, 8 находок, 3 сбоя.

Отдельно цепляет стоимость процесса. По тем же заметкам Kimi тратила около 23k токенов на одну находку, Claude около 280k. Если цифры записаны корректно, это не просто разница в цене, а разница в том, как модель вообще держит рабочую траекторию.

Почему это важно именно для практики

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

Я бы поэтому смотрел не на финальный severity, а на механику прогона: сколько было шагов, где модель застряла, возвращалась ли к гипотезам, что именно покрыла после логина. Низкий балл тут не равен безопасности. Он часто означает только одно: критичный путь не был доказан.

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

Из этого кейса я бы вынес очень приземлённое правило: authenticated testing нельзя сводить к одному агенту и одному вердикту. Снаружи LLM уже довольно ровные, а внутри приложения у них до сих пор слишком много случайности, чтобы путать молчание модели с отсутствием уязвимости.

Мы ранее рассматривали Augustus, автоматизированный сканер для red teaming, который помогает выявлять jailbreak и prompt injection в LLM. Его структурированный подход к оценке как раз и лежит в основе сравнительного скоринга безопасности, который мы сегодня исследуем.

Поделиться статьёй