Patch and Vulnerability Management
Most breaches exploit vulnerabilities that already had a patch — the failure is not unknown zero-days but known bugs left unpatched long enough for someone to walk in. Vulnerability management is the continuous cycle of discovering what is vulnerable, prioritizing by real risk, and remediating fast, especially on internet-facing systems where exploitation follows disclosure within hours.
This topic builds that cycle for Meridian and connects CVEs, scanning, and patch prioritization — turning ad-hoc patching into a measured program with deadlines that match the threat.
The Vulnerability Lifecycle
A bug is discovered, assigned a CVE, scored with CVSS, sometimes exploited (tracked by EPSS and the CISA known-exploited catalog), and patched. The defender's window is between disclosure and exploitation — and for internet-facing bugs that window is now measured in hours to days, which is why the response timeline for an exposed critical must be emergency, not routine.
Discovery — Scanning and Inventory
You cannot patch what you do not know you run, so an accurate asset inventory plus authenticated vulnerability scanning is the foundation — the same scanning from Chapter 5, now turned inward. The classic breach entry point is a forgotten, unmanaged system that never got scanned or patched, which is why closing inventory gaps matters as much as running the scanner.
Prioritization — Not All CVEs Are Equal
A queue of thousands of CVEs is triaged by exposure (is it internet-facing?), exploitability (is it in the known-exploited catalog or high on EPSS?), and impact. Patching the known-exploited internet-facing bug beats a theoretical critical on an isolated host — the same exploitability-over-CVSS point from Chapter 5's exploitation topic, applied to the patch queue. Prioritizing by raw CVSS alone drowns you in criticals while the actually-exploited bug waits.
Remediation and Compensating Controls
Patch, or — when you cannot patch immediately — mitigate: a virtual patch or WAF rule, disabling the feature, isolating the host. A documented compensating control is a legitimate interim step, not a skipped one. Meridian runs an emergency track for known-exploited internet-facing bugs, a regular cycle for the rest, and remediation deadlines by severity and exposure — so patching is a measured program with SLAs, not a scramble.
- Patching on a slow fixed cycle regardless of exploitation, so internet-facing known-exploited bugs sit open during their most dangerous window.
- Prioritizing by CVSS alone and ignoring exposure and real-world exploitation, drowning in "criticals" while the actually-exploited bug waits.
- Incomplete inventory, so unmanaged and forgotten systems never get scanned or patched — the classic breach entry point.
- Treating "can't patch yet" as "do nothing" instead of applying a documented compensating control.
- Unauthenticated-only scanning that misses the outdated packages an authenticated scan would find.
- Run authenticated vulnerability scanning against a complete asset inventory, continuously.
- Prioritize by exposure plus exploitation plus impact — the known-exploited catalog and EPSS, not raw CVSS — and give internet-facing known-exploited bugs an emergency track.
- Set and measure remediation deadlines by severity and exposure, and use compensating controls when a patch must wait.
- Automate patching where safe, and close the inventory gaps where forgotten systems hide.
- Assume internet-facing remote code execution is being exploited and respond in hours, not the quarterly cycle.
Knowledge Check
What causes most breaches — zero-days or known unpatched bugs?
- Known bugs that had a patch but stayed unpatched
- Unknown zero-days that no available patch could ever have stopped
- Physical hardware failures rather than any software bugs at all
- Cryptographic weaknesses in the TLS protocol itself
Why prioritize patching by exploitability and exposure rather than CVSS alone?
- A known-exploited exposed bug outranks a theoretical critical
- CVSS severity scores are effectively assigned at random
- Only internet-facing bugs are ever assigned a CVE identifier number
- Real-world exploitability data is never actually available
A critical internet-facing bug can't be patched for two days. What is the right interim step?
- Apply a compensating control: a WAF rule or host isolation
- Wait for the next scheduled patch cycle and do nothing in the meantime
- Quietly remove the affected host from the asset inventory
- Lower the bug's recorded CVSS score in the tracker
You got correct