Severity, Confidence, Verification: How to Read a Scanner Finding

Most scanner reports lead with a single number per finding: a severity. "3 High, 7 Medium." That number quietly bundles together three different questions, and the bundling is why automated reports so often cause either panic or shrugs. Pulling the three apart makes a report both more honest and more useful.

Three questions, three fields

When a scanner raises a finding, you want to know:

If this is real, how bad is it? That is severity.
How sure is the scanner that it is real? That is confidence.
Has a person actually confirmed it? That is verification.

They are independent. A finding can be high severity and low confidence (an outdated library version that might be exploitable), or low severity and high confidence (a missing Referrer-Policy header, which is unambiguous and minor). Collapsing them into one label throws away exactly the information a triager needs.

Severity: the impact if true

Severity answers the impact question on the assumption that the finding is accurate. Scanners usually express it on a five-point scale, from Critical through High, Medium and Low to Informational, and often derive it from a scoring system such as CVSS for known vulnerabilities, or from fixed rules for configuration issues.

Two things are worth knowing about scanner severities. First, they are generic: the scanner does not know that the "admin panel" it found is a static page with no admin functions, or that the cookie without a Secure flag is a cosmetic preference rather than a session. Second, they are deliberately pessimistic, because the cost of under-rating a real issue is higher than the cost of over-rating a false one. So read severity as "the ceiling, if everything the scanner assumed is true".

What severity is not is a priority order for your work. Priority is severity adjusted by confidence, by context and by effort, and that adjustment is the job of the person reading the report.

Confidence: how sure the detection is

Confidence answers a question about the detection method, not about the site. Some methods are nearly certain by construction:

A response header is either present or it is not.
A TLS handshake either completed with TLS 1.0 or it did not.
If the scanner retrieved the contents of .env, the file is exposed.

Other methods are inferential:

A version string in a JavaScript file says a library version is old. It does not say whether the vulnerable function is ever called, or whether the vendor backported a fix without changing the version.
A reflected parameter in a page suggests input is echoed. It does not say whether it is encoded safely.
An error message that looks like a database error may be a database error, or a themed 404 page.

A scanner that labels all of these "High" with equal weight is not lying, but it is leaving out the part that matters. Showing confidence separately tells the reader which findings they can act on immediately and which need ten minutes of looking before anyone is alarmed. The guide on false positives goes through the common inferential traps.

Verification: has a person looked?

Verification is a workflow state, not a measurement. A finding starts as Needs review, whatever its severity or confidence, because no automated system should be allowed to tell a client "you have a vulnerability" without a human having looked at the evidence. It moves to Confirmed when a person has checked the evidence and agrees, or to False positive when they have checked and disagree, ideally with a one-line reason that survives into the next scan so the same finding does not come back as new.

The reason to keep this separate from confidence is accountability. Confidence is the tool's opinion. Verification is yours. A report that distinguishes the two lets a client see which items carry your professional judgement and which are still the scanner talking.

Reading the three together

A simple way to triage a fresh report:

Severity	Confidence	What to do first
High or Critical	High	Verify today, fix this week. These are the real emergencies, and there are usually few of them.
High or Critical	Medium or Low	Spend the ten minutes to verify before anyone is alarmed. Many resolve to false positive or to "true but not reachable".
Medium	High	Batch into a configuration pass. Headers, cookies and TLS settings are often fixed together.
Low or Info	Any	Record, fix opportunistically, do not let them crowd the summary.

Notice that the second row is where most of the judgement goes, and where a one-number report does the most damage: it either makes the client panic about something unconfirmed, or it trains them to ignore "High" because the last three were nothing.

Putting it in a client report

If you deliver assessments to clients, show all three fields for every finding and show the counts for each separately in the summary. "1 High (needs review), 3 Medium (2 confirmed), 2 Informational" tells the truth. "4 vulnerabilities found" does not. It also makes the follow-up conversation easier, because the client can see that the "High" is a library version you are about to check, not a breach.

When you do verify a finding, write down what you looked at. Evidence that can be re-checked is what separates an assessment from an opinion, and it is what lets the next person, or the next scan, pick up where you left off.