Interpreting vulnerability scan results

The Prairie Paws scan finished at 1:15 in the morning on Friday, October 30, 2026. When Jordan opened the report later that day, his heart sank. It listed 214 findings across 22 devices, sorted into colors from red to blue, and ran to more than ninety pages. Keisha laughed when she saw his face. Nobody fixes ninety pages, she said. The skill is not reading the report; it is turning it into a short list of the right things to do first. This lesson is about that skill: understanding what a finding says, how severity scores are built, which findings are real, and how to decide what gets fixed this week, what gets fixed this month and what gets accepted.

Anatomy of a finding

Every scanner formats its reports differently, but each finding contains the same core pieces of information. Learning to read them quickly is the first step.

• Title and identifier: a short name and usually one or more CVE identifiers, plus the scanner's own plugin or check number.
• Affected asset: the device name or address, and the port or software where the problem was found.
• Severity and score: a rating such as critical, high, medium or low, usually based on a CVSS score.
• Description: what the weakness is and what an attacker could do with it, in general terms.
• Evidence: what the scanner observed, such as an installed version number or a response from a service. This is what lets you confirm or dispute the finding.
• Solution: the recommended fix, such as a specific update, a configuration change or removal of the software.
• References: links to vendor advisories and vulnerability databases.

The evidence section is the one beginners skip and experienced analysts read first. If a finding says a server runs a vulnerable version of a web server, the evidence should show which version the scanner saw and how. If the evidence is a guess from a banner on the network rather than a read of the installed files, the finding deserves a second look.

How CVSS scores are built

The Common Vulnerability Scoring System gives each vulnerability a score from 0.0 to 10.0. The version most scanners and databases still display is CVSS 3.1. Version 4.0, released by FIRST in November 2023, is being adopted gradually, so analysts see both. Both versions start from base metrics that describe the vulnerability itself, independent of any particular organization.

The metrics are written as a vector string, such as AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Reading it aloud helps: exploitable over the network, low complexity, no privileges needed, no user interaction, scope unchanged, and high impact on confidentiality, integrity and availability. That combination scores 9.8, which is critical. The vector is more useful than the number, because it tells you why the score is high.

Scores fall into bands that most tools use to label severity.

The calculation itself combines weights for each metric. You will not need to compute it by hand on the exam, but seeing it once makes the score less mysterious. The short program below implements the published CVSS 3.1 base-score formula. You can edit the vector strings and run it again.

import math

W = {'AV': {'N': 0.85, 'A': 0.62, 'L': 0.55, 'P': 0.2}, 'AC': {'L': 0.77, 'H': 0.44},
     'UI': {'N': 0.85, 'R': 0.62}, 'CIA': {'H': 0.56, 'L': 0.22, 'N': 0.0}}

def roundup(x):
    # CVSS rounds up to one decimal place
    i = round(x * 100000)
    return i / 100000.0 if divmod(i, 10000)[1] == 0 else (math.floor(i / 10000) + 1) / 10.0

def base_score(vector):
    m = dict(part.split(':') for part in vector.split('/'))
    changed = m['S'] == 'C'
    pr = {'N': 0.85, 'L': 0.68 if changed else 0.62, 'H': 0.5 if changed else 0.27}[m['PR']]
    iss = 1 - (1 - W['CIA'][m['C']]) * (1 - W['CIA'][m['I']]) * (1 - W['CIA'][m['A']])
    impact = 7.52 * (iss - 0.029) - 3.25 * (iss - 0.02) ** 15 if changed else 6.42 * iss
    exploitability = 8.22 * W['AV'][m['AV']] * W['AC'][m['AC']] * pr * W['UI'][m['UI']]
    if impact <= 0:
        return 0.0
    total = 1.08 * (impact + exploitability) if changed else impact + exploitability
    return roundup(min(total, 10))

for v in ['AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H',
          'AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H',
          'AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N']:
    print(v, base_score(v))

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 9.8
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H 7.8
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N 6.1

