Recording a bug reproduction for a security report
Bug bounty triage teams reject a meaningful share of reports specifically because the reproduction evidence is weak — a screen recording that clearly shows the exploit working, step by step, is often the difference between a report getting taken seriously and getting closed as “unable to reproduce.”
Record from a clean, reset starting state
Starting your screen recording from a known, reproducible starting point — freshly logged in, cache cleared if relevant, no leftover state from earlier testing — means a triager watching your recording can follow the exact same steps and get the exact same result, rather than wondering whether some earlier action of yours contributed to the outcome.
Narrate each step as you record it, don’t rely on the video alone
A silent screen recording of a technical exploit forces the triager to reverse-engineer what you clicked and why — narrating each step (“navigating to the account settings endpoint, modifying this parameter”) as you record removes that guesswork, similar to the narration principle covered in our bug report guide for internal reporting, applied here to an external security audience.
Show the before and after state clearly
Recording the application’s normal, expected behavior briefly before triggering the vulnerability, then showing the actual exploited result, gives a triager a clear contrast — this is broken, here’s what it should look like — rather than requiring them to already know what normal behavior is supposed to be.
Keep the recording focused on the reproduction, not a broader exploration
A recording that wanders into unrelated exploration after demonstrating the core vulnerability dilutes the specific evidence a triager needs — a tight, focused recording of just the reproduction steps is more useful, and faster to review, than a longer exploratory session.
Include your recording software and settings if relevant to the report
For vulnerabilities where exact timing or browser behavior matters, briefly noting what you used to record (and any relevant settings) gives the triager context for reproducing your exact conditions, similar in spirit to the identifying-information practice in our insurance documentation guide, applied here for technical reproducibility rather than evidentiary purposes.
Frequently asked questions
Why do bug bounty reports get rejected even with a screen recording attached?
Often because the recording lacks narration or a clean starting state, leaving the triager unable to confidently reproduce the same result — a focused, narrated recording from a known starting point addresses this directly.
Should I narrate a bug bounty reproduction recording, or is the video enough?
Narration matters — a silent recording forces the triager to guess at your reasoning and exact steps, which is a common, avoidable reason reports get stuck or rejected.
Related reading: Recording a bug report your dev team will actually use · Recording a walkthrough for insurance or warranty documentation · Documenting a software bug for a support ticket