Vulnerability Discovery and Analysis · Topic 3 of 5
Analysing Scan Results
Validate scanner findings, spot false positives and false negatives, troubleshoot scan settings, and prioritise with CVSS, EPSS and exploited lists.
- 5 min
- The four outcomes are true positive, false positive, true negative and false negative.
- A false negative is a missed real vulnerability, and it is the riskier error because it gives false comfort.
- Validate findings with a second method, version checks or a safe demonstration.
What it is
A scanner produces a long list of possible issues. Result analysis is the human work of deciding which findings are real, which matter most and which scans need to be repeated with better settings.
Without this step, a report is just a pile of tool output. With it, the client gets a short list of confirmed, ranked problems.
How it works
The four outcomes
Every reported item, or missing item, falls into one of four groups.
| Outcome | Meaning |
|---|---|
| True positive | The scanner reported a real vulnerability |
| False positive | The scanner reported a vulnerability that does not exist |
| True negative | No report, and no vulnerability |
| False negative | The scanner missed a vulnerability that does exist |
False positives waste time and erode trust. False negatives are more dangerous because they give false comfort.
Validating findings
Validation means confirming that the flaw is present and relevant. Methods include:
- Checking the evidence in the scanner output, such as the exact banner, response or setting.
- Comparing it with a second tool or a manual check, such as a different scanner or a targeted Nmap script.
- Logging in to confirm the installed version or setting, when allowed.
- Reading the vendor advisory to see which versions are affected.
- Safely demonstrating the issue, within the rules of engagement.
A common source of false positives is version-based detection. Some Linux distributions fix a flaw by backporting the patch into an older version number, so a scanner that only reads the version thinks the host is still vulnerable.
Common reasons for wrong results
| Problem | Effect | Fix |
|---|---|---|
| Credentials failed | Scan fell back to unauthenticated checks, so patches are missed | Check account, permissions and access method |
| Firewall or intrusion prevention blocked the scanner | Hosts look empty or ports look filtered | Allow the scanner address or scan from a better position |
| Out-of-date plug-ins | New flaws are not detected | Update before scanning |
| Wrong scan template | Wrong checks run, such as no web checks | Select a profile for the target type |
| Throttling or timeouts | Scan incomplete | Adjust speed and timeouts |
| Scope or address errors | Wrong or missing hosts | Review the target list |
| Agent not reporting | Device missing from results | Restart or reinstall the agent |
Reading the scan log is the first step in troubleshooting. A line saying that login failed explains many apparent "clean" results.
Prioritising
The Common Vulnerability Scoring System (CVSS) rates technical severity. It is a start, but it does not know your environment.
| Source | Use |
|---|---|
| CVSS base score | Technical severity of the flaw, 0.0 to 10.0 |
| Exploit Prediction Scoring System (EPSS) | Estimated probability that the flaw will be exploited soon |
| Known Exploited Vulnerabilities (KEV) catalogue from the United States Cybersecurity and Infrastructure Security Agency (CISA) | Flaws confirmed as exploited in real attacks |
| Asset value and exposure | Internet facing or holding sensitive data raises urgency |
| Compensating controls | Existing protections can lower real risk |
A medium CVSS flaw on an internet facing server that attackers already use may be more urgent than a critical flaw on an isolated machine.
Linking findings
Results become more valuable when combined. A weak password on one system plus a trust relationship to another may form an attack path that no single finding shows.
Testers also separate individual flaws from root causes, such as missing patch management. Fixing the cause removes many findings at once.
Attack dependencies
Before an attack is worth attempting, its prerequisites must hold. These dependencies decide whether a finding is practically exploitable.
- Network reach to the target from the tester's position.
- Valid credentials or a session, when the flaw needs authentication.
- A specific software version, library or configuration that the flaw requires.
Noting these dependencies keeps priorities realistic. A serious flaw that needs access the attacker cannot get is lower risk than its score alone suggests.
Documenting
For each validated finding, record the host, the evidence, the date and time, the tool and the version of its database. This makes the result repeatable and defensible.
If a scan shows a very clean result on a host that you know is old, suspect failed credentials or a blocked scanner before you trust it.
What to remember for the exam
- The four outcomes are true positive, false positive, true negative and false negative.
- A false negative is a missed real vulnerability, and it is the riskier error because it gives false comfort.
- Validate findings with a second method, version checks or a safe demonstration.
- Backported patches cause version-based false positives on some Linux systems.
- Failed credentials, blocked scanners and old plug-ins are common configuration problems.
- CVSS gives technical severity, EPSS estimates likelihood, and KEV lists flaws exploited in the wild.
- Context such as exposure and compensating controls changes priority.
- Record evidence, time and tool details for each finding.
Common mistakes
Reporting scanner output as is. Unvalidated findings may include false positives that damage your credibility.
Trusting a clean scan. It may mean that credentials failed or the scanner was blocked.
Ranking by CVSS alone. Real risk also depends on exposure, exploitation and value of the asset.
Dismissing a finding without checking. A version can look old but be patched, or look current but be misconfigured, so confirm the real state.
Forgetting root causes. Listing fifty missing patches without noting the patching process helps little.
Check yourself
What is a false negative?
A real vulnerability that the scanner failed to report.
Why might a scanner report a vulnerability on a patched Linux host?
It may judge by the version number, while the distribution backported the fix without changing it.
Which catalogue lists vulnerabilities confirmed as exploited in real attacks?
The CISA Known Exploited Vulnerabilities (KEV) catalogue.
Topic 3 of 5 in Vulnerability Discovery and Analysis
Test yourself on Vulnerability Discovery and Analysis
The full CompTIA PenTest+ PT0-003 question bank has 653 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.