The three results show how the metrics trade off. The second vector has the same high impact as the first, but the attacker must already be logged in locally, so it drops to 7.8, high rather than critical. The third needs a user to click something and affects only a little confidentiality and integrity, so it lands at 6.1, medium, even though its scope is changed.

CVSS 4.0 and the other metric groups

CVSS 4.0 keeps the idea of base metrics but refines them. It adds an Attack Requirements metric, splits user interaction into passive and active, and replaces Scope with separate impact ratings for the vulnerable system and for subsequent systems. It also renames scores to show which metric groups were used: CVSS-B for base only, CVSS-BT when threat metrics are added and CVSS-BTE when environmental metrics are added too. Version 3.1 had similar optional groups, called temporal and environmental.

The point of those extra groups is important for interpretation. A base score describes the worst reasonable case for everyone. Threat metrics adjust it for whether exploit code exists and attacks are happening. Environmental metrics adjust it for your own situation: how important the affected system is and what protections surround it. A critical base score on a test machine with no network access may matter less to you than a high score on an internet-facing server.

Beyond the score: exploitation and exposure

Keisha's biggest lesson for Jordan was that severity is not the same as priority. Thousands of vulnerabilities are rated high or critical every year, but only a small fraction are ever exploited in real attacks. Three questions sharpen the list.

• Is it known to be exploited? Check the government lists and vendor advisories from Lesson 4. A flaw on a known-exploited list moves to the top regardless of its exact score.
• How likely is exploitation soon? The EPSS probability helps rank flaws that are not yet known to be exploited.
• How exposed and important is the asset? An internet-facing device or a server holding sensitive records outranks an isolated workstation.

True and false positives

Scanners make mistakes in both directions. A false positive is a finding for a weakness that is not really there. A common cause is a backported fix: Linux distributions often fix a vulnerability in an older version number without changing the version, so a scanner that only reads the version reports a flaw that has already been patched. Another is a service that reports a misleading version banner. A false negative is a real weakness the scanner missed, often because it could not log in, the device was off, or the check did not exist yet.

Confirming a finding means checking the evidence against the device itself: the installed package version and its changelog, the vendor's advisory, or the configuration setting in question. Confirmed false positives should be marked in the scanner with a note, so they do not reappear next quarter. Suspected false negatives are handled by fixing the cause, such as a failed scan login, which shows up in the report as an authentication failure and is itself a finding worth acting on.

Jordan checked the arithmetic before the plan went to Owen. Of the 22 critical and high findings, the first steps covered 20. The other 2 high findings were both on the old waiting-room PC, which could no longer run a supported browser, so they went into the client report as a replacement recommendation. Keisha said that kind of checking is exactly what a report deserves before it reaches a client.

Remediation, mitigation and acceptance

Every finding ends in one of a small number of outcomes. Remediation removes the vulnerability, usually by updating, reconfiguring or uninstalling. Mitigation reduces the risk without removing the flaw, for example by blocking a port, disabling a feature or isolating the device. Acceptance means the organization knowingly decides to live with the risk, which must be approved by someone with authority and recorded with a review date. Transferring risk, such as through insurance, is a fourth option that Lesson 6 explains. There is no outcome called ignoring it.

Remediation is not finished until it is verified. Brightline rescanned each fixed device or checked it through the device-management agent, and closed the ticket only when the finding disappeared. The rescan sometimes revealed new findings, because fixing one thing can expose another, which is one more reason the vulnerability management cycle never really ends.

Reporting to the client

The client does not need ninety pages. Owen's rule was that every quarterly report started with one page in plain language: how many critical and high items were found, what was fixed, what remains, what the client needs to decide, and how the numbers compare with last quarter. The full technical detail went into an appendix for anyone who wanted it. A clinic owner can act on a page that says: one urgent firewall issue was fixed within a day, thirteen PCs needed a browser update that is now installed, and the old waiting-room PC cannot be updated and should be replaced or removed.