How the EG score works
Every CVE gets two EchelonGraph numbers: an EG Score (0–10 severity, synthesized from NVD/CNA CVSS + CISA KEV + FIRST EPSS + GitHub Security Advisory + our own exploitation model) and an EG Risk (0–100 priority), shown with CISA's SSVC decision at each mission impact level. Both recompute automatically whenever a signal changes. This page documents the formula, the confidence rubric, and what we deliberately don't claim.
The signals we combine
NVD CVSS
Baseline technical score from the National Vulnerability Database. Computed from a fixed vector of attack characteristics — vector, complexity, privileges, scope, impact triad.
Limit: Static after publication. Does not reflect exploitation in the wild.
CISA KEV
CISA's Known Exploited Vulnerabilities catalog. Listing means CISA confirmed real-world exploitation. We floor the EG score at 9.0 for any KEV-listed CVE.
Limit: Reactive — only catches CVEs after exploitation has been observed and reported.
FIRST EPSS
Exploit Prediction Scoring System from FIRST.org. Probability (0–1) that a CVE will be exploited in the next 30 days, trained on real attack telemetry. We apply it continuously — a smooth ramp as probability climbs, not a single on/off threshold.
Limit: Recalculates nightly — freshly-published CVEs typically lack EPSS data for 24-48h.
GitHub Security Advisory
GHSA's vendor-curated CVSS. Often differs from NVD by 1-3 points because it incorporates vendor context (affected versions, exploit availability, patch status).
Limit: Only covers CVEs in software ecosystems GitHub tracks (npm, PyPI, Go, Maven, etc.). Infrastructure-only CVEs are not covered.
EchelonGraph exploitation model
Our own graduated pre-KEV exploitation signal (eg_kev), folding in exploit-code intelligence and other early indicators. It elevates risk before CISA formally lists a CVE, without waiting for the KEV catalog to catch up.
Limit: A confidence-scored prior, not a confirmation. Populated where we have supporting exploit intelligence; a no-op where we don't.
CISA SSVC
Stakeholder-Specific Vulnerability Categorization decision points — exploitation, automatability, technical impact. We run CISA's published SSVC tree in-house to derive the Act / Attend / Track* / Track decision at each mission impact level, since CISA publishes the inputs but not the decision.
Limit: Decision-point coverage is partial. Exploitation falls back to KEV, our exploitation model, and EPSS; technical impact to CVSS; an automatability CISA has not published stays unknown, and every decision it allows is shown.
The formula (rule order)
Rules evaluated in priority order. First match wins. Once a base score is set, a continuous EPSS modifier and our exploitation prior can lift it within band — and a genuinely fresher GHSA can revise it downward.
- 0
Rule 0 — Rejected
no score · severity: NONE · confidence: NONE
Triggers when: The CVE record has been REJECTED or withdrawn by its CNA / NVD.
Why: A withdrawn vulnerability is not a vulnerability. We suppress it to NONE instead of scoring it — and we suppress its critical-severity alert too. This alone corrected dozens of CVEs that were wrongly showing CRITICAL.
- 1
Rule 1 — KEV exploitation
max(CVSS, 9.0) · severity floor: CRITICAL · confidence: HIGH
Triggers when: CVE is listed on CISA KEV.
Why: Real-world exploitation is the strongest possible risk signal. A KEV-listed CVE with NVD CVSS 6.5 is still operationally critical.
- 2
Rule 2 — Continuous EPSS uplift
base CVSS lifted smoothly toward 9.0 as EPSS rises · confidence: HIGH near the top
Triggers when: There is a real CVSS base and EPSS exploit-probability is elevated.
Why: EPSS correlates strongly with actual exploitation. We ramp the score up as probability climbs — a monotone curve, no single 0.85 cliff — so a 0.60 and a 0.90 are treated differently. We never fabricate a base from EPSS alone.
- 3
Rule 3 — GHSA CVSS (both directions)
GHSA CVSS value · severity derived from score · confidence: MEDIUM-HIGH (depends on NVD agreement)
Triggers when: GHSA has published a CVSS for this CVE.
Why: GHSA incorporates vendor context that NVD often lacks. When GHSA is genuinely fresher than the NVD record, we honor it in both directions — including a downward revision — rather than only ever ratcheting up. The disagreement itself is signal.
- 4
Rule 4 — NVD baseline
NVD CVSS · severity derived from score · confidence: LOW (only one source)
Triggers when: Only NVD CVSS is available; no KEV listing, no EPSS, no GHSA.
Why: Honest fallback. Score equals NVD because we have no additional signal to synthesize. Marked LOW confidence and rendered as 'Aggregating' in the UI.
- 5
Rule 5 — No data
0 · severity: NONE · confidence: NONE
Triggers when: No CVSS from any source — typically a CVE in 'reserved' or 'awaiting analysis' state.
Why: We don't make up scores. The CVE shows as unscored until at least one source publishes.
Confidence rubric
Confidence is computed independently from score and tells you how much to trust the synthesis. A HIGH-confidence MEDIUM is more actionable than a LOW-confidence CRITICAL.
- • KEV-listed
- • EPSS ≥ 0.95
- • ≥3 sources agree within ±1.0
- • 2 sources agree within ±1.0
- • GHSA published <30 days
- • Completed NVD analysis
- • Only NVD signal
- • EPSS pending
- • Sources conflict
- • No CVSS from any source
The second number: EG Risk (0–100)
The EG Score answers how severe? on a 0–10 scale. But severity alone can't rank a queue — dozens of CVEs share a 9.8. So every CVE also carries EG Risk, a 0–100 priority number with the headroom to separate equal-severity vulnerabilities, plus CISA's SSVC decision at each mission impact level.
How EG Risk is computed
A transparent weighted fusion — no black box. Each component is normalized 0–1, weighted, and scaled to 0–100. The exact per-CVE breakdown is in the API's score_factors.eg_risk and in the hover card on every CVE.
- Severity — the EG Score, normalized45%
- Exploitation — KEV + our exploitation model + continuous EPSS40%
- Automatability — from the CISA SSVC decision15%
A KEV-listed, automatable 9.8 lands near 100; a dusty, never-exploited 9.8 lands in the 40s. Same severity, very different urgency.
The SSVC decision
We run CISA's Stakeholder-Specific Vulnerability Categorization tree in-house — CISA publishes the decision points but not the decision. What each decision means, in CISA's words:
- Act — Leadership-level attention; CISA recommends remediating as soon as possible.
- Attend — Supervisory-level attention; CISA recommends remediating sooner than standard update timelines.
- Track* — Monitor closely for changes; CISA recommends remediating within standard update timelines.
- Track — No action required at this time — track and reassess if new information appears; CISA recommends remediating within standard update timelines.
CISA's decision, by mission impact
SSVC is stakeholder-specific. Its fourth decision point, Mission & Well-being, belongs to whoever runs the vulnerable system, so a public page cannot pick it for you. Every CVE page therefore shows the decision at each level — for example, “Track at low or medium mission impact; Attend at high” — instead of one answer for everyone. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it: high means the affected system is essential to your organisation's mission, or its compromise could cause irreversible harm to people. Where CISA has not published a CVE's automatability, both values stay in play and the page lists every decision they allow.
| Exploitation | Automatable | Technical impact | Low | Medium | High |
|---|---|---|---|---|---|
| none | no | partial | Track | Track | Track |
| none | no | total | Track | Track | Track* |
| none | yes | partial | Track | Track | Attend |
| none | yes | total | Track | Track | Attend |
| public PoC | no | partial | Track | Track | Track* |
| public PoC | no | total | Track | Track* | Attend |
| public PoC | yes | partial | Track | Track | Attend |
| public PoC | yes | total | Track | Track* | Attend |
| active | no | partial | Track | Track | Attend |
| active | no | total | Track | Attend | Act |
| active | yes | partial | Attend | Attend | Act |
| active | yes | total | Attend | Act | Act |
The action is fix-aware. CISA's timing (as soon as possible / sooner than standard update timelines / within standard update timelines) is about applying a fix. When no fix is confirmed for a CVE, its page says so and tells you to restrict network exposure of the affected system or apply the vendor's mitigation, and to watch for the fix — it never tells you to remediate on a cadence with nothing to apply.
Source: CISA, Stakeholder-Specific Vulnerability Categorization Guide (November 2022), Tables 1, 8 and 9 — identical to CERT/CC's CISA Coordinator decision table v2.0.3. In the API, echelongraph_ssvc_decision is the medium-level decision and score_factors.ssvc.by_mission carries all three.
Why two numbers instead of one? Severity and priority are different questions, and collapsing them hides information. Keeping the EG Score a stable 0–10 preserves every downstream contract and comparison to CVSS, while EG Risk gives security teams a defensible way to order the remediation queue.
Recompute on every change
Both numbers are recomputed automatically whenever an input signal changes — a new KEV listing, a fresh EPSS probability, a CNA revision, a GHSA update, or a REJECTED status. High-priority triggers (KEV, EPSS spikes) are re-scored within hours, not on a fixed daily sweep.
Every recompute writes a typed history record — which field changed, from what to what, the exact inputs and factor breakdown, and what caused the change — so any past score is fully reproducible and auditable. We keep the algorithm version on every row, so when the formula itself improves, we replay the whole corpus rather than letting old and new scores coexist silently.
Worked example
CVE-2025-10127
| NVD CVSS | 9.8 (CRITICAL) |
| GHSA CVSS | 7.3 (HIGH) — disagrees by 2.5 points |
| EPSS | 0.04 — a 4% probability of exploitation in the next 30 days |
| KEV | Not listed |
| EG score | 7.3 (HIGH) — MEDIUM confidence |
Why we picked 7.3 over NVD's 9.8: GHSA has more recent vendor context than NVD's static analysis, and disagrees significantly. EPSS is low — meaning attackers aren't targeting this CVE in the wild. KEV is not listed. The combined signal says NVD overweighted theoretical impact relative to actual risk. Rule 3 (GHSA CVSS) wins. MEDIUM confidence because two sources disagree.
What we deliberately don't claim
❌ More accurate than NVD CVSS
NVD CVSS is accurate for what it measures (CVSS-vector math). We measure more things.
❌ Replaces NVD
NVD is one of our input sources. We are an aggregator, not a replacement.
❌ The source of truth for CVE scoring
MITRE assigns CVEs, CISA maintains KEV and SSVC decision points, NVD scores, FIRST publishes EPSS. We compose their outputs; we don't override them.
❌ Always right when NVD is wrong
Sometimes we diverge (CVE-2025-10127 above). Often we converge. The diverging cases are where we add the most operational value.
❌ Predicts which CVEs will be exploited next
EPSS (one of our inputs) does that. We surface it; we don't second-guess it.
Frequently asked
What is the EG score?
The EG (EchelonGraph) score is a 0–10 severity number we compute for every CVE by synthesizing NVD/CNA CVSS, CISA KEV (real-world exploitation status), FIRST EPSS (next-30-day exploit probability, applied continuously), GitHub Security Advisory (vendor-specific CVSS), and EchelonGraph's own exploitation model. Every CVE also carries EG Risk — a separate 0–100 priority score — and CISA's SSVC decision (Act/Attend/Track*/Track) at each mission impact level. It re-computes automatically whenever any signal changes — typically within 4 hours for high-priority CVEs.
How is the EG score different from NVD CVSS?
NVD CVSS is computed from a fixed vector of technical attack characteristics (attack vector, complexity, privileges, etc.). It does not factor in whether a CVE is actively exploited or how likely it is to be exploited. The EG score adds those signals: KEV-listed CVEs get a HIGH-severity floor, EPSS-critical CVEs get elevated, and disagreements between NVD and GHSA are flagged with explicit confidence indicators.
Why does EG sometimes equal NVD CVSS?
When a CVE is fresh and only the NVD baseline has been published — EPSS has not rescored yet (their model runs nightly), GHSA has not published an advisory (4–72h lag for OSS, never for infrastructure-only CVEs), and CISA has not KEV-listed it — there is no additional signal to synthesize. In that case we display NVD CVSS as the EG score and flag it as 'Aggregating' with LOW confidence. The score upgrades automatically once enrichment data arrives.
When does the EG score differ from NVD CVSS?
Several triggers: (1) the CVE is listed on CISA KEV — we floor the score at 9.0 because real-world exploitation has been confirmed; (2) EPSS is elevated — we raise the score continuously as exploit-probability rises (a smooth ramp, not a single 0.85 cliff); (3) GHSA has published a genuinely fresher CVSS — we trust it in both directions, including a downward revision, with a confidence indicator reflecting the disagreement; (4) the record has been REJECTED by its CNA/NVD — we suppress it to NONE rather than scoring a withdrawn vulnerability.
What is EG Risk, and how is it different from the EG score?
EG Score (0–10) answers 'how severe?'. EG Risk (0–100) answers 'how urgently should I act?'. EG Risk is a transparent weighted fusion of severity (45%), exploitation — KEV, our exploitation model, and continuous EPSS (40%), and automatability from CISA SSVC (15%). It gives equal-severity CVEs the headroom to separate: a KEV-listed, automatable 9.8 lands near 100, while a dusty never-exploited 9.8 lands in the 40s. Each CVE also carries CISA's SSVC decision — Act / Attend / Track* / Track — at low, medium and high mission impact, because SSVC is stakeholder-specific and only you know how essential the affected system is to you.
What does the confidence indicator mean?
Every EG score carries a confidence rating: HIGH (≥3 independent sources agree within ±1.0 CVSS, or KEV-listed, or EPSS ≥ 0.95), MEDIUM (2 sources agree, or GHSA published within 30 days), LOW (only NVD signal, or conflicting sources), or NONE (no CVSS from any source yet). Confidence is independent of score magnitude — a high-confidence MEDIUM is more actionable than a low-confidence CRITICAL.
Is the EG score better or more accurate than NVD CVSS?
Honest answer: NVD CVSS is accurate for what it measures (CVSS-vector math). The EG score does not claim to be more accurate — it measures more things. We add exploitation telemetry and forward-looking probability to a score that NVD computes purely from technical characteristics. For triage and prioritization workflows, more signals usually means better decisions, but neither score is a ground-truth substitute for vendor advisories or your own attack-surface context.
How often does the EG score update?
By priority tier: P0 (KEV-listed or score ≥ 9.0) every 4 hours; P1 (score 7.0–8.9) every 12 hours; P2 (score 4.0–6.9) every 24 hours; P3 (score < 4.0 or unscored) every 72 hours; P-cold (>5 years old + low score) every 30 days. The continuous-refresh cadence is the operational differentiator — NVD scores are largely static after publication.
See the EG score in action
Every CVE carries an EG Score, an EG Risk priority, CISA's SSVC decision by mission impact, a confidence indicator, and a rationale you can hover.