How to read an expertise report: high, medium, low and informational findings

After a cybersecurity expertise you receive a report several pages long: a list of findings, a severity for each and recommendations. On first read it can feel heavy — unfamiliar terms, CWE numbers, OWASP references. In fact the report is a work plan. Read it the right way and you know exactly which problem to close, when and how.

In this article we look at how a report is structured, how the levels differ and how to work through the findings.

What a single finding consists of

Report formats vary, but each finding usually contains:

• Title — a short description, for example "Host header injection" or "Root detection not implemented".
• Severity — high, medium, low or informational.
• Description — what the problem is and where it was found: URL, parameter, screen or file.
• Evidence — request and response, a screenshot or reproduction steps.
• Impact — what could happen if the weakness is exploited.
• Recommendation — the direction of the fix.
• References — a CWE identifier, OWASP Top 10, an ASVS or MASVS requirement.

Do not skip the references. If a mobile report cites MASWE-0097 and M7 "Insufficient Binary Protections" from the OWASP Mobile Top 10 (2024), those pages describe what the reviewer expects to see. That lets you fix to the standard rather than "roughly".

What the levels mean

Severity combines how serious a weakness is with how easy it is to exploit. The exact criteria depend on the methodology of the organisation running the expertise, so treat the following as general guidance.

High

Issues that can lead to data leakage, account takeover, bypassing payment or a business process, or modifying and redistributing the app. In mobile apps, missing root or jailbreak detection, improper certificate validation and storing sensitive data unencrypted often land here. Until these are closed, resubmitting makes little sense.

Medium

The weakness is real, but exploiting it needs an extra condition: a special environment, user action or a combination with another weakness. Examples include missing emulator detection or some business logic gaps. Leaving medium findings "for later" is a mistake: they are usually checked again too.

Low

Limited impact, or dangerous only together with other issues — for example plain http:// links inside an app. Fixes are usually quick and cheap, so it makes sense to close them in the same pass.

Informational

Not a vulnerability but an observation: the server version in a header, extra service information, an outdated library. On their own these may carry no risk, but they give an attacker reconnaissance material. If a fix takes a few minutes, make it.

Severity sets the order of fixes, not whether to fix. Prepare a response for every item in the report.

From our own experience: what a report looks like

When our own product — a tax and finance SaaS platform — went through the expertise, the web part had 6 findings:

• the "payment successful" page was shown before the payment provider confirmed the payment (business logic);
• Host header injection: the app trusted X-Forwarded-Host and built absolute URLs and password reset links incorrectly;
• two information disclosures: the full route list was sent to the browser, and responses contained excess data;
• an action could be performed without checking state (business logic);
• ports open to the internet: FTP and control panel ports.

The mobile app (Android APK and iOS IPA) had 9 findings, most of them high: root and jailbreak detection, protection against dynamic analysis tools (Frida and others), app integrity checks, certificate validation and encrypted storage. Emulator detection was medium and http links were low. All 15 items were closed.

Note that several web findings shared one root cause — the app trusted proxy headers too much. Grouping items by root cause saves time.

How to work through the findings

1. Reproduce every item. Follow the evidence steps in your own environment. If you cannot see the problem, you cannot prove you fixed it.
2. Group by root cause. One configuration mistake can surface as several findings.
3. Queue by severity. High first, then medium, then low and informational. Close quick low items along the way.
4. Fix the cause, not the symptom. For Host header injection, do not patch one page — restrict trusted proxy headers for the whole app and force the root URL in production.
5. Re-test. After each fix, repeat the evidence from the report and record that the result changed.
6. Prepare a response document. For each item: what was done, which file or setting changed, how it was verified. For mobile apps, attach the MD5, SHA1 and SHA256 checksums of the new APK/IPA.

Common mistakes

• Fixing only the high findings and leaving the rest "for the next release".
• Applying the recommendation literally without checking whether the same problem exists elsewhere.
• Fixing in a test environment and not shipping it in the submitted build.
• Not reading the informational items at all.

Summary

An expertise report is not criticism; it is a concrete task list. Understand the structure of each finding, queue them by severity and back every fix with evidence, and the re-check goes much faster and calmer.

Sipar does this work before the expertise: a Claude AI agent reviews code and configuration quickly, and an expert confirms the findings and fixes them. To see where your product stands, request a security scan — we close the gaps before the official check.