False Positives — Findings That Are Not Real
A false positive occurs when a vulnerability scanner reports that a vulnerability exists on a system when it actually does not. The scanner has matched a signature pattern against the target and flagged a finding, but investigation reveals the system is not actually vulnerable — perhaps because the vulnerable code path has been separately patched, the configuration does not match the exploitable condition, or the scanner is using an outdated signature that no longer accurately represents the vulnerability.
False positives waste time: security analysts investigate, verify, and document a threat that does not exist. At scale — a scanner producing hundreds of findings across dozens of systems — a high false positive rate can consume most of a security team's capacity for finding review, leaving little time for the real findings that require action. Organizations can reduce false positives by keeping scanner signatures updated, tuning scanner configurations for the specific environment, and establishing validation procedures before scheduling any remediation.
One important distinction that the Security+ exam specifically tests: a low-severity or informational finding is not a false positive. A finding that the scanner has correctly identified as a real vulnerability but rated at low priority is a true finding — it is real, it exists, it is just not urgent. Calling a low-severity real vulnerability a "false positive" misclassifies it, removes it from the tracking system, and leaves a real vulnerability unaddressed. False positive = the vulnerability does not exist. Low-severity = the vulnerability exists but is not critical.
False Negatives — Real Vulnerabilities the Scanner Missed
A false negative is the reverse scenario and, in most ways, more dangerous. A false negative means that a vulnerability genuinely exists on the system, but the scanner failed to detect it. The vulnerability is absent from the scan report. Security teams reviewing the report see a clean or low-risk result and conclude the system is secure — but it is not. An attacker who probes the same system may discover and exploit the vulnerability that the scanner missed.
False negatives occur primarily because scanners can only detect what their signature databases know about. If a vulnerability was discovered after the scanner's signature database was last updated, or if the vulnerability is so newly disclosed that signatures have not yet been written, the scanner simply has no pattern to match and produces no finding. A scanner running outdated signatures is systematically blind to every vulnerability published since the last update.
The primary defense against false negatives is keeping scanner signatures current. Before every vulnerability scan, verify that the scanner is using the latest available signature database. For environments with non-standard software, unusual configurations, or custom applications, work directly with the scanning vendor to develop or refine signatures that address your specific environment. If a scan report looks unexpectedly clean for a complex environment, treat it as a reason to investigate whether signatures are current, not as confirmation that the environment is secure.
Why False Negatives Are More Dangerous Than False Positives
The asymmetry between false positives and false negatives is important. A false positive creates work: an analyst investigates a non-existent vulnerability, documents the investigation, and closes the finding. This wastes time but causes no breach. A false negative creates a blind spot: an organization does not know about a real vulnerability, does not patch it, does not monitor for exploitation of it, and remains exposed to an attacker who does know about it. The false negative is an invisible risk — not just uncorrected but unrecognized.
Organizations managing risk must account for the possibility of false negatives, particularly when a new vulnerability becomes publicly known and signatures may not yet be deployed, or when scanner coverage of specific software versions is incomplete. Supplementing automated scanning with threat intelligence (which surfaces newly exploited vulnerabilities) and manual verification of high-risk systems provides some protection against the false negative problem that no scanner can fully eliminate.
CVSS — The Common Vulnerability Scoring System
The Common Vulnerability Scoring System (CVSS) is the industry-standard framework for quantifying the severity of individual vulnerabilities. CVSS assigns each vulnerability a numerical score between 0 and 10, where 10 represents the most critical possible finding. The score is calculated from multiple factors: how the vulnerability is exploited (network, adjacent, or local access required), whether authentication is needed, the complexity of the attack, and the impact on confidentiality, integrity, and availability if exploited.
CVSS scores are published in the National Vulnerability Database (NVD) at nvd.nist.gov, which is synchronized with the CVE list and provides enhanced search functionality. When a vulnerability scanner flags a finding, it typically includes the associated CVSS score so analysts can immediately understand relative severity without needing to look up additional context.
A critical detail: CVSS versions have changed over time, and different versions may produce different scores for the same vulnerability. CVSS 2.0 uses a different scoring methodology than CVSS 3.x, so a vulnerability may show a 6.5 score under version 2.0 and a 9.1 score under version 3.x. When reviewing vulnerability reports, note which CVSS version the score comes from, particularly when comparing findings across different scanners or databases that may reference different versions. The industry generally favors the most current scoring version, but legacy databases and older systems may still report 2.0 scores.
CVE — Common Vulnerabilities and Exposures
The Common Vulnerabilities and Exposures (CVE) system provides standardized identifiers — CVE numbers — for publicly known security vulnerabilities. Each CVE entry uniquely identifies a specific vulnerability, enabling consistent cross-referencing across scanners, databases, advisories, and patches. When a vulnerability scanner detects an issue, it almost always reports the associated CVE number, which the analyst can look up in any CVE-aware database to get full technical details, affected versions, and remediation guidance.
Primary reference databases include: the National Vulnerability Database (nvd.nist.gov), which provides CVSS scores and enhanced search; the CVE list maintained by MITRE (cve.mitre.org/cve), the authoritative source for CVE numbering; and individual vendor databases such as Microsoft's Security Response Center, which provide vendor-specific remediation details. When a scanner flags a vulnerability with a specific software vendor, going directly to that vendor's security portal often provides more actionable remediation guidance than the generic CVE entry.
Not every vulnerability can be definitively identified automatically. Some scanner findings are generic — "this service version may be vulnerable" rather than "this specific CVE exists on this system." These require manual verification: check the specific version, configuration, and patch state of the affected service against the referenced CVE to determine whether the system is actually vulnerable. The scanner provides the lead; verification provides the answer.
Vulnerability Classification — Application, Web, and Network Scans
Vulnerability scanners classify their findings by the type of target environment. Understanding which scan type produced a finding affects how it is interpreted and remediated.
Application scans target desktop software and mobile applications, identifying issues such as outdated software libraries with known CVEs, insecure default configurations, weak cryptographic implementations, and insecure data storage practices in mobile apps. These findings often require coordination with software development teams or vendor update cycles.
Web application scans analyze software running on web servers, looking for vulnerabilities such as SQL injection, cross-site scripting (XSS), authentication flaws, insecure session management, and misconfigured access controls. Web application findings are frequently critical because they affect internet-facing systems that are directly reachable by external attackers.
Network scans examine infrastructure devices and communication paths: open ports with vulnerable services, misconfigured firewalls that expose internal systems, unpatched network devices (routers, switches, VPN concentrators, load balancers), and unauthorized devices connected to the network. Network scan findings often require coordination between security and network operations teams. The effectiveness of all three scan types depends directly on the quality and currency of the vulnerability signature database the scanner is using.
Exposure Factor — Quantifying Business Impact
The exposure factor measures the potential loss of value or business functionality if a vulnerability is successfully exploited, expressed as a percentage of the total asset value or service capacity affected. It is a way of connecting the technical severity of a vulnerability (captured in CVSS) to the business impact of its exploitation (specific to the organization and service in question).
A vulnerability that might limit access to a service 50% of the time — a small DDoS vulnerability that throttles but does not eliminate availability — has a 50% exposure factor. A vulnerability that could completely disable a service or destroy all data on an asset has a 100% exposure factor. A vulnerability that affects only a small subset of functionality might have a 10% exposure factor. The exposure factor is used in formal risk calculations (Single Loss Expectancy = Asset Value × Exposure Factor) and more informally to help prioritize remediation: vulnerabilities with higher exposure factors — those that can cause maximum business harm — generally receive higher remediation priority, all else being equal.
Environmental Variables — Context Changes Priority
Two identical vulnerabilities in two different environments can have dramatically different risk profiles. A critical vulnerability in a database server that is directly internet-facing on a public cloud demands immediate remediation. The same critical vulnerability on a development workstation in an isolated lab with no network connectivity to anything external may tolerate a longer remediation cycle. The vulnerability is the same; the environment changes everything about the urgency.
Environmental variables to consider when prioritizing: Network exposure — is the system reachable from the internet, from the internal network only, or from a completely isolated test environment? User base — how many users does this system serve, and are they internal employees or external customers? A vulnerability on a public-facing customer portal affects more people and causes more reputational damage than the same vulnerability on an internal tool. Revenue impact — is this system part of a revenue-generating application whose downtime has direct financial consequences? Exploitability — is this a well-publicized vulnerability with publicly available exploit code, or a theoretical weakness requiring sophisticated attack? Publicly available exploit code dramatically elevates urgency regardless of other factors.
Industry and Organizational Impact
The organizational type is a critical contextual variable. The same ransomware attack that causes a software company to scramble for a week can close a hospital for two weeks while patients are diverted to other facilities and scheduled surgeries are canceled — as happened to Tallahassee Memorial HealthCare in February 2023. The same DDoS vulnerability that disrupts a retailer's website for a day can disrupt power distribution monitoring for a utility, as seen in attacks against power utilities in Salt Lake City and Los Angeles County in March 2019.
Critical infrastructure organizations — healthcare, energy, water, financial services — face both heightened consequences from successful attacks and heightened regulatory pressure to maintain security. For these organizations, vulnerability analysis must account not just for the technical severity of a finding but for the operational and public-safety consequences of exploitation. A medium-CVSS vulnerability in a system that controls patient medication delivery or power grid switching may require immediate remediation that would be a lower priority in a different context.
Risk Tolerance — The Patching Dilemma
Risk tolerance describes how much risk an organization is willing to accept during the window between discovering a vulnerability and completing remediation. Completely eliminating all vulnerability risk is practically impossible — new vulnerabilities are published continuously, and patching takes time. Organizations must accept some level of ongoing vulnerability exposure as a normal operational condition.
The central tension in vulnerability remediation is the patching timeline. Applying a patch immediately after release minimizes the exposure window, but a patch that has not been tested in the organization's environment may introduce compatibility issues, break dependent applications, or cause service disruptions. Testing takes time — and during testing, the system remains vulnerable. Applying a patch without adequate testing exchanges vulnerability risk for operational risk. The organization must decide how much testing is enough given the severity of the vulnerability.
Risk tolerance is not a fixed value — it changes based on severity. A critical vulnerability affecting internet-facing systems with a publicly available exploit may justify compressing the testing cycle dramatically: patch within hours of testing in a staging environment, accept the small operational risk of a less-thorough test. A low-severity vulnerability on an internal system with no publicly available exploit can tolerate the full standard patch and test cycle. Most organizations maintain tiered remediation SLAs: Critical vulnerabilities remediated within 24–72 hours; High within 7–14 days; Medium within 30 days; Low addressed in the next scheduled maintenance window. The right tolerance for any given finding is the product of its CVSS score, exposure factor, and environmental context.