GitHub modificherà dal 27 luglio 2026 la struttura del proprio bug bounty, riducendo i premi previsti dal programma pubblico e concentrando le ricompense più elevate in un livello VIP accessibile su invito. La revisione interviene mentre strumenti di scansione automatizzata e modelli di intelligenza artificiale consentono di generare un numero crescente di potenziali segnalazioni, molte delle quali risultano però speculative, duplicate o prive di una dimostrazione tecnica dell’impatto.
Nel programma pubblico, gli intervalli variabili saranno sostituiti da importi fissi associati alla gravità della vulnerabilità. Le falle classificate come basse riceveranno 250 dollari, quelle medie 2.000 dollari, quelle alte 5.000 dollari e quelle critiche 10.000 dollari. In precedenza, i premi partivano da 617 dollari per i problemi meno gravi e potevano superare i 30.000 dollari per una vulnerabilità critica. GitHub potrà comunque riconoscere bonus discrezionali nei casi in cui una ricerca presenti caratteristiche o conseguenze eccezionali.
Il nuovo livello VIP diventerà permanente e offrirà una tabella economica distinta: 1.000 dollari per le vulnerabilità basse, 7.500 per le medie, 20.000 per le alte e almeno 30.000 dollari per quelle critiche. I partecipanti selezionati potranno inoltre ottenere tempi di risposta più brevi, un rapporto diretto con il gruppo di sicurezza e accesso anticipato a prodotti o funzionalità ancora in fase di sviluppo. La struttura riprende precedenti iniziative private di GitHub, ma le trasforma in una componente stabile del programma.
Per diventare candidabili al livello VIP, i ricercatori dovranno aver prodotto almeno una segnalazione critica, due alte, quattro medie oppure sette basse. Il raggiungimento delle soglie non comporterà automaticamente l’ammissione, perché GitHub manterrà una valutazione qualitativa basata sull’affidabilità delle ricerche e sulla capacità di fornire risultati riproducibili. I criteri completi saranno pubblicati anche nella pagina del programma gestita attraverso HackerOne.
Cambieranno anche le condizioni di accesso al programma pubblico. GitHub introdurrà un requisito minimo collegato al Signal di HackerOne, l’indicatore che misura la qualità storica delle segnalazioni di un ricercatore. Chi non avrà ancora raggiunto il valore richiesto potrà presentare inizialmente fino a quattro rapporti, ottenendo quindi uno spazio limitato nel quale dimostrare l’attendibilità del proprio lavoro prima di accedere normalmente al programma.
La selezione non dipenderà dall’impiego o meno dell’intelligenza artificiale. GitHub ha precisato di accettare ricerche condotte con modelli linguistici, scanner automatici, analisi statica e altri strumenti, purché il risultato venga verificato dal ricercatore prima dell’invio. La responsabilità della segnalazione rimarrà quindi in capo alla persona che la presenta, indipendentemente dal sistema utilizzato per individuare il possibile difetto.
Ogni rapporto dovrà includere una prova di concetto funzionante, passaggi di riproduzione chiari e una dimostrazione dell’effettivo impatto sulla sicurezza. Non sarà sufficiente indicare che una determinata condizione potrebbe teoricamente causare un problema: il ricercatore dovrà mostrare quale barriera di sicurezza può essere superata e quale risultato concreto potrebbe ottenere un attaccante. Screenshot, richieste HTTP, output del terminale e altri elementi verificabili potranno essere utilizzati per documentare l’esecuzione.
GitHub chiede inoltre rapporti brevi e strutturati, privi di lunghe introduzioni, spiegazioni generiche o testi prodotti automaticamente che nascondano l’informazione rilevante. La forma richiesta comprende una sintesi del problema, le istruzioni necessarie per riprodurlo e una descrizione precisa delle conseguenze. L’obiettivo è ridurre il tempo impiegato dal gruppo di sicurezza per estrarre dai documenti il comportamento effettivamente vulnerabile.
Una parte delle segnalazioni viene esclusa perché interpreta come vulnerabilità comportamenti che ricadono nel modello di responsabilità condivisa della piattaforma. L’esecuzione di codice proveniente da un repository deliberatamente clonato, l’apertura di file controllati da un attaccante o l’analisi di contenuti non affidabili attraverso uno strumento di intelligenza artificiale non rappresentano automaticamente un aggiramento delle protezioni di GitHub. Per essere ammissibile, il rapporto deve dimostrare che il problema supera un controllo di sicurezza e colpisce l’utente senza dipendere soltanto dalla sua decisione di considerare attendibile un contenuto ostile.
Le segnalazioni valide che determinano esclusivamente una modifica di irrobustimento, una correzione documentale o un intervento privo di un impatto rilevante non riceveranno necessariamente un pagamento. In questi casi GitHub potrà riconoscere il contributo attraverso prodotti e materiale promozionale, riservando i premi monetari alle vulnerabilità concretamente sfruttabili e capaci di compromettere dati, account, infrastrutture o confini di autorizzazione.
La riorganizzazione modifica quindi anche gli incentivi economici del programma. La parte pubblica continuerà a consentire l’ingresso di nuovi ricercatori, ma con premi inferiori e limiti più severi per chi non dispone ancora di uno storico affidabile. Le ricompense maggiori saranno destinate a un gruppo ristretto che abbia già dimostrato di saper produrre segnalazioni ad alto impatto, riducendo il peso attribuito al numero complessivo di rapporti inviati.
L’intelligenza artificiale rimane ammessa come strumento di ricerca, ma non come sostituto della verifica tecnica. La capacità di generare rapidamente ipotesi, esaminare codice e costruire bozze di rapporto abbassa il costo iniziale dell’analisi, mentre la riproduzione dell’attacco, la comprensione del confine violato e la valutazione dell’impatto restano i passaggi che determinano l’ammissibilità della segnalazione e l’entità del premio.