Vulnerability Management Basics

The security-controls lesson named "patch management" only in passing. This lesson covers the full lifecycle behind it — how organizations actually find, prioritize, and fix vulnerabilities at scale, directly setting up Path 08's cloud-specific vulnerability management lesson later in this course.

What a vulnerability actually is, revisited

The threats-risk lesson already defined vulnerability as a weakness that could be exploited. This lesson covers how organizations systematically find and track them, rather than discovering them one at a time by accident.

CVE: a shared, standardized naming system

A CVE (Common Vulnerabilities and Exposures) identifier is a unique, standardized name assigned to a specific, publicly known vulnerability — CVE-2021-44228 (the notorious Log4Shell vulnerability) is a real example. This shared naming system means security teams, vendors, and researchers worldwide can all refer to the exact same vulnerability unambiguously, rather than each describing it differently.

CVSS: scoring how bad a vulnerability actually is

The CVSS (Common Vulnerability Scoring System) assigns a numeric severity score (0–10) to a vulnerability, based on factors like how easy it is to exploit, whether it requires authentication, and what impact successful exploitation has:

CVSS 4.0 is the current version. Its Base metrics distinguish impact on the vulnerable system from impact on subsequent systems. Threat metrics include exploit maturity; Environmental metrics adapt the assessment to a deployment; Supplemental metrics add context without changing the score. Older reports commonly use CVSS 3.1. Always include the version and vector so the score is reproducible. Try the KashSec CVSS 4.0 + 3.1 calculator, which keeps 3.1 available for historical examples.

0.1–3.9   Low
4.0–6.9   Medium
7.0–8.9   High
9.0–10.0  Critical

Path 08's cloud-vulnerability-management lesson makes this point directly for cloud environments, and it's just as true generally: a critical CVSS score on a system properly isolated by segmentation (Path 02, Path 24) is a genuinely different real-world priority than a medium-severity vulnerability on a system directly exposed to the internet. CVSS measures theoretical severity, not your specific, actual exposure.

The vulnerability management lifecycle

  1. Discovery — finding vulnerabilities through scanning tools, vendor advisories, or security research
  2. Prioritization — combining CVSS score with actual exposure and business context (exactly the exposure-based reasoning from Path 08)
  3. Remediation — patching, reconfiguring, or applying a compensating control (directly connecting to Path 03's package-management lesson and Path 07's Windows-patching coverage)
  4. Verification — confirming the fix actually worked and didn't introduce a new problem
  5. Reporting — tracking metrics over time (covered directly in this path's upcoming security-metrics lesson) to show whether the overall program is actually improving

Why "just patch everything immediately" doesn't scale

A large organization might have thousands of systems and hundreds of newly disclosed vulnerabilities every month — patching everything instantly, without any prioritization, is both operationally unrealistic and often unnecessary, since not every vulnerability poses equal real-world risk to that specific organization. This is exactly why prioritization (step 2 above) is the genuinely hard, judgment-intensive part of vulnerability management, not just a formality.

Why might a security team choose to patch a "Medium" CVSS-scored vulnerability before a "Critical" one, given everything covered in this lesson?

Show answerCVSS scores measure a vulnerability's theoretical severity in isolation, not its actual exploitability within a specific organization's real environment. A "Critical" vulnerability on a system with no network access to it at all (properly segmented, per Path 02 and Path 24) presents genuinely lower real-world risk than a "Medium" vulnerability sitting on a system directly reachable from the internet with no compensating controls in place — an attacker simply can't reach the first system to exploit it, regardless of how severe the underlying flaw theoretically is. A mature vulnerability management program prioritizes based on actual exposure and business context combined with CVSS score, not CVSS score alone — exactly the same exposure-based reasoning Path 08 applies specifically to cloud environments, generalized here to vulnerability management as a whole.

Key terms

  • CVE (Common Vulnerabilities and Exposures) — a standardized, unique identifier for a specific publicly known vulnerability.
  • CVSS (Common Vulnerability Scoring System) — a numeric score (0-10) representing a vulnerability's theoretical severity.
  • CVSS vector — the versioned metric choices that produced the score; publish it alongside the number.
  • Vulnerability management lifecycle — the ongoing process of discovering, prioritizing, remediating, verifying, and reporting on vulnerabilities.

Recap

  • CVE provides a shared, unambiguous naming system for known vulnerabilities; CVSS provides a standardized severity score.
  • CVSS score alone doesn't determine real-world priority — actual exposure and business context matter just as much, echoing Path 08's cloud-specific coverage of the same principle.
  • The vulnerability management lifecycle (discover, prioritize, remediate, verify, report) is how organizations manage vulnerabilities systematically at scale, rather than reactively one at a time.

Next up → Attackers & the kill chain