Зачем автоматизировать recon и тесты на API NotHoly

Прогон recon выдаёт больше, чем вы прочитаете: поддомены, endpoint, заголовки, версии, стену вывода инструментов. Медленная часть это triage, решить, что стоит взгляда поближе. Модель в loop помогает тут, но только если она не отказывает в контексте безопасности и если вспомогательные данные не превращают каждый поиск в счёт. API NotHoly даёт и то, и другое. Этот текст о том, как её подключить, а не о методе recon; сценарий bug bounty покрывает сам поток.

#Модель читает, ваш код касается

Держите границу ясной. Модель рассуждает над выводом, который у вас уже есть: читает scan, ранжирует то, что выглядит достижимым, набрасывает следующий шаг, пишет парсер, который вы собирались писать. Серверы NotHoly никогда не сканируют, не зондируют и не шлют payload к цели. Активная часть, запрос к хосту в scope, идёт в вашей среде, с вашего адреса, под вашим контролем. Это разделение и есть суть. Вы получаете модель, которая обсудит находку, не споря, разрешена ли она, а трафик к цели остаётся вашим, чтобы запускать и логировать. Результаты инструментов, которые вы возвращаете, считаются данными, а не инструкциями, так что враждебный баннер в scan не рулит прогоном. Когда вы запускаете активный шаг из терминала, notholy engage может записать scope и проверять каждую команду по нему перед запуском, и ничто из этого scope не покидает вашу машину.

#Данные, которые не стоят токенов

Research API отвечает на поиски, которые loop recon делает постоянно, и ограничен по частоте на организацию, а не считается по токенам. GET /v1/cve/{id} и GET /v1/cve/search возвращают описание NVD, CVSS, CWE, оценку EPSS и статус CISA KEV в одной записи, каждый источник с датой. POST /v1/advisories/query возвращает то, что OSV перечисляет для пакета и версии. GET /v1/kb/search читает курируемую лицензированную базу знаний с источником на каждом фрагменте. POST /v1/web/search и POST /v1/web/read ищут и читают публичные страницы через выход, который отказывает приватным и внутренним адресам, пришпиливает соединение к проверенному IP и никогда не шлёт трафик к цели. Результаты из NVD, CISA, GitHub, PortSwigger и OWASP идут первыми, а страница может ошибаться, так что откройте источник перед действием. Обогащение CVE или проверка версии не тратит токены модели.

curl "https://api.notholy.com/v1/cve/search?q=openssh&kev=true&min_epss=0.5" \
  -H "Authorization: Bearer $NOTHOLY_API_KEY"

#Подключите к пайплайну

Endpoint модели совместим с OpenAI и Anthropic, так что ваш код оркестрации, ваши функциональные инструменты и ваш streaming остаются как есть. Передайте модели ваши инструменты, дайте ей их вызвать, и запускайте сами: сервер запускает только функции, которые вы шлёте. Reasoning и max_tokens проходят, так что шаг triage может подумать перед ранжированием. Запрос без streaming с Idempotency-Key можно повторить и воспроизвести до 24 часов, что помогает пайплайну, который перезапускает шаг. POST /v1/messages/count_tokens оценивает prompt до траты. Function calling содержит форму запроса, а ID модели берётся из каталога. Раз исследовательские маршруты не стоят токенов, вы обогащаете целую очередь находок и тратите только на рассуждение, которое их ранжирует.

#Где не подходит

Не подходит, если вы хотите, чтобы платформа запустила scan. Она не будет. Нет серверного выполнения и нет активных инструментов, а read_url открывает только публичные страницы, не внутренний хост и не ссылку, найденную на странице. Модель может поставить ложное срабатывание первым или пропустить настоящее, так что ранжированный список это очередь на проверку, а не приговор. Исследовательские маршруты ограничены в минуту на организацию, чего с запасом хватает пайплайну и мало массовому краулеру. Prompt и ответы модели не хранятся, хотя метаданные каждого вызова хранятся.

Пусть ваши scanner сканируют, а модель читает. Положите ключ и небольшой баланс на тарифы, и направьте шаг triage вашего пайплайна на API.