How to Write a Great Vulnerability Assessment Report with this Template

David Sopas is a longtime member of the Cobalt Core and the no. 1 ranked researcher on the Cobalt Hall of Fame. He also leads up Char49 and works as a consultant in Checkmarx. David has found several critical vulnerabilities in top sites and is always looking for a new challenge. Among other achievements he recently was the first to reach 2,000 rep points on Cobalt, but his work is not over yet. In this blog post he shares his advice on writing a high-quality vulnerability assessment report.

Introduction to Vulnerability Report

Based on my experience with bug bounties and penetration tests (pentests) on Cobalt.io and other platforms, I have learned that a well written report of bugs or pentests will make a major difference in your ability to help the program owners or pentest clients understand and correct problems and increase your value.

In the world of vulnerability reporting, you sometimes come across the following type of vulnerability reports:

Or even begging for a better reward:

If I was a bug bounty program owner (or program curator) or pentest client, I would categorize both reports with 'WTF' — not based on the vulnerability itself, but the lack of information and effort by the security researcher or white hat hacker. Don’t forget you need to sell your service. You need to show the program owners or clients that you care about their security and that you can talk the talk — articulating the problem in clear terms and demonstrating some authority on the subject.

In this blog post, I will share some of my own best practices for writing great security vulnerability assessment reports for bug bounty programs and penetration tests. A good vulnerability assessment report aims to provide network security engineers insights into system vulnerabilities with an end goal of empowering the remediation process, understanding the risk they present, and the potential for a network breach.

You can use this information to create a template for vulnerability or pentest findings — whether you want to call that a vulnerability assessment report template, sample vulnerability assessment report, vulnerability scan report template, vulnerability assessment template, security vulnerability assessment template, or a penetration testing report template. The principles are the same.

1. Prepare before you test

Being professional and understanding what the business is looking for often makes the difference between earning a few bucks and hitting a homerun.

To start, carefully read the program or project scope and rules of engagement. This is one of the most important things to do before you begin researching and testing.

Bug Bounty Preparation — Imagine spending time finding a security bug and writing an awesome bug report and then, in the end, the program owners tells you it’s out of scope — it’s frustrating. It happened to me when I first started working on bug bounty programs. I didn’t spend enough time reading the program scope. If you have specific questions about the scope, contact the program owners/curators by email or use the comments on another report you are submitting to contact them.

Rules of engagement for bug bounty programs provide details such as:

• In-scope areas
• Out-of-scope areas
• Out-of-scope techniques and methods such as social engineering or use of automated scanning tools
• Vulnerability types that are eligible for the program
• Vulnerability types that are ineligible
• Program-specific instructions such as setting up a test account and submitting a bug
• Terms
• Restrictions based on researcher age, location, or other factors
• Guidelines for public disclosure
• Reward eligibility criteria including reward rules for duplicate reports

Pentest Preparation — For pentests, service agreements and statements of work include similar information about the scope including a list of the in-scope components of the network, web or mobile application, system, API, or other asset. The security researcher does not publicly disclose pentest vulnerabilities (vulns) unless contractually permitted to do so.

2. Writing a good report

After you have done some research and found a great vulnerability, the next step is to make a good report of your findings. Whether you are communicating a security weakness in a bug bounty submission or a penetration testing report, the basics of what you include are the same.

To help you guys out, I have explained some of the guidelines I use to write good reports. I have explained it according to the format found on the Cobalt platform — a structure which could also be replicated in an email or a free-text report.

Title of the vulnerability

When creating a title for the vulnerability, be explicit about what the vulnerability is. Don’t write show-off titles. Let’s consider an cross-site scripting example (XSS vulnerability example):

Example of a good title — Reflected XSS on reference parameter at product page

Example of a bad title — CRITICAL — XSS on your program

Keep in mind that this is the first thing the program owners or clients will see. It’s their first impression of you and your report.

Description

A vulnerability description must be short, clear, and direct. Program owners and clients don’t want to spend much time reading.

A great way to describe a vulnerability in a short, clear way is to include references/links to trusted sources that can help others understand, identify, and fix the bug. This could be an OWASP link, CVE references or links to other public advisories and standards. (Don’t reference Wikipedia or other less respected sites.)

e.g. If I find a XSS bug, I’ll explain what it is, give an OWASP reference, tell them what type of XSS was found, and so on.

Don’t copy-paste information from automated tools or other sources into the description. It shows the program owners or clients that you didn’t even take the time to write a few words specific to their scenario.

