Reading a vulnerability report: severity, likelihood, and what to fix first

The short answer

A vulnerability report, whether from an automated scan or a penetration test, lists findings, each with a severity and usually a likelihood or exploitability. Severity measures potential impact: what could happen if the flaw were used. Likelihood measures how easily it could be used: whether it is reachable from the internet without a login, whether an exploit is public, whether anything else already blocks it. The order of fixes follows both together. Critical and high findings reachable without login are fixed first, within days. Findings behind a login, or that need unusual conditions, are scheduled. Low and informational findings, of which automated scans produce many, are explained and handled in routine maintenance. A good report separates confirmed findings from potential ones and false positives; a good partner explains each finding in a sentence, provides a fix plan with dates, retests afterwards and writes a summary you could show a client.

Reading the labels

Label	Usually means	Typical examples	Typical response
Critical	Takeover or full data exposure, easily exploited	Injection on a public endpoint, exposed admin with default credentials, leaked keys	Fix or mitigate within a day or two
High	Serious impact, exploitable with some conditions	Access control flaws, stored cross-site scripting, outdated component with a public exploit	Fix within days
Medium	Real but limited impact or harder to exploit	Missing security headers on sensitive pages, weak session settings, verbose errors	Fix within weeks, in the next release
Low	Minor impact	Version disclosure, minor misconfiguration	Routine maintenance
Informational	Not a vulnerability; an observation	Technology fingerprint, best-practice notes	Note and move on
False positive	The scanner was wrong	A pattern match that does not apply	Document why and exclude

Turning the report into a plan

What a good report contains

For each finding: where it is, what it is, how it was confirmed, the evidence, the severity and exploitability, and a specific recommendation. A summary that a non-technical reader can follow. A separation of confirmed, potential and false positive. A retest section. And the scope: what was tested and what was not, because a clean report of a narrow scope proves little about the rest.

What this means for you

Read a vulnerability report by severity and exploitability together, fix the critical and high findings reachable from the internet within days, schedule the rest with dates, explain or accept the low and informational items, and insist on a retest that records each finding’s status. The report is not a verdict on your site; it is a work list, and reading it properly is what turns it into a safer site rather than a filed document.