Il toolkit del bug bounty e la NotHoly CLI

Non ti serve un toolkit grande per iniziare. Ti servono un browser, un proxy, un terminale e un posto per tenere note ed evidenze. Questo post prepara quella lista breve e mette un modello di IA dove aiuta di più: nel terminale, a leggere l'output e a proporre il passo successivo, mentre ogni comando gira sulla tua macchina sotto la tua approvazione. Segue la scelta di un programma e porta a leggere il JavaScript con l'IA.

#La lista breve

Un browser e i suoi dev tools coprono una quantità sorprendente del lavoro iniziale. Un proxy come mitmproxy ti lascia osservare e modificare il traffico tra il browser e il target. Il terminale è dove vivono l'agente e gli scanner. Le note sono dove un finding diventa un report.

#La NotHoly CLI nel terminale

La NotHoly CLI esegue un agente nel tuo progetto. Può leggere e cercare file, eseguire un comando e chiamare strumenti di ricerca remoti, e per impostazione predefinita chiede prima di ogni scrittura e di ogni comando. Installala e accedi una volta.

curl -fsSL https://notholy.com/install.sh | sh
notholy login
notholy --version

Eseguila dentro una directory di lavoro per il programma. In modalità ask, quella predefinita, l'agente propone un comando e aspetta il tuo sì. In modalità plan legge soltanto. Parti in modalità plan mentre impari l'app.

notholy --mode plan -p "list the hosts and endpoints you can find in these notes"

Il modello non raggiunge mai un target dal lato di NotHoly. I comandi girano in locale, dal tuo indirizzo, con la tua approvazione. Questa è la proprietà che vuoi per il bug bounty: il traffico arriva da dove il programma se lo aspetta, e puoi registrare ogni request.

#Registra lo scope con notholy engage

Prima di testare, registra cosa il programma ti lascia toccare. notholy engage tiene lo scope per la sessione e controlla il target di ogni comando rispetto a esso.

notholy engage init --name acme-web --scope "*.example.com,api.example.com" --exclude vpn.example.com --until 2026-12-31
notholy engage status

Con un engagement attivo, l'agente legge l'host da ogni comando prima che parta. Un target nello scope passa per l'approvazione normale. Un target fuori scope ti fa digitare l'host tu stesso, e l'override viene scritto in un log locale. Il controllo legge il testo del comando e non risolve il DNS, quindi coglie i tuoi errori e non è una sandbox. Trasforma lo scope da qualcosa che devi ricordare in qualcosa che il terminale controlla.

#Un proxy per vedere ogni request

Punta il browser su un proxy locale e puoi leggere, mettere in pausa, modificare e rigiocare ogni request. È qui che avviene la maggior parte del test web. Quando una response sembra strana, copia la request grezza e chiedi al modello cosa significa e cosa cambiare dopo. La request modificata la mandi tu attraverso il proxy. Il proxy ti dà anche il testo esatto di request e response che a un report serve come evidenza.

#Tieni note ed evidenze dalla prima request

Apri un file di note per ogni programma prima di toccare qualsiasi cosa. Per ogni pista, salva la request, la response, l'orario e cosa ti aspettavi rispetto a cosa hai visto. Il modello può abbozzare da queste note più tardi, e delle buone note sono la differenza tra un report che paga e uno che il triager non riesce a riprodurre. Tieni le evidenze fuori da qualsiasi repository pubblico, e tieni i dati del cliente o del programma fuori dai servizi condivisi.

#Un piccolo home lab

Esegui l'app, o una sua build demo, sulla tua macchina così impari il suo comportamento senza inviare traffico al target live per ogni domanda. Come costruire un home lab legale prepara un ambiente isolato proprio per questo.

#A seguire in questa serie

Con il terminale, il proxy e lo scope a posto, passa a leggere il JavaScript con l'IA per trovare endpoint. L'OWASP Web Security Testing Guide è il riferimento per cosa testare una volta mappata la superficie.