If it is my first time submitting a report to a bounty program, I’ll introduce myself and say “hello.” There’s nothing wrong with showing a little politeness.

Proof-of-concept

In the proof-of-concept section, I always treat program owners and clients as if they are newbies. I provide a clear step-by-step guide or process showing how to replicate the vulnerability.

Example of a XSS proof of concept:

Step 1: Go to the following [URL]

Step 2: Enter your username and password (you need an account to do this)

Step 3: In the Search box at top right, insert the following information:

<script>alert(document.domain);</script>

Step 4: Click the “Search” button

Step 5: You’ll see a JavaScript popup box showing your domain

Check the attached screenshot to see the actual XSS vulnerability.

Depending on the type of vulnerability, I may also show the reflected code so the program owners and clients can identify faster where the payload is loading. Example:

Criticality Assessment

To give the program owners and clients an idea of the seriousness or criticality of a security weakness, you can explain how a malicious user or black hat hacker could attack by exploiting the vulnerability you found. Describe how and what the company (and its clients and customers) can lose with this vulnerability, in particular the impact on confidentiality, integrity, and availability. The criticality assessment could consider factors such as customer privacy, reputation impact for the company, inappropriate access to proprietary or confidential data such as intellectual property or marketing plans, potential regulatory fines, or compliance risks.

You might also be called upon to assign a criticality rating. In the Cobalt.io platform, the rating is based on impact and business context such as the damage potential, reproducibility, exploitability, number of affected users, and discoverability of each finding.

3. Tools

Share which tool or tools you used when finding the vulnerability. If you used only a browser, identify the required browser version. For particular types of vulns, the proof of concept will only work on some versions so be specific.

Example: Burp, Nmap and Firefox 47.0

4. Attachments

Provide screenshots, video, or audio recording to improve and add value to your report.

Sometimes program owners and clients can’t replicate the vulnerability so helping them with images or a step-by-step video or audio will help them significantly.

If you can’t do a video, just send an audio version explaining how to replicate your finding. This will also show the owners and clients that you took time to create a good report and they may even evaluate you a little higher for the extra effort.

5. Suggested Fixes/Solutions

Show the program owners clear solutions for their problem. Give examples, don’t just tell them to sanitize the input, but also give them references and possible ways to do it. They’ll greatly appreciate it. Sometimes the developers don’t know how to fix a vulnerability, and if you provide a great description of a suggested fix it’s a win-win situation. After all, the key mission is to fix the vulnerabilities.

Comments

Comments are great when/if the program owners or clients need further clarification on the report.

Always be polite and, for bounty programs, don’t continually ask for updates. You can ask owners once or twice every month, and if you are not getting any feedback, contact the platform support team to help moderate the issue.

Differences Between Bug Bounty Reports and Pentest Reports

A bug bounty report documents a single vulnerability while a pentest report documents all discovered vulnerabilities. For instance, an average application pentest discovers 20 to 30 vulnerabilities.

Pentest Executive Summary

Pentest reports typically include an Executive Summary near the beginning to provide a testing overview and the security tester’s impression of overall security risk. The Executive Summary also notes any trends in the types of weaknesses found; for instance, if several weaknesses fall under an OWASP Top 10 category, it would be noted. The Summary also could include information from the project’s Statement of Work such as assessment scope and methodologies. Ideally, the Summary is written in less technical terms to encourage distribution beyond the IT and security teams to business and management stakeholders. After all, security risk is ultimately business risk. The Summary also typically includes a list or table of discovered vulns.

Interactive Pentest Reports

Historically, pentest reports are delivered at the end of an engagement in a linear PDF, but the age of the interactive pentest report is dawning. Organizations like Cobalt.io are leading the way in providing a real-time dashboard and detail views so clients can track progress throughout an engagement. This creates efficiency while also increasing the level of communication with the client. For instance, the development team, security engineers, or others responsible for fixing open issues can ask questions and learn from the researcher during testing. In addition, the client can mark a vulnerability ready for retest, allowing you to immediately proceed with retest and close the bug as resolved.

Conclusion

The main goal in producing a quality report is to show program owners and clients that you are there to help — collaboratively working with them, unified against the bad guys. The problem is that sometimes that connection is not clearly established. By being professional and writing great reports, you can build a stronger relationship with the companies you assist, making you the resource of choice for future programs and assessments.

I hope this blog post will help improve your reports, and benefit the organizations you assist along the way. Read more about how Cobalt offers a variety of reports including attestation letters to prove you've completed a pentest successfully.

Cya next time!