Introduction
From personal experience, penetration testing reports can be divided into two categories: simple reports that provide a brief summary of vulnerabilities, which are technical in nature and not suitable for management, and complex and formal reports that can be used for project summaries, acceptance, and official purposes.
I came across an article that discussed how to write high-quality vulnerability reports, specifically for foreign penetration testing reports. I have summarized the content and included other reports in the attachment for reference.
Simple Report
| Name | Description |
|---|---|
| Summary | Introduction to the vulnerability, providing a brief description of the issue and its scope |
| Impact | Description of the vulnerability's impact |
| Reproduction Steps | Steps to reproduce the vulnerability, including screenshots, HTTP requests, POCs, or exploits |
| Recommendations | Suggestions for fixing the vulnerability |
| References | Generally not included |
Vulnerability scoring and severity levels typically reflect the level of harm, ranging from informational, low, medium, to high.
Formal Report
This report is based on the securitum-protonmail-security-audit and is more practical. There are many other links in the attachment for those interested.
- Summary (Work, Penetration)
- Testing scope
- Testing methods (OWASP TOP10, OWASP ASVS)
- Discovered vulnerabilities
During the testing process, special emphasis was placed on vulnerabilities that could negatively impact the confidentiality, integrity, or availability of processed data.
As part of the testing, a combination of manual testing methods (using the aforementioned methodologies) and various automated tools were used, including Burp Suite Professional, DirBuster, ffuf, nmap, Visual Studio Code, semgrep, grep, and sonarqube.
The vulnerabilities are described in detail in the subsequent sections of the report.
Vulnerability Risk Level:
Vulnerabilities are classified into five levels, reflecting the probability of exploitation and the business risks associated with their exploitation. The following is a brief description of each severity level.
- Critical
- High
- Medium
- Low
- Informational
Vulnerability Statistics:
Graphical representation
- Version Change History
- Time
- Version
- Description of changes
- Vulnerability Reproduction Process Record
- Vulnerability name
- Vulnerability description
- Prerequisites for the attack
- Technical details (POC)
- Vulnerability location
- Recommendations for fixing the vulnerability
Lessons Learned
When writing the report, it is recommended to use the passive voice instead of the first person.
When providing recommendations for fixing vulnerabilities, it is generally better to start with suggestions rather than using a mandatory approach.
One difference between foreign reports and our reports is the placement of the final summary. Foreign reports tend to place it at the beginning, while we prefer to place it at the end. Sometimes, we may also place it at the beginning for summarization purposes.
In terms of vulnerability reproduction, foreign reports are more detailed and include information on informational vulnerabilities. The vulnerability fix recommendations are tailored to the system rather than providing general solutions.
When reproducing the vulnerability scenario, it is recommended to approach it from the perspective of the attacker and the victim, making it easier for others to understand. In comparison, some domestic vulnerability notifications only provide text and links without any accompanying graphics, making it difficult to understand the vulnerability without a solid foundation.
Foreign reports also assign numbers to vulnerabilities, seemingly based on project names, which helps clearly distinguish these vulnerabilities.
Writing a report doesn't require much technical work, but making it understandable and of high quality can be challenging. I have personally experienced situations where a report had to be revised 5-6 times based on client feedback before it was satisfactory. The report itself is procedural, and as long as you have a template, you can modify it for others. Some reports are simply simple reports submitted with the source code. In such cases, a simple report is sufficient.
References: best-practices-for-writing-quality-vulnerability-reports
Additional reference for other penetration testing reports: More Penetration Testing Reports