The Math Behind Our CVE Scoring Model

Beyond CVSS: A Data-Driven Approach

CVSS is a useful baseline, but it was designed as a static severity rating, not a dynamic risk predictor. Our scoring model adds temporal and contextual layers that evolve as new intelligence arrives.

The Problem With Static Scores

When a CVE is first published, its CVSS score is calculated based on the vulnerability's technical characteristics. This score never changes (within a major CVSS version). But the real-world risk of a vulnerability is anything but static:

• Day 1: CVE published. No exploit exists. Risk is theoretical.
• Day 7: A researcher publishes a proof-of-concept on GitHub. Risk increases.
• Day 14: The PoC is weaponized into a Metasploit module. Risk spikes.
• Day 21: CISA adds the CVE to the KEV catalog. Risk is confirmed.
• Day 60: Most organizations have patched. Risk decreases for updated systems.

A static CVSS 9.8 can't capture this lifecycle. Our model can.

Signal Inputs

Our scoring model ingests multiple data streams:

1. Vulnerability Metadata

• CVSS base score and vector (attack surface characteristics)
• CWE type (what class of vulnerability, injection, overflow, auth bypass, etc.)
• Affected product and version ranges
• Vendor patch availability and timeline

2. Exploit Intelligence

• Proof-of-concept availability (GitHub, ExploitDB, Packet Storm)
• Metasploit/Nuclei module existence
• Exploit maturity classification (theoretical → PoC → weaponized → in-the-wild)

3. Threat Context

• EPSS probability score (machine-learned exploitation likelihood)
• KEV catalog status (confirmed exploitation)
• Mentions in threat intelligence feeds and dark web forums
• Social media velocity (how fast security researchers are discussing it)

4. Temporal Factors

• Days since publication
• Days since last EPSS score change
• Patch availability duration
• Vendor response time patterns

The Scoring Algorithm

Our unified risk score combines these signals using a weighted ensemble approach:

risk_score = w1 × severity_component
           + w2 × exploitability_component
           + w3 × temporal_component
           + w4 × context_component

Severity Component, derived from CVSS, normalized to 0–1. Accounts for attack vector, complexity, and impact scope. This is the baseline.

Exploitability Component, a composite of EPSS score, exploit code availability, and exploit maturity level. A CVE with a working Metasploit module scores much higher here than one with only a theoretical description.

Temporal Component, models the CVE lifecycle using a sigmoid decay function. New CVEs with active exploitation signals score high. Old CVEs with available patches and no recent exploitation activity score low. The curve is calibrated against historical exploitation data.

Context Component, this is where infrastructure matching happens. A critical CVE in software you don't run contributes zero. A medium CVE in your exact version of your most exposed service contributes heavily.

Feature Engineering

Some of the more interesting features we've found predictive:

• CWE-to-exploit correlation: Certain vulnerability classes (e.g., CWE-78 OS Command Injection, CWE-502 Deserialization) have historically higher exploitation rates than others
• Vendor patch latency: The time between CVE publication and patch release correlates with exploitation window duration
• Description text signals: CVE descriptions containing terms like "unauthenticated," "remote," or "arbitrary code execution" correlate with higher exploitation rates
• Publication timing: CVEs published on Fridays or before holidays historically have longer exposure windows

Model Validation

We validate our model against historical data using three key metrics:

• Precision: Of the CVEs we flag as high-risk, what percentage were actually exploited? Higher precision means fewer false positives.
• Recall: Of the CVEs that were actually exploited, what percentage did we flag? Higher recall means fewer missed threats.
• Lead time: How far in advance of confirmed exploitation (KEV listing) did we flag the CVE as high-risk?

We optimize hardest for recall. Missing a real threat is worse than over-alerting on a few false positives. We publish our validation results as they mature, we'd rather share real numbers than impressive-sounding ones.

Continuous Calibration

The model isn't static. We recalibrate against the latest exploitation data as the threat landscape evolves. Attack patterns change, what worked for exploitation prediction in 2024 may not hold in 2027. Continuous calibration keeps the model aligned with reality.

Why This Matters For You

When you receive an alert from our platform, it's not just "this CVE has a high CVSS score." It's "this CVE has a high probability of being exploited, it affects your specific stack, and you should act within X days based on historical patterns."

That's the difference between a scoring system and an intelligence system.