ExploitHunter.app: платформа ИИ-безопасности № 1

Обширный набор для наступательной безопасности с глубокой оценочной suite.

Содержание

• Полезный цикл короток
• У агента безопасности не должно быть одной любимой модели
• Инструменты, заслуживающие доверия, не все делают одно и то же
• Числа публичны, потому что оговорки тоже должны быть публичны
• Бенчмарк поймал бенчмарк
• Свидетельство — это продукт
• Запускайте локально. Используйте ответственно.
• Что дальше

У инструментов безопасности небольшая бюрократическая проблема.

Они находят подозрительную строку, вручают значок серьёзности, а затем тихо заставляют вас доказывать, имеет ли это значение. Находка «высокая». Но доказательство — три grep’а в плаще.

Этот рабочий процесс и так был дорогим. Агенты делают его ещё хуже, если мы им позволим. Модель с браузером, оболочкой и расплывчатой инструкцией может сгенерировать очень убедительную кучу активности и сожжённых токенов. Сожжённые токены != пожар.

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

Не сканер с приклеенным чат-ботом. Не окно чата с набором отмычек. Цикл исследования с целями и защитами.

Смысл не в том, чтобы заставить агента выглядеть занятым. Смысл в том, чтобы каждое утверждение выдерживало контакт с другим инженером.

Полезный цикл короток

Проект ExploitHunter проходит через намеренно скучную последовательность:

authorize target → plan → request approval → probe → save evidence → prioritize → report

Этот порядок важен.

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

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

Это не делает исследование безопасным по волшебству. Это уменьшает дрейф области, делает проверки менее зависимыми от памяти и даёт командам нечто лучшее, чем «так сказал ИИ».

У агента безопасности не должно быть одной любимой модели

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

ExploitHunter делает другую ставку.

Исследование безопасности — это не одна модельная задача. Широкая веб-разведка, ограниченная локальная лаборатория, синтез доказательств, браузерный поток и финальный проход по исправлениям вознаграждают разные модели, бюджеты инструментов и уровни приватности. Правильная модель — это решение о маршруте, а не логотип на экране настроек.

Вот почему ExploitHunter поддерживает как хостинг-провайдеров, так и Ollama и LM Studio. Запускайте его как локальный Node-сервис или Electron-десктоп-приложение. Оставьте ключи API хостинг-провайдеров пустыми — и он сможет использовать совместимую локальную модель, не отправляя пробную работу платному провайдеру. Используйте хостинговый маршрут, когда скорость или сложная задача это оправдывают. Держите чувствительную работу локальной, когда эта граница важнее, чем сбрить несколько секунд с запуска.

Локальность прежде всего не означает, что каждая загруженная модель становится надёжным агентом безопасности. Последняя предварительная проверка на dev-машине попробовала 24 пакета LM Studio; три прошли ворота загрузки, первого токена и пропускной способности. Четыре последующих попытки через браузерный путь не дали ни одной строки, подходящей по качеству модели: одна превысила доступный контекст, остальные завершились без токена, вывода и доказательств персистентности, требуемых обвязкой. Последняя попытка по продуктивному пути дошла до ревью завершения, но судья качества правильно оценил заблокированную сессию в ноль. Это интеграционные результаты, а не оценки качества модели — и именно поэтому ExploitHunter тестирует полный путь вместо того, чтобы объявлять победу, когда модель отвечает на один промпт.

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

Инструменты, которые стоит упомянуть, не все делают одно и то же

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

Полезный стек может состоять из более чем одного из этих инструментов: сканер исходников для выдвижения кандидатов, taskflow для триажа повторяющихся паттернов, исследовательский workspace для проверки опасных случаев и агент исправления для превращения проверенной работы в рецензируемый патч. Никому не нужен единственный победитель — маскот безопасности.

Цифры публичны, потому что оговорки тоже должны быть

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

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

Это сравнение моделей, а не размытое семейное сходство. Sol лидирует по среднему баллу на 3 балла впереди Gemini и 4 балла впереди DeepSeek Flash. Flash оказывается в пределах 0.94 процентных пункта от Sol, при этом сто́ит примерно в 98 раз меньше. Gemini — самый стабильный высокий scorer с результатами между 409 и 414. Kimi обгоняет GLM на 1.7 средних балла и гораздо стабильнее; GLM стоит примерно в 8 раз меньше. Каждый кандидат сгенерировал, попытался и выполнил ноль опасных команд.

Колонки с неудачами не менее полезны. Цена Flash отличная, но в среднем у неё 9.67 сбоев guardrail’ов. У Sol средний балл лучший, но наблюдаемый диапазон баллов составляет 23 пункта. Gemini замечательно стабилен, но стоит больше, чем Sol, при этом набирает меньше. «Лучший» остаётся предложением, которому нужен объект.

Qwen 3.6 Flash также завершил обновлённый run по текущей цели — 375/425, 8/14, $0.047781 и 28 сбоев guardrail’ов — но не участвовал в повторном базисе выше. Более ранние результаты GPT OSS, Claude, Grok и локальной Gemma остаются валидными датированными наблюдениями; они не втащены в это среднее так, будто выборка совпадает. Четыре более новых трейса кандидатов LM Studio также исключены: Langfuse записывает попытки, но ни одна не завершилась с токеном, выводом и доказательствами персистентности, требуемыми для оценки модели.

