For most of us, the pentest report is the worst part of pentesting. Never mind that most pentesters spend an average of 30-50% of the total time on a pentest writing the report. The pentest report is the deliverable, the part of your work that clients actually see, and for them, the most important part. That’s a far cry from the approach many pentesters would prefer to take, of simply doing the work and it’s done – but clients need to be able to see what you’ve done, what you’ve found, and to read and break that down across the organization in a meaningful way. Doing that means getting a report, and a good one.
That’s why so many pentesters treat pentest reports like industry secrets. For the most part, they are. A good report can differentiate your pentest firm from a client, help you to deliver better value, and literally help a client make the right decisions for compliance and security.
So, what makes a good pentest report? Clarity, content written for technical and non-technical users, and sufficient proof and data on findings to make them meaningful.
Writing for Technical and Non-Technical Readers
The first important step in a pentest report is to consider who is reading it. In most cases, the first part of the report is for non-technical readers. This might be Executive and C-Suite, it might be senior management, it might be lower management and eventually IT management. Eventually, most of these readers will have little to no technical experience or knowledge. They need vulnerabilities broken down in a legible and non-technical way, detailing risk level, impacted environments, and impacted users. The top part of the report has to answer questions in simple language, with the most important question being “Are you secure? Yes/No? If not, how bad is it? If not, which assets are impacted? That’s it.
The second major part of the report, the details or the body of the report, is for the technical reader. This should contain specific details, tooling, screenshots, and technical information. You can write this part of the report to the experienced user, who knows exactly what you are talking about and hopefully, how to fix it. Technical readers appreciate and prefer information on how to replicate vulnerability findings, proof of those findings, and, where you have them, remediation tips.
Organizing Data
Data in your report should be organized based on factors like severity or asset. Picking which one to group vulnerabilities by should depend on the client. However, most will prefer assets grouped by severity, which allows severity to easily function as a means of prioritization. That’s also true when the same vulnerability exists across multiple assets or servers – meaning you won’t have to duplicate the finding throughout the report like you would if grouping by asset.
You can also write up an additional asset report, such as highlighting critical vulnerabilities by asset in the “report card” or overview section of the pentest report.
Report Sections
In most cases, your report should include information like an executive summary, a report overview or “report card”, the scope of the pentest, and the main body of the report with technical findings.
Assessment Overview – This optional section should function as a cover sheet and should cover information from the initial scope – detailing methodology, assessment components, etc. This should be relatively non-technical, except to function as a list of what was used, which standards were applied, and why. This is also where you might mention who the pentester is, what their qualifications are, etc.
Executive Summary – The executive summary exists to explain the pentest to the non-technical reader – usually C-Suite, executives, and IT management. These groups normally have only tangential experience with the technology being discussed. In this case, you want to highlight major vulnerabilities, discuss overviews, and discuss how specific assets are impacted. It’s important to use clear and relatively non-technical language.
Scope – Clearly define the scope, outlining tested assets, detailed methodology, assessment components, and tooling. Some pentesters prefer to split this data into an assessment overview and final section with tooling.
Vulnerability Report – A Vulnerability Report or “report card” highlights vulnerabilities based on risk level – allowing you to quickly highlight what was found and how bad it is. In this case, it’s important to use a standard, such as CVSS scoring and the OWASP Risk Rating Methodology, which helps you to sort vulnerability findings based on an Informative-Low-Medium-High score – for easier prioritization by the client.
Report Body – The report body contains the technical detailing for the vulnerability findings, which normally covers what, where, how, and how to fix it:
- CVSS Scoring – Detail the risk level of the vulnerability finding in clear language
- Description – What was found? How was it found? On what asset(s)? What is exploited? How? Did it lead to access? Etc.
- Evidence: How was it found, what systems were used, what tools were used, and a screenshot where possible.
- Remediation Advice – How can the client go about resolving the issue. E.g., downloading a patch or implementing security standards.
- Any references, such as links to the asset issue, etc.
Additional Sections
In most cases, you’ll want to map your pentest report to compliance frameworks used for the test. Whether that’s NIST Guidelines, OWASP 10, or a specific compliance framework doesn’t matter. You should normally include a section just for the framework, so the client can see how they align with that framework and how they are compliant. This is more important if the test is for compliance or audit purposes, in which case you need the section for them to pass the audit.
Cyver Core – Our Approach
Cyver Core uses automation to pull findings from imports to automatically build the pentest report. This is then broken down into customizable sections, which the pentester has to edit and manage themselves. Cyver Core does provide a base template, but most pentesters will prefer to create their own, with their own branding, highlights, and unique scoping data. Cyver Core’s primary report also adds additional sections, so the full template looks more like this:
- Cover Page / Introduction
- Management Summary
- Technical Summary with full list of findings and risk mapping
- Assignment – The scope, full details, checklists used, etc.
- Compliance – Any compliance framework used with findings mapped to that framework
- Findings – Automatically imported from Cyver Core’s platform using tokens
- Test Setup – The pentester, their source, tooling, and approach
Closing
In every case, it’s important to offer clear and open communication with the client throughout the pentest. That means delivering status notifications, offering findings in advance when critical findings occur, and ensuring that the client is aware when you stop and start testing, so that issues can be tracked and mapped to their proper causes.
Eventually, pentest reporting takes up a considerable amount of time – even if you’re importing scans from NMap directly into a report. You still have to do the write ups, you still have to add details, and you have to add a considerable amount of personalization per client. That will never change. Writing a good report means paying attention to those (small) details, offering valuable advice to the client, and ensuring that information is available for both types of readers – technical and non-technical.
Interactive Pentest Reporting
Pentest management platforms like Cyver Core deliver new reporting formats, with interactive reports in the platform. That allows stakeholders like developers and IT to quickly sort and view relevant parts of the report, while delivering features like Findings-as-Tickets, interactive metrics, threat analysis, and integrated chat. These features allow stakeholders to export findings to Jira and other tooling, for faster management and remediation. This means driving more added-value from remediation tips and CVSS scoring, so the client can quickly prioritize remediation and resolve problems. This type of vulnerability management is already offered by many scanners, meaning many clients are already accustomed to using similar tools – but for automatically discovered vulnerabilities.
Cyver Core is a pentest management platform offering tooling like report automation, vulnerability libraries, and pentest management. We change how you build and deliver reports, by using automation to create vulnerability findings as tickets – which can be used to generate quality, informative reports. If you want to know how it works and how it’s different from a standard pentest report, click here to see our tooling in action. Or feel free to schedule a call to see a full demo of the platform.