Por que automatizar recon e teste na API da NotHoly

Uma rodada de recon produz mais do que você consegue ler: subdomínios, endpoints, cabeçalhos, versões, uma parede de saída de ferramenta. A parte lenta é a triagem, decidir o que merece um olhar mais perto. Um modelo no loop ajuda aí, mas só se ele não recusar o contexto de segurança e se os dados de apoio não transformarem cada consulta em uma cobrança. A API da NotHoly dá os dois. Este texto é sobre ligar isso ao seu fluxo, não sobre método de recon; o caso de uso de bug bounty cobre o fluxo em si.

#O modelo lê, o seu código toca

Mantenha a linha clara. O modelo raciocina sobre a saída que você já tem: ele lê um scan, ordena o que parece alcançável, rascunha o próximo passo, escreve o parser que você ia escrever. Os servidores da NotHoly nunca escaneiam, sondam nem mandam um payload a um alvo. A parte ativa, a requisição ao host no escopo, roda no seu ambiente, do seu endereço, sob o seu controle. Essa divisão é o ponto. Você ganha um modelo que discute o achado sem brigar sobre se é permitido, e o tráfego ao alvo continua seu para rodar e registrar. Resultados de ferramenta que você devolve são tratados como dado, não como instrução, então um banner hostil num scan não dirige a execução. Quando você roda o passo ativo no terminal, o notholy engage pode registrar o escopo e checar cada comando contra ele antes de rodar, e nada desse escopo sai da sua máquina.

#Dados que não custam tokens

A Research API responde às consultas que um loop de recon faz o tempo todo, e tem limite de taxa por organização em vez de medição por token. GET /v1/cve/{id} e GET /v1/cve/search devolvem a descrição do NVD, CVSS, CWE, nota EPSS e status CISA KEV em um registro, cada fonte datada. POST /v1/advisories/query devolve o que o OSV lista para um pacote e versão. GET /v1/kb/search lê uma base de conhecimento curada e licenciada com uma fonte em cada trecho. POST /v1/web/search e POST /v1/web/read buscam e leem páginas públicas por uma saída que recusa endereços privados e internos, fixa a conexão em um IP verificado e nunca manda tráfego a um alvo. Resultados de NVD, CISA, GitHub, PortSwigger e OWASP ficam no topo, e uma página pode estar errada, então abra a fonte antes de agir. Enriquecer um CVE ou checar uma versão não gasta tokens do modelo.

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

#Ligue ao pipeline

O endpoint do modelo é compatível com OpenAI e Anthropic, então o seu código de orquestração, as suas ferramentas de função e o seu streaming ficam como estão. Passe ao modelo as suas próprias ferramentas, deixe ele chamá-las e rode você mesmo: o servidor roda só as funções que você manda. O reasoning e o max_tokens seguem, então um passo de triagem pode pensar antes de ordenar. Uma requisição sem streaming com uma Idempotency-Key pode ser repetida e reexecutada por até 24 horas, o que ajuda um pipeline que roda de novo um passo. POST /v1/messages/count_tokens dimensiona um prompt antes de você gastar. Function calling tem a forma da requisição, e o ID do modelo vem do catálogo. Como as rotas de pesquisa não custam tokens, você enriquece uma fila inteira de achados e gasta só no raciocínio que os ordena.

#Onde não encaixa

Não encaixa se você quer que a plataforma rode o scan. Ela não roda. Não há execução no servidor nem ferramenta ativa, e read_url abre só páginas públicas, não um host interno nem um link que achou numa página. O modelo pode colocar um falso positivo no topo ou perder um real, então uma lista ordenada é uma fila para conferir, não um veredito. As rotas de pesquisa têm teto por minuto por organização, o que sobra para um pipeline e falta para um crawler em massa. Prompts e respostas ao modelo não são guardados, embora os metadados de cada chamada sejam.

Deixe seus scanners escanearem e o modelo ler. Ponha uma chave e um saldo pequeno em preços, e aponte o passo de triagem do seu pipeline para a API.