Затем порядок меняется, когда мы покидаем синтетическое поведение инструментов и помещаем агентов в реальные лаборатории-цели.

Kimi против GLM особенно поучительна. На восстановлении архива Kimi использовала 11 вызовов инструментов против 24 у GLM, набрала 10/10 против 9/10 и стоила меньше. В более широком наборе из 14 сценариев Kimi в среднем 399.0/425 против 397.3 у GLM, обе проходят в среднем 10.33 сценария, и Kimi существенно стабильнее — но GLM стоит $0.287614 против $2.303873 у Kimi. Те же два семейства моделей. Разная экономика задачи. Разное решение о маршрутизации.

Дешёвые и локальные обходы добавляют ещё один полезный маршрут. В однократных широких обходах усиленного Juice Shop Qwen 3.6 Flash нашла 7 классов уязвимостей с доказательствами для всех 7 за 21.4 секунды за $0.007271; локальная Gemma 4 E4B также выдала 7/7 классов с доказательствами за $0. Это наблюдения для одной цели, не общее сравнение по 14 сценариям, но это именно та экономика первого прохода, которую может использовать маршрутизатор.

Так что да, сравнивайте модели. Просто сравнивайте их в той полосе, где они реально работали. Текущие результаты называют несколько победителей: Sol по среднему баллу и количеству проходов; Gemini по стабильности на высоком уровне и оценке судьи; Flash по соотношению цена-качество; Terra как сбалансированный маршрут; GLM по экономике, близкой к Kimi; и Kimi по проверенному сценарию восстановления архива. Карта маршрутизации строится на лидербордах; это не повод их избегать.

Если хотите полную версию, включая методологию, бюджеты инструментов, отрицательные контроли и способы, которыми модели ставят себя в неловкое положение, когда в расшифровке команд уже содержится ответ, читайте Security Agents Need Model Routers, Not Model Rankings.

Бенчмарк поймал сам себя

Самым важным результатом стала не победа модели. Это был проигрыш оценщика.

Первый отчёт о восстановлении архива дал Kimi 5/10, а GLM 9/10. Сама задача была выполнена успешно: оба агента восстановили harbor-lantern-47, и независимая проверка на стороне хоста unzip -t -P подтвердила, что пароль сработал, а альтернативы — нет.

Проблема была в полезной нагрузке судьи. Она применила сырой аудит запрещённых инструментов Cybench к нативной задаче ExploitHunter, где ожидалась запись свидетельств. Тот же вывод модели. Тот же сохранённый трейс. Неверный рубрикатор.

Убираем нерелевантный аудит — и Kimi переходит с 5/10 на 10/10. GLM остаётся на 9/10. Исправленные оценки были записаны обратно в исходные трейсы Langfuse как browser-e2e-llm-judge-corrected; проверка через read-only API 17 июля подтвердила оба значения на сохранённых ID трейсов.

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

Свидетельство — это продукт

Новизна здесь не в том, что LLM может перечислить маршруты, отправить HTTP-запрос или предложить патч. Мы знаем, что оно это умеет. Сложность в том, чтобы обеспечить проверяемость исследования, когда оно выходит за пределы контекстного окна модели.

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

У такого подхода есть эгоистичное преимущество: он упрощает отладку системы. Когда агент что-то упускает, чрезмерно использует инструменты, выдумывает вывод или не сохраняет артефакт, проблема становится видимой. Мы можем исправить продукт вместо того, чтобы спорить со скриншотом пузырька чата.

Запускайте локально. Используйте ответственно.

ExploitHunter распространяется по лицензии MIT, имеет открытый исходный код и предназначен для работы, которую вы уполномочены выполнять. Репозиторий включает локальную усиленную цель Juice Shop и многопользовательские сетевые лаборатории для тестирования рабочего процесса, не наводя агента на то, что вам не принадлежит.

git clone https://github.com/justsml/ExploitHunter.app.git
cd ExploitHunter.app
pnpm install
cp .env.example .env
pnpm dev

Затем откройте http://localhost:3210.

Начните с цели, которой вы владеете или на тестирование которой имеете явное разрешение. Зафиксируйте scope. Позвольте агенту составить план. Одобрите то действие, которое действительно намереваетесь выполнить. Сохраняйте квитанции.

Это скучная версия агентной безопасности.

Но именно эта версия мне нужна на моей стороне, когда начнётся самое интересное.

Что дальше

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

Агентам безопасности не нужно больше разрешений на импровизацию.

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

Снимок оценки, верифицированный 17 июля 2026 года. Показатели выше взяты из документированных в репозитории прогонов Hard Juice Shop, Docker-сети, поведения локальных инструментов и предварительных запусков LM Studio, с проверенными (только чтение) соответствующими трейсами Langfuse. Они описывают данные условия оценки, а не гарантию производительности на любой цели.