Guides

Vulnerability Management: CVEs, KEV, Patching and Verification

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

Vulnerability management is the defender loop: find weaknesses (often tracked as CVEs), prioritise what matters (CVSS plus CISA KEV and asset value), patch or mitigate, then verify the fix with evidence. Scanning alone is not a program — owned SLAs and re-checks keep Equifax-style unpatched disasters from repeating.

Inventory → Discover → Prioritise (KEV/CVSS/asset) → Fix → Verify → Improve
Scan without owner = PDF wallpaper
Patch without verify = hope

What do I need before this guide?

• Idea of what a security update is on Windows / Linux.
• Optional: How to use nmap ethically (authorised scanning only).
• Optional: Incident response first 24 hours.

What are CVE, CVSS and KEV?

1. CVE — Common Vulnerabilities and Exposures: a public ID for a known flaw (example shape: CVE-2021-44228).
2. CWE — weakness class (for example injection, broken auth) — helps group root causes.
3. CVSS — score / vector that estimates severity; useful but not the only signal (context matters).
4. KEV — CISA Known Exploited Vulnerabilities catalog: flaws seen abused in the wild. Treat KEV hits on your estate as emergency queue work.
5. Advisory — vendor bulletin that says which builds are fixed.

Educational warning: any scanner or exploit research stays in your isolated lab or under written authorisation. No scanning neighbour networks or random public IPs.

Real incident: Equifax (2017) — unpatched known CVE

Public reporting on the Equifax 2017 breach described attackers abusing a known Apache Struts vulnerability after a patch was already available. Massive personal data exposure followed, with long regulatory and trust fallout.

Takeaways (vertical):

1. What happened — known CVE; patch existed; exploitation window stayed open.
2. What went wrong (theme) — inventory / patch SLA / verification culture failed under real complexity.
3. Care-take — internet-facing apps need faster patch clocks than interior printers.
4. Care-take — “scanner green last quarter” is not continuous assurance.
5. Care-take — track KEV-class items with executive visibility.
6. Bonus parallel — WannaCry (2017) showed wormable unpatched Windows estates collapsing in days.

Where does KEV fit next to CVSS?

1. CVSS answers “how bad could this be in a generic model?”
2. KEV answers “are defenders already seeing this abused?”
3. Asset context answers “does our exposure make it urgent?”
4. Use all three — never CVSS alone, never “internet blog severity” alone.
5. If a KEV item does not apply to your software list, document the exclusion with inventory proof.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

• Race defenders between public CVE disclosure and your patch window.
• Focus on forgotten internet-facing apps and abandoned admin panels.
• Chain a medium CVE with weak credentials (high-level idea only).

Blue Team — defend, detect, respond

• Maintain asset inventory tied to owners.
• Prioritise KEV + exposed criticals; document exceptions with expiry dates.
• Patch pipelines with staged rings and rollback plans.
• Verify with authenticated re-scans and version evidence in tickets.
• Watch exploit-attempt noise in WAF / IDS after big CVE news (detection, not offence).

How do I run the loop step by step?

Step 1 — Build a usable inventory

1. List servers, endpoints, cloud accounts, containers, and critical SaaS.
2. Record owner, data class, and internet exposure.
3. For a Nashik grape exporter SMB: start with Microsoft 365, one public website host, and finance laptops — not “every IoT bulb”.

Step 2 — Discover findings safely

1. Prefer authenticated vulnerability scans on systems you own / are authorised to test.
2. Pull OS vendor channels and language dependency alerts (npm / pip / Maven, etc.).
3. Subscribe to CISA KEV updates and major vendor PSIRTs.
4. Deduplicate scanner noise; mark false positives with evidence.

Step 3 — Prioritise like a defender

1. Is it on KEV? Escalate.
2. Is the asset internet-facing or holding personal / payment data?
3. Is a reliable fix available? If not, plan a compensating control (WAF rule, disable feature, segment).
4. Write an SLA: for example KEV on exposed assets in days, not months.

Step 4 — Patch or mitigate

1. Stage in test → pilot → broad.
2. Read vendor notes for breaking changes.
3. Prefer supported upgrade paths over forever “hotfix folklore”.
4. Temporary mitigations must have an expiry and owner.

Step 5 — Verify (the step students skip)

1. Confirm package / build version on a sample of hosts.
2. Re-scan the same authenticated policy; expect the CVE to clear.
3. Attach screenshots or CLI evidence to the ticket.
4. If still open: wrong asset, incomplete cluster, or scanner plugin lag — investigate, do not close blind.

Step 6 — Measure and improve

1. Open aging by severity.
2. Mean time to remediate for KEV.
3. Recurring CVE families → root-cause (old base image, abandoned app).
4. Tabletop: “KEV drops Friday evening — who patches?”

Step 7 — Communicate without fear theatre

1. Tell leadership: exposed KEV count, age of oldest critical, next patch window.
2. Tell engineers: exact packages and rollback owners — not only a severity colour.
3. Tell auditors: evidence of verify, not only “we scanned”.
4. After a mass-CVE week, publish a short internal FAQ (what we run, what we patched, what remains).

Care-take — keep the program honest

1. Named owners per asset class.
2. Exception register with expiry (no eternal “risk accepted”).
3. Change windows and rollback tested once.
4. Dependency / container base images in the same program as VMs.
5. After big CVE weeks: hunt for exploit attempts in logs (blue detection).
6. Never celebrate “zero findings” from an unauthenticated scan of three hosts.

How do I fix common vuln-mgmt mistakes?

Ghabru naka 😅 — these are the usual ones: