Writing bug bounty reports with AI

A bug is worth nothing until someone else can reproduce it and see the impact. The report is where that happens, and it is the step beginners rush. A model drafts a clean report from your notes in seconds, which is useful, as long as you verify every line before it goes out. This post closes the track that began with the loop. For the basics of report writing, how to write your first security report pairs well with this.

#What a triager needs

A triager reads many reports and reproduces the ones that are clear. Give them a short title that names the bug and the asset, exact steps they can follow, the request and response that prove it, and a plain statement of impact. Make it so they can paste your steps and see the same result. A report that makes the reader guess gets closed or sent back for more detail.

#The parts of a report

Part	What goes in it
Title	The bug class and the affected asset
Summary	One or two sentences on what and why it matters
Steps	Numbered, exact, reproducible from a clean state
Evidence	The request and response, screenshots where they help
Impact	What an attacker gains, stated plainly
Fix	A short, honest suggestion when you have one

#Draft from your notes with the model

If you kept notes through the loop, you have the raw material. Give the model the request, the response, and what the bug lets an attacker do, and ask for a report in the structure above. The model is good at turning rough notes into clean prose and consistent steps. Give it facts, not a guess about severity, and tell it to leave a placeholder anywhere it lacks a detail, so it writes a gap instead of inventing one.

#Rate severity honestly

Severity decides the reward tier, so the temptation to inflate it is real, and triagers see through it fast. Rate what you proved, not what might be possible. The Bugcrowd Vulnerability Rating Taxonomy maps bug classes to severities, and CVSS from FIRST gives a score with a documented vector. A model can propose a CVSS vector, and you check each metric against what you actually demonstrated. An honest medium beats an exaggerated high that gets downgraded and marks you as someone who overstates.

#Verify every line before you submit

This is the same rule the whole track runs on. Read the model's draft against your evidence. Does each step work from a clean state? Is every URL and parameter correct? Does the impact match what you proved, with nothing added for effect? Walk through your own steps one more time on the target, exactly as written, and fix anything that does not reproduce. The report has to be true, because the triager will run it.

#What not to let the model do

Do not let the model write impact it cannot support, name a CVE it is not sure of, or describe a step you did not perform. These are the errors a fluent model makes while trying to be helpful, and each one costs you credibility with the program. Keep program and user data out of the draft beyond the minimum needed to show the bug, and keep the report off public services until the program has fixed the issue and agreed to disclosure. The disclose.io terms describe good-faith disclosure.

#Submit, then follow up

Send the report through the program's channel, answer questions quickly, and add detail if the triager asks. If the bug is downgraded, read why before you argue, because the triager usually has context you do not. A calm, accurate follow-up builds the record that earns private invitations later.

#The end of the track, and the start of the loop

You have read a scope, mapped a surface, tested and verified bugs, built an agent to speed the dull parts, and written a report. That is the whole loop. Run it again on the next asset. Keep the OWASP Web Security Testing Guide and the bug bounty use case open, and start the next pass from the loop.