Finding the bug is only the beginning

The interesting part of vulnerability research often starts after I send the report.

Reporting through GitHub, a bug-bounty platform and a vendor’s security mailbox turned out to be three different experiences. In one case, a maintainer replied within minutes and sent a patch a couple of hours later. Other reports went through a much longer process.

On a bounty platform, I also ran into duplicates of reports submitted months earlier. From outside the programme, I could not see that work. Reproducing a bug did not tell me whether someone else had already reported it.

Two mistakes worth keeping

I bundled several findings from one project into one report. It made sense to me at the time: one project, one package. It made the individual findings harder to handle separately. I now prefer a distinct reproduction, impact explanation and tracking thread for each issue. CVE assignment is a separate decision; the number of reports alone does not determine it.

The second mistake was more useful. I reproduced a bug locally and sent it in, then learned that the affected functionality was not enabled in the production deployment I had in mind. The code was present and the local failure was real, but I had not established the path from an attacker to that code in the relevant environment. I withdrew the report.

Reproduction needs a deployment context

A crash is evidence of a failure. To explain its security impact, I also need to establish the input an attacker controls, the configuration that reaches the affected path and the consequences in that setting.

That extra work matters to the person receiving the report. A maintainer needs enough information to reproduce and fix it. A triager needs enough to assess scope and impact. Missing context adds another exchange before either can act.

I came away paying more attention to the route from report to fix. Finding an issue is useful; getting a clear, reproducible report to someone who can change the code is what makes the work count.