A triager opens your report with one question in mind: can I reproduce this in the next five minutes? Everything else — the elegant payload, the video with captions, the theory about how the code might be structured — comes second. Reports move quickly through triage when they remove work from the reader's plate. They stall when a triager has to hunt for the URL, guess the account state, or ask for a screenshot you took but buried in paragraph nine.
Most triage queues are long, and most triagers are reading between other tickets. Put the five things they need before they have to scroll: the affected asset, the exact input, the observable result, the security consequence, and the reproduction environment.
If the vulnerability only fires when a feature flag is on, the victim is an admin, or the request needs a header your proxy added, say so in that block. Hiding a precondition to make the bug look bigger is the fastest way to earn a "not reproducible" and a slow back-and-forth.
The title is a label on a shelf. A good one lets a triager route the report to the right team without opening it.
Weak: XSS on the site. Better: Stored XSS in support ticket subject executes in agent dashboard. Strongest: Stored XSS in support ticket subject (account A) executes in agent dashboard (account B).
The third version names the vulnerability class, the injection point, the victim surface, and the trust boundary crossed. That last part matters: a self-XSS that only fires in your own session is not the same bug as one that fires in someone else's browser, and the title should make the difference obvious.
Keep one issue per report. If you found a stored XSS and a missing rate limit on the same endpoint, file them separately unless the chain is genuinely required for impact. Bundled reports slow triage because two teams may need to look at them.
Write for someone who has never seen the application and does not trust your conclusion. Assume they will follow your steps literally, in order, without improvising.
Then add the raw request. One HTTP request block is often more useful than ten screenshots, because a triager can paste it into a proxy and replay it. Include cookies only if they belong to your own test session, and strip them if the program asks. If the bug needs a specific header, show that header.
If a step takes more than one action to describe, split it into two steps. Triagers follow lists; they skim paragraphs.
Screenshots should show the URL, the relevant state, and a timestamp where possible. Record a short screen capture only when timing or a multi-step interaction is genuinely hard to describe. Forty seconds beats ten minutes.
"An alert box appeared" is a symptom. Impact is what that alert box represents: session tokens readable by an attacker, actions taken as the victim, data belonging to another user returned in a response.
Write one or two sentences answering three questions: who is harmed, what do they lose, and what does the attacker have to do to make it happen? For a stored XSS in an agent dashboard, that might read: "Any user who can submit a ticket can run script in the browser of an agent reviewing it, allowing the attacker to read that agent's session token and act with agent privileges." Concrete, and it follows directly from your steps.
Resist inflation. Calling every finding "full account takeover" when you have demonstrated a redirect erodes trust and invites a severity argument you will lose. If you can describe the reach — which roles, how many users, whether authentication is required — do it plainly. A CVSS vector or a suggested priority tier is welcome in many programs, but it should support your case, not replace it.
A short fix suggestion saves the engineering team time and signals that you understand the bug rather than just the tool that found it. Two or three sentences is usually right.
Be specific about the layer: "encode the subject field on output in the agent dashboard template" is actionable. "Rewrite the input handling" is not. Mention a defensive control when it is cheap to add, such as server-side validation alongside client-side checks. If you cannot see the backend, describe what you observed and offer a direction instead of asserting an implementation.
Skip the unrelated hardening wishlist. A report about stored XSS does not need your opinions on TLS configuration, password policy, and missing security headers. Those belong in a separate, low-severity report if the program accepts them at all.
Small choices add up to hours of delay across a program.
Tone counts too. Triagers are not adversaries, and a report written on the assumption that they will try to reject it reads as hostile. State the facts, answer likely objections in advance, and let the evidence argue.
Summary: one sentence naming the vulnerability, the affected asset, and the consequence. Steps to reproduce: numbered, literal, with a raw request. Impact: who is harmed and what they lose. Evidence: a screenshot or response body with the proof highlighted. Remediation: one or two specific suggestions. Then stop.
Write the draft, put it aside for a few minutes, and read it as though you are the triager seeing the target for the first time. If a step assumes knowledge you did not provide, add it. Fast triage is rarely about finding rarer bugs; it is about making an ordinary bug impossible to misunderstand.
Photo: viarami / Pixabay
CVSS turns a vague severity opinion into a defensible number. Here is how the metrics work, how to build a vector,...
A practical roadmap for leaving a salaried IT security role for full-time bug bounty, covering skills, track record,...
A step-by-step build of a Subfinder, httpx and Nuclei recon pipeline — install, script, filter the noise, and...
Notes from the front lines of bug hunting.
