How do you prioritize and report the findings of a pen test based on OWASP risk rating?

The OWASP risk classification is a methodology used to assess and prioritize risks associated with security vulnerabilities in web applications and APIs. It is based on a systematic approach that helps development, security, and management teams identify and address the most critical vulnerabilities. This methodology is closely aligned with the OWASP Top Ten, which highlights the most significant security risks in applications.

When ranking findings in a pen test using the OWASP risk rating, it’s essential to provide a clear rationale for each vulnerability’s score. For example, while working with a fintech company, I discovered several vulnerabilities in their payment processing API. By assigning values to the OWASP factors—likelihood, impact, detectability, and exploitability—I was able to rank these issues effectively. One critical vulnerability had a high exploitability due to poor authentication mechanisms and a severe impact since it affected sensitive financial data. This process allowed the team to prioritize patching based on the severity and urgency, ensuring the most significant risks were addressed first.

Once we finish the execution of a pentest, we need to classify the results. Thsi part of a pentest is a crucial step to clearly communicate findings, prioritize remediation, and align security efforts with business objectives. Classification typically involves categorizing vulnerabilities based on their severity, impact, and associated risk. The most commonly used frameworks are CVSS (Common Vulnerability Scoring System): A standardized score from 0 to 10 based on factors like impact, exploitation complexity, and more. And the OWASP Risk Rating: A framework that evaluates risks based on likelihood and impact.

Writing a good and concise penetration test report requires balancing technical detail with readability and relevance. The goal is to clearly communicate findings, their impact, and actionable remediation steps to both technical and non-technical stakeholders. For example, we could use this basic structure and write an effective report: Executive Summary (for non-technical stakeholders) ; Scope and Objectives ; Methodology ; Findings and Analysis ; Remediation and/or Recommendations ; Conclusion ; Appendices (detailed logs, tools used, or proof of concept).

For stakeholders, like executives, management and etc, we need provide a high-level overview of the key findings, their impact on the business, and suggested next steps. Focus on the business impact, show how do the vulnerabilities affect the organization in terms of data protection, financial risk, and regulatory compliance. Avoid technical jargon and use simple language to ensure understanding. BTW, teams like IT, Security and etc, we need to provide a detailed, technical report that includes step-by-step findings, proof of concept (PoC), and specific remediation recommendations. It's mandatory use severity levels (Critical, High, Medium, Low) to make simple to the teams prioritize the issues.

Following up on the results of a penetration test (pen test) is crucial to ensure that the identified vulnerabilities are addressed and that the organization's security posture improves. Follow these basic steps, will be enough to make a good operation: Review the Report with key stakeholders, prioritize remediation efforts, offer support and guidance to the involved teams, re-test and validate the fixes, document the results of remediation, continuous monitoring and future testing, and finally provide a final summary to Stakeholders.