Perché usare NotHoly per il bug bounty

Un bug bounty gira in loop: recon, triage, una proof of concept, un report che un triager possa riprodurre. Due cose lo rallentano. Un modello generico rifiuta di scrivere la proof of concept per un programma che paga esattamente per quello, e ogni ricerca di arricchimento entra in un conto. NotHoly toglie entrambe. Il modello accetta il loop, i dati di ricerca non costano token, e la CLI tiene il lavoro sulla tua macchina e dentro lo scope del programma. Il caso d'uso di bug bounty ha la metodologia; qui si parla del perché lo strumento si adatta al loop.

#Il loop, senza il rifiuto

Il modello legge il tuo output di recon e ordina ciò che pare raggiungibile, spiega una risposta che sa di IDOR o SSRF, e scrive la proof of concept per l'endpoint che puoi testare. Non si ferma a pesare se la richiesta è permessa, perché lo scope del programma ha già risposto. Con il reasoning attivo, un passo di triage percorre una catena prima di ordinare, e lo stesso modello abbozza la richiesta che testa il prossimo hop. Per un bersaglio web legge un bundle JavaScript che incolli; per uno mobile alleghi l'APK e ricevi il manifest e le stringhe. La base di conoscenza porta metodologia di test OWASP e riferimenti di payload con una fonte su ogni passaggio, così una tecnica arriva con dove verificarla. Visto che il modello è abliterated, una proof of concept funzionante per un endpoint nello scope torna come codice, non come rifiuto, e la iteri nella stessa conversazione finché un triager non possa eseguirla.

#Resta dentro lo scope del programma

Un programma ti dà uno scope e regole, e notholy engage le trasforma in un guardiano. Registri gli host e i wildcard nello scope e punti --auth alla pagina del programma, e ogni comando che l'agente esegue è controllato contro quello scope prima. Un host fuori scope ti fa digitarlo e registra l'eccezione, così un colpo accidentale su un dominio fratello che non è nel programma viene preso prima di lasciare la tua macchina. Le regole stanno fuori dal repo, così i file del bersaglio stesso non allargano il tuo scope. Il log è un log.jsonl concatenato, un registro a prova di manomissione di ciò che hai toccato e quando, ed è il registro che un programma o una disputa chiede.

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

#Da un reperto a un report

Un reperto è pagato solo quando un triager può riprodurlo. Fai pipe delle tue note e della richiesta nel modello e chiedi un testo con impatto, passi e una correzione suggerita, nel formato che il programma vuole. La CLI legge lo standard input, così un file di note, un export HAR o un diff lo alimentano diretto, e --json su una ricerca restituisce dati strutturati che i tuoi script analizzano. Arricchisci il report con un lookup CVE che porta CVSS, EPSS e KEV, e una query advisory per la dipendenza che sospetti, nessuno dei due costa token. Il prezzo prepagato a token si adatta a una caccia che si scalda per un fine settimana e resta tranquilla un mese, perché paghi il fine settimana.

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

#Dove non si adatta

Il test attivo è tuo. I server di NotHoly non scansionano mai né mandano traffico a un bersaglio, quindi le richieste al programma vengono dai tuoi strumenti, sulla tua macchina. Se un reperto è nello scope, valido o un duplicato è decisione del programma, non del modello, e il modello può sbagliare, quindi riproduci la proof of concept da te prima di inviare. L'account ha bisogno di una e-mail, e la chat conserva le tue conversazioni a meno che tu non ne apra una effimera.

Tieni le richieste sulla tua macchina e lascia che il modello porti la lettura e la scrittura. Installa la CLI, aggiungi un saldo piccolo su prezzi, ed esegui un bersaglio per cui hai già lo scope.