lca

Introduction
In my personal experience, penetration testing reports can be divided into two categories: simple reports that provide a brief summary of vulnerabilities, which are more technical and not suitable for management, and complex and formal reports that can be used for project summaries and acceptance.

I came across an article that discussed how to write high-quality vulnerability reports, specifically for penetration testing reports. I have summarized the content and included other reports in the attachment for reference.

Simple Report

Vulnerability scoring and severity levels usually 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 provides a more practical approach. There are many other links in the attachment for those interested.

1. 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

2. Version History

• Date
• Version
• Description of modifications

3. Vulnerability Reproduction Process Record

• Vulnerability name
  • Vulnerability description
  • Prerequisites for exploitation
  • Technical details (POC)
  • Vulnerability location
  • Recommendations for fixing

Lessons Learned

When writing the report, it is recommended to use 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, it may also be placed at the beginning for summarization.

In terms of vulnerability reproduction, foreign reports are more detailed and include information on informational vulnerabilities. The vulnerability fixing recommendations are tailored to the system, rather than generic solutions.

When reproducing the vulnerability scenario, it is important to present 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 involve much technical work, but making it understandable and of high quality is challenging. I have had the experience of revising a report 5-6 times based on client feedback before being satisfied. The report itself is procedural, and once you have a template, you can make changes based on the template for other people. Some reports are simply submitted as source code, so a simple report is sufficient.

References: best-practices-for-writing-quality-vulnerability-reports

Additional reference for other penetration testing reports: More Penetration Testing Reports