Vulnerability Intelligence Explained: The Five-Question Model Behind Every Finding
Log4Shell taught the industry an expensive lesson: patching is never truly finished. A vulnerability finding is not a point-in-time assessment, it is a continuous evaluation. And it answers five questions in order, every time. Understanding those five questions separates teams that prioritize effectively from teams that chase false alarms while real threats slip through.
What is a vulnerability finding, actually?
A vulnerability finding answers five questions in order:
- What software is running on this CI (Common Platform Enumeration)?
- Is there a known flaw in that software (CVE)?
- How damaging is that flaw (CVSS score)?
- How likely is it to actually be exploited (EPSS probability)?
- Is it being exploited in the wild right now (CISA KEV / exploit maturity)?
Everything below is just those pieces in detail. The two that do the matching work are CVE and CPE; the rest are enrichment that makes a finding useful to act on.
What is a CVE, the flaw’s identity?
CVE stands for Common Vulnerabilities and Exposures. It is a unique ID for one specific, publicly disclosed security flaw, like CVE-2025-0810. The format is CVE-<year>-<number>. It is maintained by MITRE (US-government-funded), and it is just an identifier plus a description.
A CVE by itself carries no score and no severity, it only says this particular flaw exists and here is what it is. Think of it as the flaw’s passport number. Everything else (how bad, what is affected) gets attached to it by other systems.
What is a CPE, and why does it matter?
CPE stands for Common Platform Enumeration. This is a rigid, standardized way to name a piece of software, hardware, or OS so that everyone spells it the same way. Real-world names are chaos, Chrome, Google Chrome, chrome browser, and you cannot match against chaos.
CPE forces one canonical form:
cpe:2.3:a:google:chrome:119.0.6045.199:*:*:*:*:*:*:*
That is vendor:google, product:chrome, version:119.0.6045.199. CPE is the join key of the whole system. It is how the software running on this customer server gets connected to the flaws known to exist.
How do CVE and CPE connect, version ranges?
A single CVE affects specific versions of specific products, expressed as CPEs with version ranges. CVE-2025-0810 might say: affects google:chrome from version 119.0.0.0 up to (but not including) 119.0.6045.199. So the matching question is never does this exact string appear, it is does this CI version fall inside an affected range?
That range comparison is the core of the matching engine, and it is why the fixed version matters to a user: the top of the affected range is essentially upgrade past here and you are safe. Except, as Log4Shell showed, sometimes you are not.
What are the four severity signals?
This is the part people conflate, so it is worth separating clearly. A finding carries up to four signals, and they are not redundant:
CVSS: How bad is the flaw?
CVSS stands for Common Vulnerability Scoring System. A 0-10 score of how bad the flaw is if exploited. v3.1 is most common. It comes with a vector string that decomposes the score (e.g., CVSS:3.1/AV:N/AC:L/… tells you it is network-exploitable, low complexity, etc.). The number maps to bands: Critical (9-10), High (7-8.9), Medium (4-6.9), Low (0.1-3.9).
EPSS: How likely is it to be exploited?
EPSS stands for Exploit Prediction Scoring System. A probability (0-1) that this CVE will be actually exploited in the wild in the next ~30 days. This is the crucial complement to CVSS: a flaw can be a scary 9.8 CVSS but have near-zero EPSS (nobody is bothering to exploit it), while a medium 6.5 with high EPSS is a fire you should put out today.
KEV: Is it being exploited right now?
KEV stands for Known Exploited Vulnerabilities, a catalog maintained by CISA (US cyber agency) of CVEs confirmed to be exploited in the real world right now. In the schema it is essentially a boolean flag (kev_flag) plus the date it was added. If a CVE is on the KEV list, it jumps to the top of anyone fix queue, this is the strongest drop everything signal.
Exploit maturity: How ready-to-use is the attack?
How developed and available a working exploit is, on a ladder: NONE → POC (proof-of-concept exists) → WEAPONIZED (reliable, packaged) → ACTIVE (in active use). This is the nuance between theoretically exploitable and there is a point-and-click tool for it.
Why all four signals matter together
The reason the feature surfaces all four is that security teams prioritize on their combination: high CVSS and high EPSS and on the KEV list = unambiguous emergency; high CVSS alone might be background noise. Your security team needs to see all of them, not just one score.
Where does this data come from?
CVEs and their enrichment do not come from one place; the feature pulls them from providers:
NVD (National Vulnerability Database): NIST database that takes raw CVEs and enriches them with CVSS scores and CPE mappings. It is the classic free public source, authoritative but historically slow and, in recent years, backlogged.
VulnCheck: A commercial vulnerability-intelligence provider, think NVD++: the same CVE data but enriched faster and with extra intel (exploit availability, KEV context, etc.).
Different providers disagree on scores and affected ranges. The architecture keeps every provider view rather than trusting one blindly.
Log4Shell: When all four signals screamed at once
The disclosure of Log4Shell in December 2021 demonstrated why a single fix date does not mean a permanently fixed system. Here is the full chain:
Apache Log4j version 2.14.1 contained a critical remote code execution vulnerability assigned CVE-2021-44228 with a maximum CVSS score of 10.0. Within days of the December 2021 disclosure, security operations teams rushed to deploy version 2.15.0, which disabled Java Naming and Directory Interface (JNDI) lookups by default.
Within days, researchers proved version 2.15.0 remained vulnerable to denial of service attacks in non-default configurations. MITRE issued CVE-2021-45046, and Apache released version 2.16.0. Days later, security analysts discovered version 2.16.0 still allowed infinite recursion loop attacks, prompting CVE-2021-45105 and version 2.17.0. Before the year closed, a fourth vulnerability, CVE-2021-44832, forced organizations to deploy version 2.17.1.
Those four CVEs carried:
- CVSS 10.0 (maximum damage possible)
- EPSS ~0.94 (94% probability of exploitation, near the very top of all CVEs)
- KEV-listed (CISA confirmed it was being exploited in the wild)
- ACTIVE exploit maturity (public exploit code and a Metasploit module within days)
Organizations that treated version 2.15.0 as permanently fixed marked remediation tickets closed and moved on. But every signal was screaming: this chain was not over. Hosts stuck in intermediate patch states sat unmonitored while active exploit attempts targeted secondary vectors. A security team looking at that finding saw CVSS 10 and EPSS 0.94 and KEV-listed and ACTIVE, every single signal at once. That is the unambiguous patch this tonight case. Most real findings light up only one or two of these signals, which is precisely why showing all of them matters, it is what lets a team tell a genuine emergency apart from a scary-looking 10.0 that nobody is actually exploiting.
Vulnerability intelligence vocabulary
Here is the whole vocabulary as a one-screen reference:
| Term | Full name | Answers |
|---|---|---|
| CVE | Common Vulnerabilities and Exposures | Which flaw? |
| CPE | Common Platform Enumeration | Which software? (the join key) |
| CWE | Common Weakness Enumeration | What kind of flaw? |
| CVSS | Common Vulnerability Scoring System | How bad? |
| EPSS | Exploit Prediction Scoring System | How likely? |
| KEV | Known Exploited Vulnerabilities (CISA) | Being used today? |
| Exploit maturity | , | How ready is the attack? |
| NVD | National Vulnerability Database (NIST) | Where from? (free) |
Why patching once is not patching done
A configuration item verified safe today can become vulnerable tomorrow when a vulnerability database expands its affected version range. Static CMDB discovery cannot protect production systems against dynamic vulnerability re-escalations, treating a closed change ticket as a permanent state is one of the most common failure modes in enterprise vulnerability management today.
Continuous vulnerability matching between infrastructure records and evolving CVE data matters more than a one-time patch check. When a vulnerability database updates its affected version ranges, the matching engine runs an automated evaluation pass across stored software keys, without triggering intrusive host scans. A CI whose version falls within a newly expanded risk boundary gets flagged immediately, not at the next quarterly scan.
Book a demo to see how ViVID helps you stay on top of real time threat intelligence and keeps you updated on latest patch info to keep your IT estate fully secure.
