Vulnerable Software Explained: CVE, CVSS and Patching for Security+

Vulnerable software is software containing a flaw an attacker can exploit. The exam is less interested in the flaws themselves than in how you find them, how you decide which ones matter, and what you do when patching is not an option.

The identifiers

CVE — Common Vulnerabilities and Exposures. A unique identifier for a publicly known vulnerability, in the form CVE-2024-12345. It is a name, not a score; it says nothing about severity.

CVSS — Common Vulnerability Scoring System. A 0 to 10 score reflecting technical severity, built from base metrics such as attack vector, complexity, required privileges and impact on confidentiality, integrity and availability. Ratings run None, Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), Critical (9.0–10.0).

CWE — Common Weakness Enumeration. The class of flaw rather than a specific instance: buffer overflow, SQL injection, improper authentication. A CVE is an instance; a CWE is the category.

CPE — a standard naming scheme for products and versions, which is how scanners match what you run against known vulnerabilities.

Why CVSS alone is a poor priority list

This is the point CySA+ presses hardest, and Security+ now echoes it.

CVSS measures theoretical severity in isolation. It does not know whether the affected system is internet-facing or on an isolated lab segment, whether it holds regulated data, or whether anyone is actually exploiting the flaw.

Patching strictly by CVSS means a critical rating on an offline test box outranks a high rating on your public payment system. Real prioritisation combines severity with asset criticality, exposure, data sensitivity and exploit likelihood. EPSS provides that last input by predicting the probability of exploitation in the wild, and it changes the ordering substantially — most critical CVSS scores are never exploited at scale.

KEV, the Known Exploited Vulnerabilities catalogue, is the blunt version: if a vulnerability is on it, it is being exploited now, and it goes to the front of the queue.

Categories of vulnerable software

Unpatched software. A fix exists and has not been applied. The largest category of real-world compromise, and the least excusable.

Zero-day. No patch exists because the vendor does not yet know, or has not yet fixed it. You cannot patch, so the answer is compensating controls: segmentation, monitoring, virtual patching at a WAF or IPS, and reducing exposure.

End-of-life and end-of-support. The vendor has stopped issuing fixes, so every new flaw is permanent. Exam distinction: end-of-life means no longer sold, end-of-support means no longer patched. End-of-support is the security problem.

Legacy systems. Still running, often business-critical, frequently unpatchable because the application or a certification depends on the exact configuration. Medical and industrial equipment is the classic case.

Third-party and open-source dependencies. Your own code may be sound while a library three levels down is not. This is where an SBOM earns its keep — you cannot patch what you do not know you ship.

Misconfiguration. Default credentials, unnecessary services, permissive shares. No patch applies, because the software is working as designed.

Finding it

Credentialed scans see installed versions and patch levels and produce far fewer false positives; uncredentialed scans see what an unauthenticated attacker sees. Agent-based scanning covers devices that are rarely on the network. Software composition analysis inspects dependencies. Penetration testing confirms whether a finding is actually exploitable — the difference between a scanner's claim and a demonstrated exploit.

Expect false positives, and validate before raising an emergency change.

When you cannot patch

The realistic scenario, and a common question. Segment the system so it can only reach what it must. Restrict access tightly. Increase monitoring around it, since detection is what you have left. Apply virtual patching at a WAF or IPS to block the exploit pattern in transit. Remove the exposure entirely if it does not need to be reachable. And document the residual risk with the system owner's formal acceptance.

Patch management as a process

Inventory first, because you cannot patch unknown assets. Then test in a representative environment, deploy in rings so a bad patch does not take out everything at once, keep a rollback plan, and verify afterwards that the patch actually applied. Emergency patching for actively exploited flaws is a separate, faster path that should be defined before you need it.

What to remember

CVE names, CVSS scores, CWE categorises. CVSS alone is a bad priority order — combine it with exposure, asset criticality and exploit likelihood via EPSS or KEV. End-of-support means permanently unpatchable. When you cannot patch, compensate with segmentation, monitoring and virtual patching, and record accepted risk.

Related reading: EPSS · SBOM · Mean time to remediate