Scegliere il tuo primo programma di bug bounty

Il programma che scegli decide se il tuo primo mese è produttivo o sprecato su target che non puoi testare. Questo post parla di leggere bene uno scope, con un modello di IA che fa la prima passata e tu che decidi. Segue il loop e alimenta la preparazione del toolkit.

#Cos'è un programma

Un programma di bug bounty è un'offerta pubblica. Un'organizzazione indica gli asset che vuole far testare, stabilisce le regole per testarli e fissa le ricompense per i report validi. La policy è il contratto. Tutto ciò che fai resta dentro ciò che elenca, e un report che esce fuori viene chiuso per quanto buono sia il bug. Alcuni siti pubblicano anche un file security.txt sotto /.well-known/security.txt con un contatto e un link alla policy, che ti dice dove vanno i report.

#Nello scope e fuori scope

Ogni policy divide il mondo in asset che puoi testare e asset che non puoi. Nello scope di solito c'è un insieme di domini, domini wildcard, app mobile o API. Fuori scope c'è il resto, e spesso include servizi di terzi che l'organizzazione usa ma non possiede. Per chi inizia la lista fuori scope conta più di quella nello scope, perché è lì che capitano gli incidenti. Un wildcard come *.example.com può comunque escludere host specifici, quindi leggi le due liste insieme.

#Le regole che fanno chiudere i report

Oltre alle liste di asset, una policy fissa le regole d'ingaggio: rate limit, se è permesso lo scanning automatico, quali classi di bug non vengono premiate e cosa puoi fare con i dati che raggiungi. Classi comunemente fuori scope per chi inizia sono il self-XSS, gli header di sicurezza mancanti senza exploit e i report da scanner automatici senza prova manuale. Le regole d'ingaggio nel bug bounty le spiega per intero.

#Leggi uno scope con il modello, poi controllalo

Incolla la policy in una chat e chiedi tre liste: asset nello scope, asset fuori scope e regole che farebbero chiudere un report. Il modello è bravo in questo lavoro di lettura. È anche capace di perdere un host o inventare una regola, quindi dopo leggi la policy tu stesso e correggi le sue liste. Qui il modello serve per la velocità su un compito noioso, non per un verdetto di cui ti fidi alla cieca.

Segnale	Adatto a chi inizia	Avvio più difficile
Dimensione dello scope	Pochi domini chiari	Grande parco di wildcard
Maturità	Programma nuovo, meno hunter	Programma maturo, già setacciato
Regole	Scanning permesso, classi chiare	Rate limit stretti, molte esclusioni
Target	Un'app web che puoi anche eseguire in locale	App hardware o solo native

#Scegli un asset che puoi davvero testare

Un programma può elencare dieci asset mentre solo due si adattano alle tue capacità. Da chi inizia, scegli un'applicazione web che puoi anche studiare sulla tua macchina, così impari il suo comportamento senza inviare traffico al target live per ogni domanda. Se il programma offre una build self-hosted o demo, eseguila in locale e tieni l'host live per confermare un bug. Così il conteggio delle request sul target reale resta basso, il che rispetta le regole di rate e lascia un registro più pulito.

#Registra lo scope prima di toccarlo

Scrivi lo scope da qualche parte dove i tuoi strumenti possano controllarlo, non solo nella tua memoria. La NotHoly CLI può tenere lo scope per una sessione con notholy engage, e legge il target da ogni comando prima che il comando parta, così un host fuori scope chiede una seconda conferma. Il post sul toolkit lo configura. Registrare lo scope trasforma una regola che devi ricordare in un controllo che il terminale fa per te.

#Scegliere la piattaforma

I programmi vivono su piattaforme di bounty e su pagine aziendali raggiunte tramite security.txt o una pagina /security. I programmi pubblici accettano chiunque. Quelli privati arrivano su invito dopo che ti sei costruito un registro. Parti dai pubblici, leggi qualche policy con il modello per farti un'idea di come differiscono e resta su un programma abbastanza a lungo da imparare bene la sua applicazione.

#A seguire in questa serie

Una volta che hai un programma e un asset, prepara il toolkit e il terminale. Tieni vicino l'OWASP Web Security Testing Guide e i termini di disclose.io come riferimenti per capire che aspetto ha il test condotto in buona fede.