Analyzing Vulnerabilities — Glossary

A vulnerability scanner finding that investigation reveals does not actually exist on the target system. The scanner matched a signature pattern and reported a vulnerability, but the system is not genuinely vulnerable — the patch has already been applied, the exploitable configuration does not exist, or the signature is imprecise. False positives waste analyst time and can cause operational disruption if acted upon (patching a system for a vulnerability it does not have). Critical distinction (exam-tested): a false positive is not the same as a low-severity real vulnerability. A low-severity finding is a real vulnerability that simply is not urgent — it should remain in the tracking system. Calling a real low-severity finding a "false positive" and closing it removes a genuine risk from oversight.

A vulnerability that genuinely exists on a system but was not detected by the vulnerability scanner, and therefore does not appear in the scan report. The most dangerous type of scan error because it creates a blind spot: the organization believes the system is safe when it is not, and neither patches the vulnerability nor monitors for exploitation of it. Primary cause: the scanner's signature database does not contain a signature for the specific vulnerability, either because the vulnerability was published after the last signature update or because the scanner lacks signatures for the specific software configuration. Primary defense: keep scanner signatures updated before every scan. More dangerous than a false positive because it leaves real risk unrecognized.

The database of detection patterns used by a vulnerability scanner to identify specific weaknesses on target systems. Each signature describes how to detect a particular vulnerability: which software version, which configuration condition, which network response indicates that the vulnerability is present. A scanner can only detect vulnerabilities for which it has signatures — a newly disclosed vulnerability with no signature is invisible to the scanner, producing a false negative. Keeping signatures current is the foundational maintenance requirement for vulnerability scanning: before every scan, update signatures to the latest available database. For specialized or custom environments, work with the scanning vendor to develop environment-specific signatures.

The industry-standard framework for quantifying the severity of security 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 factors including: access vector (network, adjacent, local), attack complexity, authentication requirements, and the impact on confidentiality, integrity, and availability. Scores are published in the National Vulnerability Database (nvd.nist.gov). Version distinction (exam-tested): CVSS 2.0 and CVSS 3.x use different scoring methodologies and may produce different scores for the same vulnerability. Both scores may appear in a vulnerability report; note the version. The current industry standard is CVSS 3.x.

The U.S. government repository of vulnerability data maintained by NIST (National Institute of Standards and Technology), available at nvd.nist.gov. The NVD synchronizes with the CVE list maintained by MITRE and adds CVSS scores, severity ratings, and enhanced search capabilities. Security professionals use the NVD to look up details on any CVE, understand its severity score, review affected software versions, and find links to vendor patches and advisories. Most vulnerability scanners report findings with direct CVE references that can be cross-referenced in the NVD. Also hosts the CVSS calculator for computing scores for newly disclosed vulnerabilities.

A standardized identification system for publicly known security vulnerabilities. Each CVE entry assigns a unique identifier (formatted as CVE-YEAR-NUMBER) to a specific vulnerability, enabling consistent cross-referencing across scanners, databases, vendor advisories, and patches. The CVE list is maintained by MITRE at cve.mitre.org/cve. Vulnerability scanners report CVE numbers with their findings so analysts can look up technical details in any CVE-aware database. CVE identifiers are the common language of vulnerability management: a CVE number found in a scanner report, a threat intelligence feed, a vendor advisory, and a patch release all refer to the same specific vulnerability.

The categorization of vulnerability scanner findings by target environment type. Three primary categories: Application scans — desktop software and mobile applications; finds outdated libraries, insecure configurations, weak cryptographic implementations. Web application scans — software running on web servers; finds SQL injection, XSS, authentication flaws, insecure session management. Network scans — infrastructure devices and communication paths; finds open ports with vulnerable services, misconfigured firewalls, unpatched network devices, and unauthorized systems. Classification matters for remediation routing: web application findings go to the development team; network findings go to network operations; application findings go to IT operations or software teams.

A measure of the potential loss of value or business functionality if a vulnerability is exploited, expressed as a percentage (0% to 100%). An exposure factor of 50% means the vulnerability could affect half the system's operational capacity or value — for example, a DDoS vulnerability that throttles but does not eliminate a service. An exposure factor of 100% means the vulnerability could cause total loss of the asset or service — for example, a buffer overflow that completely disables a system or destroys its data. Used in formal risk calculations: Single Loss Expectancy (SLE) = Asset Value × Exposure Factor. A key input to vulnerability prioritization: high exposure factor findings cause more business harm when exploited, warranting higher remediation priority even if CVSS scores are similar.

Contextual factors about the system hosting a vulnerability that affect its real-world risk level beyond what CVSS scores capture. Key variables: Network exposure — internet-facing (highest risk), internal-only, or isolated test lab (lowest risk); User base — external customers vs. internal employees; number of users affected; Revenue dependency — whether system downtime directly impacts revenue; Exploitability in context — whether public exploit code exists for the specific configuration. Environmental variables explain why the same CVE can be a Critical-priority remediation in one organization and a Low-priority in another: the CVSS score is universal, but the risk to a specific organization depends on its specific environment.

The amount of risk an organization is willing to accept during the window between vulnerability discovery and completed remediation. Completely eliminating vulnerability risk is impractical: new vulnerabilities appear continuously and patching takes time. Risk tolerance determines how quickly an organization must patch a given vulnerability and how much testing is required before deployment. The core tension: patching immediately minimizes exposure but may skip testing, introducing operational risk; delaying to test thoroughly minimizes operational risk but extends the vulnerability window. Risk tolerance is not fixed — it changes with severity. Critical vulnerabilities on internet-facing systems may justify compressing the test cycle; low-severity vulnerabilities on isolated systems can wait for the next maintenance window.

The process of ordering identified vulnerabilities by remediation urgency, accounting for multiple factors: CVSS severity score, exposure factor, environmental context (internet-facing vs. internal vs. isolated), exploitability (public exploit code available vs. theoretical), organizational impact (critical infrastructure vs. general IT), and the organization's risk tolerance. Not all vulnerabilities can be patched simultaneously; prioritization ensures that limited remediation resources are applied to the highest-risk findings first. Industry standard tiered SLAs: Critical (24–72 hours), High (7–14 days), Medium (30 days), Low (next maintenance window). Vulnerability databases and public disclosures help by providing independent severity ratings that most organizations use as starting points before applying contextual factors.

The principle that identical vulnerabilities can produce dramatically different consequences depending on the type of organization affected. Healthcare organizations, utilities, financial institutions, and government agencies face elevated consequences because their systems support public safety and critical infrastructure. Examples: Tallahassee Memorial HealthCare (February 2023) — ransomware closed the facility for two weeks, diverting emergency cases and canceling surgeries; power utilities in Salt Lake City and Los Angeles County (March 2019) — DDoS attacks exploiting unpatched vulnerabilities disrupted operational systems. The organizational type is a required input to vulnerability analysis: a finding that is Medium priority for a software company may be Critical for a hospital or utility serving the same software.