Vulnerability Management · Topic 2 of 5
Interpreting Scan Results
Read vulnerability scan reports for CySA+: fields, CVE and CWE, true and false positives, validation steps and common findings such as weak TLS.
- 7 min
- Reports are leads that need validation, because scanners produce false positives and false negatives.
- A false positive is a reported issue that is not real, and a false negative is a missed real issue.
- The evidence or plugin output shows why a finding was raised.
What it is
A scan report lists every issue the scanner believes it found. The analyst's task is to read it, decide which findings are real, understand what each means and pass on clear, useful results.
Scanners make mistakes. A report is a set of leads to check, not a final verdict.
How it works
Fields in a finding
Most tools show similar fields, though the names differ.
| Field | Meaning |
|---|---|
| Host and port | Where the issue was seen |
| Plugin or check name | The test that produced the finding |
| Severity | The scanner's rating, often based on Common Vulnerability Scoring System (CVSS) |
| Identifier | A reference such as a Common Vulnerabilities and Exposures (CVE) number |
| Description and solution | What is wrong and the suggested fix |
| Evidence or plugin output | What the scanner saw, such as a banner or a registry value |
| Status or age | New, recurring or fixed since the last scan |
The evidence field is the most useful for validation. It shows exactly why the tool flagged the system.
Identifiers
A CVE identifier, such as CVE-2021-44228, names one publicly known vulnerability. The National Vulnerability Database (NVD) adds scores and details to CVE entries.
A Common Weakness Enumeration (CWE) identifier describes a type of software weakness, such as improper input validation. In short, CVE names a specific flaw in a product, and CWE names the underlying class of mistake.
True and false results
| Result | Meaning |
|---|---|
| True positive | The scanner reported a real vulnerability |
| False positive | The scanner reported a problem that does not exist |
| True negative | No finding, and there is truly no issue |
| False negative | The scanner missed a real vulnerability |
False negatives are the dangerous ones because nobody sees them. Causes include missing credentials, an outdated plugin set, a blocked scan or a service on an unusual port.
Validating a finding
- Read the evidence. Does it match the real system?
- Check the version and patch level. Some Linux vendors fix a flaw without changing the version number (backporting), so a version based check can raise a false positive.
- Confirm manually with a safe check, such as looking at the installed package or the configuration setting.
- Compare with other tools or with an earlier scan.
- Consider context. A service may be present but not reachable, or a compensating control may block exploitation.
- Record the decision, including why a false positive was dismissed, so the same finding is not reviewed again.
Credentialed scans reduce false positives. Treat informational findings as context, such as a list of open services, and not as vulnerabilities.
Common finding types
| Finding | Why it matters |
|---|---|
| Missing patch | A known flaw with a public fix is still present |
| Default or weak credentials | Easy to guess, and attackers try them first |
| Insecure protocol or old Transport Layer Security (TLS) | Cleartext or outdated encryption exposes traffic |
| Expired or self signed certificate | Users and systems cannot rely on the identity |
| Misconfiguration | Open shares, excess permissions or unnecessary services |
| End of life software | No more security updates will come |
| Injection (such as Structured Query Language, SQL, injection) | Untrusted input changes a query or command |
| Cross site scripting (XSS) | A site returns attacker supplied script to other users |
| Cross site request forgery (CSRF) | A user's browser is tricked into sending an unwanted request |
| Missing security headers | Web servers lack browser side protections |
A short example
Host: 192.0.2.40 Port: 443/tcp Severity: High
Plugin: TLS Version 1.0 Protocol Detection CVE: not applicable
Evidence: The server accepted a TLS 1.0 handshake
Solution: Disable TLS 1.0 and 1.1, enable TLS 1.2 or laterThe finding is a configuration weakness and not a missing patch. The fix is a server setting, so the owner of the web service should handle it, and a rescan should show it closed.
Trends
Compare scans over time to see new, recurring and fixed findings. A finding that returns after a fix points to a process problem, such as an old image being redeployed.
Other assessment tools
| Tool | Purpose | Reading the output |
|---|---|---|
| Metasploit Framework | An exploitation framework of modules (exploit, auxiliary and others) that authorised testers use to validate a finding | A session opened on the target confirms a true positive, but a failed attempt does not prove a false positive |
| Maltego | Link analysis that maps people, domains, addresses and infrastructure | A graph of entities joined by relationships, built with transforms that query data sources |
| Recon-ng | A modular open source intelligence (OSINT) reconnaissance framework | Results from modules, which often need API keys, are stored per workspace as tables of hosts and contacts |
| ScoutSuite | A multi cloud configuration auditor | A report of findings by service, such as public buckets or security groups open to the internet |
| Prowler | Cloud checks for Amazon Web Services (AWS), Azure and Google Cloud against Center for Internet Security (CIS) benchmarks | Each check is PASS or FAIL with a severity and the affected resource |
| Trivy | A scanner for container images, file systems and infrastructure as code | A table of CVEs with installed and fixed versions, plus misconfigurations |
| Checkov | A static analyser for infrastructure as code such as Terraform and CloudFormation | Passed and failed policy checks with the file and resource |
| Atomic Red Team | Small tests ("atomics") mapped to MITRE ATT&CK techniques | If the test runs and raises no alert, there is a detection gap |
| Caldera | MITRE's automated adversary emulation, with agents that run abilities in operations | Which steps succeeded, were blocked or were detected |
Atomic Red Team and Caldera are breach and attack simulation (BAS) tools. They test whether controls and detections work, instead of looking for missing patches, and they belong only on authorised test systems.
Library Vulnerability Severity Installed Fixed
log4j-core CVE-2021-44228 CRITICAL 2.14.1 2.15.0In this Trivy style row, upgrading to the fixed version closes the finding. An empty fixed column means no patch exists yet, so use a compensating control.
Check: CKV_AWS_20: "S3 Bucket has an ACL defined which allows public READ access."
FAILED for resource: aws_s3_bucket.logsA failed Checkov check names the rule and resource, so the fix is made in code before deployment.
What to remember for the exam
- Reports are leads that need validation, because scanners produce false positives and false negatives.
- A false positive is a reported issue that is not real, and a false negative is a missed real issue.
- The evidence or plugin output shows why a finding was raised.
- CVE identifies one specific flaw, CWE identifies a weakness class, and NVD enriches CVE entries.
- Credentialed scans produce more accurate results.
- Version based detection can be wrong when a vendor backports a fix.
- Informational findings are context, not vulnerabilities.
- Common findings include missing patches, weak credentials, old TLS, misconfigurations and end of life software.
- A finding that keeps coming back signals a process issue.
When a question asks what to do first with a surprising critical finding, validate it. Confirm the evidence before escalating or changing production systems.
Common mistakes
Accepting severity at face value. The scanner's rating ignores your asset value and exposure, so context can raise or lower the real priority.
Dismissing findings without evidence. Marking something as a false positive needs a recorded reason.
Confusing CVE and CWE. One is a specific instance, the other is a category.
Assuming a clean scan means safe. Missing credentials or coverage can hide problems, so a clean result may be a false negative.
Treating every informational item as noise. A list of open ports or services often shows unneeded exposure.
Check yourself
What is a false negative in vulnerability scanning?
A real vulnerability that the scanner failed to report.
What is the difference between a CVE and a CWE?
A CVE names one specific known vulnerability, while a CWE names a general type of software weakness.
Why can a version check produce a false positive on Linux?
The vendor may have backported the security fix without changing the version number.
Topic 2 of 5 in Vulnerability Management
Test yourself on Vulnerability Management
The full CompTIA CySA+ CS0-004 question bank has 654 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.