Day 38: Report writing
Bug bounty and pentest writeups
I’ve interacted with a number of social media communities and forums where pretty decent hackers miss a bounty because of a poorly written report. I’ve also seen numerous posts where experienced hackers emphasize the importance of good writing skills for a Penetration Tester. I’m yet to find out what a good report needs to look like but I have a rough idea so far.
If you may know a better way to approach it, feel free to hit me up.
Security reports are how we (security researchers) make sense of complex technical findings and turn them into real security improvements. A good report will simply lay out vulnerabilities, rates their risk, and suggests fixes. It is meant to give decision-makers the facts they need to make choices. These reports also track progress. They show we’re meeting compliance rules like GDPR or PCI-DSS. It seems easy and straightforward, but a report that just lists problems misses the point. It should tell us what broke, why, and how to stop it from happening again.
Pentest Reports
A pentest report is meant for executives, legal teams, and the engineers who fix things. Its main job is to show all found vulnerabilities, give them a risk score, often using CVSS for consistency, and suggest how to fix them. These reports are often structured in layers because different people and departments need different information. An Executive Summary targets non-technical folks (think the CEO or the legal team), while a detailed Technical Report goes to the implementation teams. Security professionals must translate complex exploits into business terms for executives, explaining how a bug could affect the company’s revenue or reputation. At the same time, they give engineers the details needed for a fix. This layered approach just makes it that everyone gets what they need.
The Executive Summary gives a high-level, jargon-free overview. It covers the test’s purpose, scope, methods, and highlights critical vulnerabilities needing immediate attention.
The Technical Report’s introduction sets the stage for detailed findings. This section lists the key people involved, contact info, tested assets, objectives, scope, test type, approach, and how we graded risks.
The core of the technical report describes each vulnerability. In it, you should find the details on how we found it, its potential impact, our testing methods, and an exploitation rating. We review every step taken to confirm the bug, including the timeline, targets, successful attacks, access gained, and any privilege escalation paths.
Get Nile Okomo’s stories in your inbox
Join Medium for free to get updates from this writer.
The Risk Assessment section evaluates each vulnerability’s risk, often using CVSS scores. On here, the section considers event frequency, threat capability, control strength, compound factors, and required skill or access. The goal is to show the business impact and likelihood, so organizations can focus on the biggest threats.
Recommendations offer specific, actionable fixes for each vulnerability. These might involve patches, system reconfigurations, or even replacing security measures. Recommendations directly link to findings and can also have extra mitigation or compensating controls to boost overall security.
Evidence and Appendices provide solid proof. The decision-makers like this part a lot so clear language goes a long way. In this section, you’ll find detailed exploit walkthroughs, screenshots, videos of attacks, logs, network traffic, and system config files.
Finally, Countermeasure Effectiveness assesses existing security controls, both active and passive. You’ll often find details on incident response during testing.
Bug Bounty Write-Ups
A bug bounty write-up, unlike a pentest report, targets a very specific audience: the program’s security team, especially those who validate submissions. The goal of these reports is to clearly show a vulnerability exists, how to exploit it, and its direct impact. The faster they confirm it, the faster the researcher gets paid. Bug bounty reports stress "easy to follow" steps and "quick reproduction" because these programs often handle a ton of submissions and triagers review many reports daily. Any confusion, missing steps, or reproduction issues usually causes delays or, in some cases, lead to rejecting valid bugs.
A good bug bounty write-up is lean and efficient. This means that it should help someone quickly grasp and reproduce the bug. Start with a descriptive, concise title. It should immediately tell you the bug type, its location, and overall impact. Think "SQL Injection in [example.com] parameter [id=]" or "Admin account takeover in [https://www.google.com/search?q=app.example.com]" and so on.
The description then explains the vulnerability, often with a CWE identifier, just to give the reader a general idea of the issue. Then, tell the story of how you found the bug; it usually helps the triager understand the context.
The Proof of Concept (PoC) is your smoking gun. It needs a short summary and clear visuals, like images or videos, showing the exploit in action. For complex bugs, an exploitation script goes a long way. Here, always include testing credentials, the exact endpoint, and the payload used.
While not always required, offering a technical fix is a big plus. It saves the security team time and they’ll definitely appreciate it.
I know, I know. Where’s an example of each? I’ll do a full pentest soon and a bug bounty as well and you’ll be the ones to read them before everyone else. Although, there are some standards that exist out there meant to give us a professional guide on how to do this. A good example is the Web Application Security Testing Guidehttps://owasp.org/www-project-web-security-testing-guide/v42/5-Reporting/README.
That’s all for today, Nerds!! Hack responsibly and See you tomorrow!!! Get outta here!!!
