Summary

A while ago I wrote about getting quietly deprioritized by a vendor after handling a disclosure badly. That post was about the relationship. This one is about the artifact: the report itself, and why some of mine get acknowledged and scheduled inside a single patch cycle while others sit in triage for weeks.

The uncomfortable finding, after enough of both kinds, is that the difference is usually not the severity of the bug. It is whether the first person who opens the report can reproduce it and re-state the impact in one sentence without asking me anything. Almost everything below serves those two goals.

What the triager needs on the first read

A vendor’s intake queue is triaged by someone who has ten other reports open and no context on my finding. The report has to survive that reader. I structure every one around the same fields, in this order, because it front-loads the decision:

Field What goes in it Why it is first-read material
One-line impact “Unauthenticated attacker can read arbitrary files as the web user” The triager can route and rank from this alone
Affected versions Exact build strings I tested, not “latest” Tells them whether it is still live in a supported release
Preconditions Default config? Auth required? Non-default feature? Separates “critical” from “critical if you enabled X”
Reproduction Numbered steps, exact requests, expected vs actual This is the part that gets it fixed or ignored
Suggested severity A full CVSS vector, not just a number Shows the work; invites correction rather than a fight
Remediation What a fix would need to do Saves the engineer a step and signals good faith

The single highest-leverage line is the one-line impact. If a busy reader has to assemble the impact themselves from a wall of technical detail, the report drops down the queue until someone has time. If it is stated in the first sentence and the reproduction backs it up, it gets scheduled.

Reproduction is the whole report

Everything else is framing around this section. A reproduction that a triager can paste into their own environment and watch fail is worth more than any amount of prose about how serious the issue is. What I have learned to include, every time:

  • The exact request or input, copy-pasteable, not a screenshot of it.
  • The expected behaviour and the actual behaviour, stated separately. “It should return 403, it returns the file” is unambiguous. “It is broken” is not.
  • The minimum steps. If the bug reproduces without authentication, I do not include a login step. Every removable precondition I leave in makes the finding look narrower than it is.
  • A clean environment. I confirm the repro on a fresh install before sending, because “cannot reproduce” from the vendor is where reports go to die, and it is almost always my setup drift rather than their disagreement.

The part that is about writing, not research

The technical work is usually the easy half. These are the writing choices that, in my experience, move a report faster:

  1. One bug per report. Bundling three findings into one thread guarantees that the whole thing moves at the speed of the hardest one. I split them, cross-reference if they chain, and let each get triaged on its own.
  2. Match their intake format. If the vendor has a form or a template, I use it exactly. A report that maps onto the fields their tooling expects gets processed; one that ignores the format makes someone re-key it first.
  3. A CVSS vector, not just a score. I include the full vector string so the reader can see how I got to the number and adjust it. Handing over a bare “9.8” reads as a negotiating position. Handing over the vector reads as an assessment.
  4. State the ask once, plainly. “I am reporting this for coordinated disclosure and will hold publication until a fix ships or 90 days, whichever is first.” No implied threats, no moving the date, no drama. A predictable researcher is an easy one to work with, and that reputation is the thing the bad-list post was really about.

What slows a report down

The inverse is just as consistent. The reports of mine that stalled shared some combination of: a vague reproduction that needed a follow-up email before anyone could confirm it, an inflated severity that the vendor spent their first reply arguing down instead of scheduling a fix, multiple loosely-related bugs in one thread, and an adversarial tone that turned a technical exchange into a defensive one. None of those are research failures. They are all report failures, and they are all avoidable.

Closing

The through-line with the vendor-patching-cadence data is that vendors are faster than their reputation when the report does not make them work to understand it. The severity of the bug sets the ceiling on how fast it should be fixed. The quality of the report determines whether it gets anywhere near that ceiling. I spend more time on the write-up now than I used to, and it has done more for my fix rates than any improvement in the actual finding.