How to Read a Security Finding

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

That is usually the wrong order, and the reason sits in 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, and each does a different job.

CVSS: what the score measures

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. Most reports populate neither.

So a Base score of 9.8 says "this is a severe flaw in the abstract", not "this is your most urgent problem".

Reading the vector

The vector is the string behind the number, and it is the more useful half. Each metric covers one thing:

• 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 far 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.
• 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.

Vectors get published for that reason. A report that gives numbers without vectors gives you no way to check the reasoning, so you are taking the rating 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 links a finding to the existing literature on that class of bug, and it makes patterns visible: three findings sharing one CWE are one habit showing up three times.

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

Severity, risk and priority

These three words get used interchangeably in practice.

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 ranking into a priority order is your side of it.

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, provided it genuinely applies. Write down why, so the decision can be defended 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.

When to push back

Sometimes 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. Check that last one before you assert it. Sometimes the tester did miss something, and sometimes the confusion is itself 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.