Por que usar a NotHoly para bug bounty

Um bug bounty roda em loop: recon, triagem, uma prova de conceito, um relatório que um triador consiga reproduzir. Duas coisas atrasam. Um modelo genérico recusa escrever a prova de conceito para um programa que paga exatamente por isso, e cada consulta de enriquecimento entra numa conta. A NotHoly tira as duas. O modelo aceita o loop, os dados de pesquisa não custam tokens, e a CLI mantém o trabalho na sua máquina e dentro do escopo do programa. O caso de uso de bug bounty tem a metodologia; aqui é sobre por que a ferramenta encaixa no loop.

#O loop, sem a recusa

O modelo lê a sua saída de recon e ordena o que parece alcançável, explica uma resposta com cheiro de IDOR ou SSRF, e escreve a prova de conceito para o endpoint que você pode testar. Ele não para para pesar se o pedido é permitido, porque o escopo do programa já respondeu isso. Com reasoning ligado, um passo de triagem percorre uma cadeia antes de ordenar, e o mesmo modelo rascunha a requisição que testa o próximo hop. Para um alvo web ele lê um bundle de JavaScript que você cola; para um alvo mobile você anexa o APK e recebe o manifest e as strings. A base de conhecimento traz metodologia de teste da OWASP e referências de payload com uma fonte em cada trecho, então uma técnica vem com onde conferir. Como o modelo é abliterated, uma prova de conceito que funciona para um endpoint no escopo volta como código, não como recusa, e você itera sobre ela na mesma conversa até um triador conseguir rodá-la.

#Fique dentro do escopo do programa

Um programa te dá um escopo e regras, e o notholy engage os transforma num guarda. Você registra os hosts e wildcards no escopo e aponta o --auth para a página do programa, e todo comando que o agente roda é checado contra esse escopo antes. Um host fora do escopo faz você digitá-lo e registra a exceção, então um acerto acidental num domínio irmão que não está no programa é pego antes de sair da sua máquina. As regras ficam fora do repo, então os arquivos do próprio alvo não ampliam o seu escopo. O log é um log.jsonl encadeado, um registro à prova de adulteração do que você tocou e quando, que é o registro que um programa ou uma disputa pede.

notholy engage init --name acme-bbp --scope "*.acme.com,api.acme.com" --auth "https://hackerone.com/acme"

#De um achado a um relatório

Um achado só é pago quando um triador consegue reproduzi-lo. Faça pipe das suas notas e da requisição no modelo e peça um texto com impacto, passos e uma correção sugerida, no formato que o programa quer. A CLI lê a entrada padrão, então um arquivo de notas, um export HAR ou um diff a alimentam direto, e --json numa consulta devolve dados estruturados que os seus scripts parseiam. Enriqueça o relatório com um lookup de CVE que carrega CVSS, EPSS e KEV, e uma consulta de advisory para a dependência que você suspeita, nenhum dos dois custa tokens. O preço pré-pago por token encaixa numa caçada que esquenta num fim de semana e fica parada por um mês, porque você paga o fim de semana.

cat finding.md | notholy "turn this into a reproducible report with impact, steps and a suggested fix"

#Onde não encaixa

O teste ativo é seu. Os servidores da NotHoly nunca escaneiam nem mandam tráfego a um alvo, então as requisições ao programa vêm das suas ferramentas, na sua máquina. Se um achado está no escopo, é válido ou é duplicado é decisão do programa, não do modelo, e o modelo pode errar, então reproduza a prova de conceito você mesmo antes de enviar. A conta precisa de um e-mail, e o chat guarda as suas conversas a menos que você abra uma efêmera.

Mantenha as requisições na sua máquina e deixe o modelo carregar a leitura e a escrita. Instale a CLI, ponha um saldo pequeno em preços, e rode um alvo para o qual você já tem escopo.