How to Read a Security Finding

A report arrives with fourteen findings, ranked. The ranking looks authoritative — there are numbers to one decimal place — and it is tempting to work down the list from the top.

That is usually the wrong order, and understanding why requires knowing what the number actually measures.

The anatomy of a finding

A complete finding carries an identifier, a title describing the flaw, a severity, a CVSS score with its vector, a weakness class, the affected location, reproduction steps, evidence, and remediation guidance. Taking one from our published sample report:

F-001: Broken Access Control — Horizontal Privilege Escalation
CVSS v3.1: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE: 285   OWASP: A01:2021

Three separate classification systems, each answering a different question.

CVSS: what the number is, and is not

The Common Vulnerability Scoring System produces a score from 0.0 to 10.0. Almost every report gives you the Base score, which describes the intrinsic characteristics of the flaw — how hard it is to exploit and what exploiting it achieves against the affected component.

The Base score deliberately excludes your circumstances. It does not know what data the system holds, how many customers it serves, or whether it is reachable from the internet in your particular deployment. Two further metric groups exist for that — Temporal, which accounts for exploit availability, and Environmental, which is where your context belongs — and most reports populate neither.

So a Base score of 9.8 means "this is a severe flaw in the abstract". It does not mean "this is your most urgent problem".

Reading the vector

The vector is the string behind the number, and it is more useful than the number. Each metric answers one question:

• AV — Attack Vector. Where the attacker must be. N network, A adjacent, L local, P physical. This is the metric that most often changes in your environment: a flaw scored AV:N against an internet-facing deployment is materially less exposed on a system reachable only from your internal network.
• AC — Attack Complexity. L low means no special conditions. H means the attacker needs something to go their way.
• PR — Privileges Required. N none, L a normal account, H an administrative one.
• UI — User Interaction. N none needed, R a user must do something — click a link, view a page.
• S — Scope. U unchanged, C changed, meaning the flaw lets the attacker affect resources beyond the vulnerable component. A scope change is a significant escalation and is worth noticing.
• C, I, A — Confidentiality, Integrity, Availability. What is lost. H high, L low, N none.

Read that way, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H says: reachable over the network, easy, needs no account, needs no victim to do anything, and totals confidentiality, integrity and availability. That sentence is worth more than "9.8", because you can argue with it.

Being able to argue with a score is the point of publishing the vector. If a report gives numbers without vectors, you cannot check the reasoning, and a finding you cannot check is one you have to take on trust.

CWE: the weakness class

The Common Weakness Enumeration identifies the kind of flaw — CWE-285 improper authorisation, CWE-89 SQL injection, CWE-79 cross-site scripting. It is how a finding connects to everything ever written about that class of bug, and it is what makes patterns visible: three findings sharing one CWE is not three bugs, it is one habit.

That distinction changes the remediation. Fixing three instances of CWE-89 individually leaves the fourth, written next quarter, exactly as vulnerable.

Severity, risk and priority are three different things

These get used interchangeably and should not be.

Severity is a property of the flaw. The report assigns it, and CVSS is the usual instrument.

Risk is severity combined with what the affected system means to you — what data it holds, who depends on it, what the consequence would be. Only you can assess this. The tester knows the technique; you know the business.

Priority is risk combined with effort, dependencies and timing. A moderate finding fixed by a configuration change this afternoon outranks a critical one that needs a schema migration and a release window.

A report that ranks by severity has done its job. Converting that into priority is yours, and it is not a step to skip — it is the step where a document becomes a plan.

The re-ranking questions

For each finding worth acting on, four questions:

• What does this system actually hold? The same flaw is not the same risk in a payment path as in an internal booking tool.
• Who can reach it? Check AV against your real deployment, not the abstract one.
• What would exploitation cost us? Regulatory exposure, customer data, downtime, contractual breach.
• Does anything already mitigate it? A compensating control the tester could not see legitimately lowers the risk — but only if it genuinely applies, and writing down why is what makes that defensible later.

Expect the order to change. A "high" on a system holding nothing sensitive can reasonably sit below a "medium" on the system that runs your billing. That is not disagreeing with the report; it is doing the half the report could not do.

When to push back

Sometimes the right answer is that the finding is wrong or the score is. Reasonable grounds: the vector does not match your deployment; a compensating control makes exploitation impractical; the finding assumes a configuration you do not run.

Unreasonable grounds: it would be inconvenient to fix, or the tester did not understand the system — which is worth investigating rather than asserting, because sometimes it is true and sometimes it is the finding.

A good tester will discuss a score. Ask for the reasoning, give yours, and record the outcome either way. The full structure a report should have is in what is actually inside a VAPT report, and what separates a written finding from tool output is in the side-by-side.