Vai al contenuto
New

DeepSeek V4.1 Flash free for 7 days: 10M tokens a day after a top-up of $10 or more. Until Nov 30.

How it works

Scrivere report di bug bounty con l'IA

Trasforma le note in un report che un triager può riprodurre, con l'IA che abbozza dalle tue evidenze e tu che verifichi ogni riga prima di inviare.

Base3 min di letturaDi NotHoly

Un bug non vale niente finché qualcun altro non riesce a riprodurlo e vedere l'impatto. Il report è dove questo succede, ed è il passo che chi inizia affretta. Un modello abbozza un report pulito dalle tue note in pochi secondi, il che è utile, a patto che tu verifichi ogni riga prima che esca. Questo post chiude la serie iniziata con il loop. Per le basi della scrittura di report, come scrivere il tuo primo report di sicurezza si abbina bene a questo.

Cosa serve a un triager

Un triager legge molti report e riproduce quelli che sono chiari. Dagli un titolo breve che nomina il bug e l'asset, passi esatti che può seguire, la request e la response che lo provano, e un'affermazione semplice sull'impatto. Fai in modo che possa incollare i tuoi passi e vedere lo stesso risultato. Un report che fa indovinare il lettore viene chiuso o rimandato indietro per più dettaglio.

Le parti di un report

Parte Cosa ci va
Titolo La classe di bug e l'asset interessato
Sommario Una o due frasi su cosa è e perché conta
Passi Numerati, esatti, riproducibili da uno stato pulito
Evidenze La request e la response, screenshot dove aiutano
Impatto Cosa ottiene un attaccante, detto in modo semplice
Correzione Un suggerimento breve e onesto quando ne hai uno

Abbozza dalle tue note con il modello

Se hai tenuto le note lungo il loop, hai la materia prima. Dai al modello la request, la response e cosa il bug lascia fare a un attaccante, e chiedi un report nella struttura qui sopra. Il modello è bravo a trasformare note grezze in prosa pulita e passi coerenti. Dagli fatti, non una supposizione sulla severità, e digli di lasciare un segnaposto ovunque gli manchi un dettaglio, così scrive un vuoto invece di inventarne uno.

Valuta la severità con onestà

La severità decide la fascia di ricompensa, quindi la tentazione di gonfiarla è reale, e i triager la vedono in fretta. Valuta ciò che hai provato, non ciò che potrebbe essere possibile. La Bugcrowd Vulnerability Rating Taxonomy mappa le classi di bug alle severità, e il CVSS di FIRST dà un punteggio con un vettore documentato. Un modello può proporre un vettore CVSS, e tu controlli ogni metrica rispetto a ciò che hai davvero dimostrato. Un medium onesto batte un high esagerato che viene declassato e ti marchia come qualcuno che esagera.

Verifica ogni riga prima di inviare

È la stessa regola su cui gira tutta la serie. Leggi la bozza del modello rispetto alle tue evidenze. Ogni passo funziona da uno stato pulito? Ogni URL e parametro è corretto? L'impatto corrisponde a ciò che hai provato, senza niente aggiunto per effetto? Ripercorri i tuoi passi un'altra volta sul target, esattamente come scritti, e correggi qualsiasi cosa non si riproduca. Il report deve essere vero, perché il triager lo eseguirà.

Cosa non lasciar fare al modello

Non lasciare che il modello scriva un impatto che non può sostenere, nomini una CVE di cui non è sicuro o descriva un passo che non hai eseguito. Questi sono gli errori che un modello fluente fa mentre prova a essere utile, e ciascuno ti costa credibilità con il programma. Tieni i dati del programma e degli utenti fuori dalla bozza oltre il minimo necessario per mostrare il bug, e tieni il report fuori dai servizi pubblici finché il programma non ha corretto il problema e concordato la divulgazione. I termini di disclose.io descrivono la divulgazione in buona fede.

Invia, poi segui

Manda il report attraverso il canale del programma, rispondi in fretta alle domande e aggiungi dettaglio se il triager lo chiede. Se il bug viene declassato, leggi perché prima di discutere, perché il triager di solito ha un contesto che tu non hai. Un seguito calmo e accurato costruisce il registro che fa guadagnare gli inviti privati più avanti.

La fine della serie, e l'inizio del loop

Hai letto uno scope, mappato una superficie, testato e verificato bug, costruito un agente per accelerare le parti noiose e scritto un report. Questo è tutto il loop. Eseguilo di nuovo sull'asset successivo. Tieni aperti l'OWASP Web Security Testing Guide e il caso d'uso del bug bounty, e comincia la passata successiva da il loop.

Fonti

  1. Bugcrowd Vulnerability Rating Taxonomy
  2. FIRST CVSS
  3. OWASP Web Security Testing Guide
  4. disclose.io core terms

Altro su Carriera e metodologia

Carriera e metodologia

Code e limiti di frequenza nel lavoro di sicurezza

Come code, limiti di frequenza e rallentamenti incidono su recon e cicli di agenti, e cosa pubblicano Verboo, Venice, Drael e NotHoly su ciascuno.

Intermedio6 min di lettura

Carriera e metodologia

Bug bounty con un copilota di IA: il loop

Un loop di bug bounty con l'IA: scegli il programma, leggi lo scope, recon, testa, verifica, segnala. Cosa abbozza il modello e cosa controlli.

Base4 min di lettura