Bug bounty con un copilota di IA: il loop

Il bug bounty è test pagato dentro i confini che un programma stabilisce. Questa serie ti porta da zero al primo report valido, con un modello di IA che fa la lettura e le bozze mentre tu tieni il giudizio e tutto ciò che raggiunge un target. Questo primo post è il loop che ripeti su ogni programma. Il resto della serie approfondisce ogni fase e poi costruisce un piccolo agente che esegue parte del loop per te.

Un modello è un lettore veloce e un redattore discreto, senza memoria del tuo scope e senza niente da perdere sul tuo account. Riassume una policy, ordina una lista di endpoint, spiega una response strana e abbozza un report. Inventa anche un endpoint, legge male uno status code e suona sicuro mentre lo fa. Tratti il suo output come una pista, mai come un finding.

#Il loop

Il lavoro è un loop di cinque fasi. Lo esegui una volta su un programma, poi di nuovo sul target successivo, poi di nuovo sulla classe di bug successiva. Il modello aiuta in ogni fase. Non decide cosa è nello scope e non invia una request a un target al posto tuo.

Fase	Cosa fai tu	Dove aiuta il modello
Scegliere	Scegli un programma e un target	Riassume la policy, segnala clausole strane
Scope	Leggi cosa è dentro e cosa è fuori	Trasforma una policy lunga in una checklist breve
Recon	Mappi la superficie che puoi toccare	Ordina endpoint, legge JS, suggerisce parametri
Test	Invii request e leggi response	Spiega una response, propone il caso successivo
Report	Scrivi il testo	Abbozza i passi mentre tu verifichi ogni riga

#Scegli un programma e leggi lo scope

Un programma è un'offerta pubblica per testare target indicati sotto regole indicate. Prima di tutto leggi la policy per intero: i domini e le app nello scope, quelli fuori scope, le classi che non premia e i limiti di rate e di automazione. Incolla la policy in una chat e chiedi al modello di elencare host nello scope, host fuori scope e ogni regola che farebbe chiudere un report. Poi leggi la policy tu stesso, perché un riassunto sbagliato qui è il tipo di errore che chiude un account. Come scegliere il tuo primo programma spiega nel dettaglio come leggere uno scope.

#Recon senza toccare host fuori scope

Il recon mappa la superficie che il programma ti lascia testare. Raccogli sottodomini, endpoint e parametri, poi decidi dove un bug è probabile. Il modello serve per leggere, non per raggiungere: raggruppa una lista disordinata di endpoint, legge un bundle JavaScript minificato e indica i parametri che valgono un test. Tieni ogni scan e request sugli host che lo scope elenca. Per gli strumenti, il post sul toolkit prepara un terminale che ti tiene dentro lo scope.

#Testa, poi verifica prima di crederci

Il test è dove chi inizia perde tempo sui falsi positivi. Il modello dirà che una response sembra un IDOR o un XSS. A volte ha ragione. Confermi a mano: riproduci la request, cambi una cosa, osservi la response e tieni la request e la response esatte che lo provano. Un bug che non riproduci a comando non è ancora un bug. Testare i bug web comuni con l'aiuto dell'IA passa per IDOR, XSS, SSRF e auth rotta, compreso come evitare i falsi positivi che il modello ti consegna.

#Scrivi il report

Un report deve permettere a un estraneo di riprodurre il bug e capire l'impatto. Il modello abbozza bene dalle tue note: dagli la request, la response e l'effetto, e produce un testo pulito. Poi verifichi ogni passo, ogni URL e ogni affermazione sull'impatto, perché il triager lo farà. Scrivere report che vengono pagati ha la struttura e la checklist di revisione.

#Dove il modello è bravo, e dove mente

I modelli leggono veloce, traducono il gergo e tengono in moto un cervello stanco alle due di notte. Allucinano anche endpoint, gonfiano la severità per sembrare utili e confondono CVE simili. L'OWASP Top 10 per le applicazioni LLM cataloga questi modi di fallire. La regola che ti protegge è semplice: il modello propone, tu disponi. Niente di ciò che scrive raggiunge un programma prima che tu l'abbia riprodotto.

#A seguire in questa serie

Leggi come scegliere il tuo primo programma, poi prepara il toolkit e il terminale. Il caso d'uso del bug bounty e l'OWASP Web Security Testing Guide sono i due riferimenti che vale la pena tenere aperti tutto il tempo. I post successivi costruiscono un hackbot che esegue recon e test sulla tua macchina, sotto la tua approvazione, usando la NotHoly CLI.