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.
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.
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.
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.
| 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 |
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.
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.
È 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à.
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.
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.
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.
Carriera e metodologia
Come code, limiti di frequenza e rallentamenti incidono su recon e cicli di agenti, e cosa pubblicano Verboo, Venice, Drael e NotHoly su ciascuno.
Carriera e metodologia
Verboo, Venice AI, Drael e NotHoly a confronto per la sicurezza offensiva: fatturazione, licenza, dati, modelli e dove girano gli strumenti.
Carriera e metodologia
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.