How the EG score works
Every scored CVE gets two EchelonGraph numbers: an EG Score (0–10 severity, synthesized from NVD/CNA CVSS + CISA KEV + FIRST EPSS + GitHub Security Advisory) and an EG Risk (0–100 priority, which adds our own exploitation model), shown with an SSVC decision at each mission impact level (CISA's decision table, applied by EchelonGraph). Since algorithm v4.0 each CVE also carries the three questions the EG Score mixes, published apart: EG Severity, EG Likelihood and EG Priority. Both numbers are re-computed by a rolling sweep per priority tier, and ahead of it when the CVE record changes, CISA KEV-lists the CVE, new exploit code is recorded, our EG-KEV tier changes, or an EPSS move changes the 0–10 score. 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. Until NVD scores a CVE, its headline CVSS is the CNA's, CISA-ADP's or a secondary source's, and every page and API field that uses it names whose.
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.
ENISA EU KEV
The EU Known Exploited Vulnerabilities catalogue in ENISA's European Vulnerability Database (EUVD): CVEs whose exploitation in the wild ENISA records. Since algorithm v4.1 a CVE it lists and CISA's catalog does not is floored at 9.0 too (Rule 1b). Each CVE page shows the listing with ENISA's date and the reporting source ENISA records, and EUVD identifiers resolve to their CVE. Source: ENISA EUVD, reproduced with acknowledgement.
Limit: Reactive like CISA KEV, and much smaller. The reporting source is shown as ENISA records it: a national CSIRT for most entries, ENISA itself for some.
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 — and publish it, as FIRST's, as EG Likelihood.
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: GitHub reviews advisories for the software ecosystems it tracks (npm, PyPI, Go, Maven, etc.). For other CVEs it may publish an unreviewed advisory, which may carry no CVSS; many CVEs have no advisory at all.
EchelonGraph exploitation model
Our own graduated pre-KEV exploitation signal (eg_kev), folding in exploit-code intelligence and other early indicators. It raises EG Risk (the 0–100 priority) before CISA formally lists a CVE, without waiting for the KEV catalog to catch up. It never moves the 0–10 EG Score.
Limit: A confidence-scored prior, not a confirmation. Populated where we have supporting exploit intelligence; a no-op where we don't.
CISA SSVC inputs
CISA's values for three Stakeholder-Specific Vulnerability Categorization decision points — exploitation, automatability, technical impact — published for some CVEs in its Vulnrichment data. CISA also publishes the SSVC decision table, but no decision for any CVE: we run that table in-house to derive the Act / Attend / Track* / Track decision at each mission impact level, and BOD 26-04's Table 1 to give its remediation timeline.
Limit: Decision-point coverage is partial. A value CISA has not published comes only from what CISA or CERT/CC defines: exploitation from a KEV listing or exploit code on record, never EPSS; automatability and technical impact from a CVSS v4.0 vector, else CISA's own BOD 26-04 default. The table below names every source.
The formula (rule order)
Rules evaluated in priority order. First match wins. The only continuous modifier of the 0–10 score is the EPSS ramp in Rule 2; our exploitation prior (eg_kev) does not touch this number — it feeds EG Risk, the separate 0–100 score below. A genuinely fresher GHSA can revise the score downward (Rule 3). The headline CVSS below is NVD's own score where NVD has published one, otherwise the CNA's, CISA-ADP's or a secondary source's (the CVE's cvss_source); each rationale names whose it is. Each rule's identifier, in brackets, is the rule_triggered value in the API's score_factors. A score computed before v3.3 names Rule 2 epss_critical, its earlier identifier, until the CVE is next re-scored.
- 0
Rule 0 — Rejected (rejected)
no score · severity: NONE · confidence: NONE (0)
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 (kev_exploitation)
max(headline CVSS, GHSA CVSS, 9.0) · severity: CRITICAL · confidence: HIGH 1.00
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, so it scores 9.0 and is rated CRITICAL. Confidence stays HIGH even when EPSS is stale: the exploitation is confirmed, not predicted. The 9.0 is a floor for confirmed exploitation, not an impact rating: since v4.0 the rationale says so, score_factors.kev carries floor_applied and floor_basis, and the CVE's impact severity is published apart as EG Severity (CVSS 6.5 MEDIUM here). A KEV-listed CVE with no CVSS at all still scores 9.0; its EG Severity reads “exploited; severity not yet published”.
- 2
Rule 1b — ENISA EU KEV exploitation (eu_kev_exploitation)
max(headline CVSS, GHSA CVSS, 9.0) · severity: CRITICAL · confidence: HIGH 1.00
Triggers when: ENISA's EU Known Exploited Vulnerabilities catalogue lists the CVE and CISA's KEV catalog does not. A CVE both list takes Rule 1, whose rationale then names the EU listing too.
Why: An EU KEV listing records exploitation in the wild — the same class of evidence as a CISA listing, so the same floor, rating and confidence, and no stale-EPSS downgrade. The rationale names ENISA's listing with ENISA's acknowledgement, says CISA does not list the CVE and, as Rule 1's does, that a floored 9.0 is the floor for confirmed exploitation, not an impact rating (score_factors.eu_kev carries floor_applied and floor_basis). The CVE's impact severity is published apart as EG Severity; with no CVSS at all it reads “exploited; severity not yet published”. ENISA's date and the reporting source it records are on the CVE's page, from ENISA's record, not in the score. Source: ENISA EUVD, reproduced with acknowledgement.
- 3
Rule 2 — Continuous EPSS uplift (epss_uplift)
base + f × (9.0 − base), base = max(headline CVSS, GHSA CVSS), f = (EPSS − 0.30) / (0.85 − 0.30), capped at 1 · severity derived from the lifted score · confidence: table below
Triggers when: There is a real CVSS base below 9.0 and the EPSS exploit probability is above 0.30, so the ramp lifts the base by more than 0.05.
Why: EPSS correlates strongly with actual exploitation. Below 0.30 it leaves the score alone; from 0.30 to 0.85 it lifts the score smoothly toward 9.0; at 0.85 and above it reaches 9.0. There is no single cliff, so a 0.60 and a 0.90 are treated differently — and the result is rated by the lifted score, so it need not be CRITICAL (a 6.5 base at EPSS 0.60 becomes about 7.9, HIGH). We never fabricate a base from EPSS alone.
- 4
Rule 3 — GHSA CVSS, both directions (ghsa_cvss)
GHSA CVSS value · severity derived from score · confidence: by NVD agreement and advisory age (table below)
Triggers when: GHSA has published a CVSS for this CVE, and either there is no NVD CVSS, GHSA is at or above NVD, or the GHSA advisory was published after the NVD record was last modified.
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. A lower GHSA that is older than NVD's last revision does not override NVD. A downward revision is capped at MEDIUM confidence (at most 0.60): the disagreement itself is signal.
- 5
Rule 4 — Headline CVSS baseline (nvd_cvss)
headline CVSS (NVD's own, else the CNA's, CISA-ADP's or a secondary source's) · severity derived from score · confidence: MEDIUM 0.60 when EPSS has scored the CVE, LOW 0.35 when it has not
Triggers when: There is an NVD/CNA CVSS base and none of Rules 0–3 applied: not KEV-listed (by CISA or ENISA's EU KEV), EPSS absent or too low to lift the score, and no GHSA score that qualifies under Rule 3.
Why: Honest fallback: the score is the headline CVSS, because no other signal changed it. The identifier says nvd_cvss for every provider (it is an API contract); since v3.6 the rationale, the CVE page's “Triggered by” line and score_factors.headline_cvss name whose CVSS it is. The rationale ends with what Rule 3 decided about a GitHub advisory CVSS on record — lower than this score and not newer than the CVE record's last change, or with a date missing — or says none is on record. While confidence is LOW, the UI renders it as 'Aggregating'.
- 6
Rule 5 — CVSS v2.0 fallback (cvss_v2)
NVD CVSS v2.0 base · severity: NVD's own v2 label (LOW / MEDIUM / HIGH — never CRITICAL) · confidence: LOW 0.40 when EPSS has scored the CVE, LOW 0.25 when it has not
Triggers when: No CVSS v3.1 or v4.0 base from any source, but NVD published a CVSS v2.0 base — the case for most CVEs from before 2016.
Why: Terminal: a v2 base gets no EPSS uplift and no agreement math, because v2 is an older, coarser metric (no Scope, no User Interaction, no Attack Requirements) and is not comparable to a v3 or v4 score. EPSS still feeds EG Risk.
- 7
Rule 6 — Vendor-stated severity (vendor_prose_severity)
calibrated band score (Critical 8.8 · High 8.8 · Medium 6.5 · Low 5.4) · severity derived from that score, so never CRITICAL · confidence: LOW 0.20 when EPSS has scored the CVE, LOW 0.15 when it has not
Triggers when: No CVSS base of any version exists, but the vendor stated a severity in its own advisory text. Today that is Chromium, whose CNA publishes no CVSS vector.
Why: Terminal, like Rule 5. Each band's score is the median CVSS v3 base NVD later gave that vendor band, and the rationale quotes the exact advisory wording, so the number is traceable to the bytes it came from.
- 8
Rule 7 — No data (no_data)
0 · severity: NONE · confidence: NONE (0)
Triggers when: No CVSS of any version, no KEV listing, no GHSA score and no parseable vendor severity — typically a CVE in 'reserved' or 'awaiting analysis' state.
Why: We don't make up scores. The CVE shows as not yet assessed — not as a score of zero — until at least one source publishes.
Algorithm version v4.1
Every score is stamped with the algorithm version that produced it (score_factors.algorithm_version). A score computed under an earlier version can still carry that version until the CVE is next re-scored.
v4.1(2026-10-25) — Adds ENISA's EU Known Exploited Vulnerabilities catalogue (EU KEV, from ENISA's European Vulnerability Database) as an input. Rule 1b scores a CVE EU KEV lists and CISA's KEV catalog does not as Rule 1 scores a CISA listing — max(headline CVSS, GHSA CVSS, 9.0), CRITICAL, HIGH 1.00 — because both record exploitation in the wild; its rationale says CISA does not list the CVE and, like Rule 1's, that a floored 9.0 is the floor for confirmed exploitation, not an impact rating. A CVE both catalogues list keeps Rule 1 (kev_exploitation stays CISA's), and its rationale names the EU listing too. EG Severity is never raised by the listing (a CVE with no CVSS reads “exploited; severity not yet published”); EG Likelihood reports it as confirmed exploitation, never as a probability; EG Risk counts it once, in its exploitation term; and the SSVC exploitation input reads it where CISA's catalog does not list the CVE. CISA BOD 26-04's KEV input and its defaults stay CISA's, as the directive defines KEV: an EU-only CVE with no Automatable value from CISA or its CVSS v4.0 vector takes the directive's default (not automatable) in SSVC and EG Risk, where an unknown Automatable on a CISA-listed CVE is assumed automatable (CERT/CC's safer answer), so with nothing else known an EU-only listing scores EG Risk 85 and a CISA one 100. score_factors gains eu_kev, which says that ENISA lists the CVE and carries ENISA's acknowledgement; ENISA's date and the reporting source it records are shown on the CVE's page, from ENISA's record, not in the score. With no EU KEV listing every output is v4.0's. ENISA's data is shown with acknowledgement (Source: ENISA EUVD).v4.0(2026-10-17) — Publishes the three questions the 0–10 EG Score mixes, apart and each with its source: EG Severity (the CVSS base score alone, which no KEV listing, EPSS or EG-KEV tier raises), EG Likelihood (FIRST's EPSS probability over 30 days, with confirmed exploitation reported beside it) and EG Priority (the SSVC decision and the BOD 26-04 timeline). EG Risk's severity term now reads EG Severity instead of the EG Score, so a KEV listing is counted once, in the exploitation term: a KEV-listed CVE with CVSS 5.4 and an Automatable value CISA has not published is EG Risk 79, not 96, and an EPSS-lifted CVE loses the uplift from its severity term. EG Risk's weights do not change. The EG Score, its severity, confidence and rule, and the SSVC decision do not change either: the KEV floor stays, and the rationale and score_factors.kev now say that a floored 9.0 comes from exploitation, not impact.v3.7(2026-10-12) — Three corrections to what the CVSS v2.0 rule (Rule 5) and the vendor-stated-severity rule (Rule 6) say about EPSS and the v2 bands; no score, severity, confidence, EG Risk or SSVC decision changes. Their rationale printed the EPSS figure from the time the CVE was scored, which went stale as FIRST updated EPSS daily without a rescore, and said that figure “is reflected in EG Risk”, which is false wherever an EG-KEV tier's fixed weight, not EPSS, sets EG Risk's exploitation input. It now says only that EPSS does not lift the score; the CVE page states the current EPSS figure and what set EG Risk. The rationale names the v2 bands as NVD's (“NVD rates that HIGH (NVD's v2 bands: …)”), because CVSS v2 itself defines no severity bands. And score_factors.sources_contributing no longer lists EPSS for these two rules, because EPSS did not move the score.v3.6(2026-10-11) — Four corrections; no score, severity, EG Risk or SSVC decision changes. Rule 4's rationale ended with a GitHub sentence that was false both ways: with an advisory CVSS on record it called it “pending alignment” after Rule 3 had declined it, and without one it promised that confidence would rise once GitHub published and that GitHub never covers infrastructure-only CVEs. It now states what Rule 3 decided — a lower advisory score not newer than the CVE record's last change, or a date missing — or that no advisory CVSS is on record. GHSA confidence and the NVD/GHSA agreement compare the two scores to one decimal, where they compared a raw floating-point difference: a fresh GitHub score exactly 1.0 above NVD was MEDIUM 0.70 instead of HIGH 0.90 at six of the 90 NVD bases (7.8 with GitHub's 8.8 among them), exactly 2.0 above was MEDIUM 0.55 and “conflicting” instead of MEDIUM 0.70 and “partial” at eight, a newer GitHub score exactly 2.0 below was MEDIUM 0.55 and “conflicting” instead of MEDIUM 0.60 and “partial” at eight, and exactly 0.5 apart “unanimous” instead of “partial” at five. A stale EPSS is measured from the last daily EPSS file that covered the CVE, not from the last change of its value, so an EPSS FIRST re-publishes unchanged no longer loses a confidence tier after a week; score_factors.epss gains score_date and model_version. Rule 4's score_factors gain headline_cvss, whose CVSS the score is — NVD's own, the CNA's, CISA-ADP's or a secondary source's — and the CVE page's “Triggered by” names it instead of “NVD CVSS baseline”.v3.5(2026-10-11) — EG Risk's breakdown says what its exploitation number is: score_factors.eg_risk gains exploitation_source (kev, eg_kev_tier1, eg_kev_tier2, eg_kev_tier3, epss or none), and its summary names it — “65% (EchelonGraph's fixed weight for EG-KEV Tier 2, not a probability)”, “97% (FIRST EPSS 30-day probability)”. Until v3.5 the API and MCP summary printed a tier's fixed weight as a bare percentage. No score, severity, confidence, rationale, EG Risk or SSVC decision changes.v3.4(2026-10-11) — Adds CISA BOD 26-04's remediation timeline to every CVE that is not withdrawn, for a publicly exposed system and for one that is not. Makes the SSVC inputs CISA's: exploitation is CISA's value, a CISA KEV listing, or exploit code on record — EPSS and EG-KEV's tiers no longer stand in for a public PoC; Automatable and technical impact come from CISA, then the CVE's CVSS v4.0 vector by a cited rule, then CISA's own BOD 26-04 default for a CVE not in KEV (“no” and “total”). That default replaces three that disagreed — EG Risk's 0.30, the stored SSVC decision's “no”, CISA's SSVC guide's “yes” — and the rule that read technical impact from the CVSS base score. A KEV-listed CVE CISA has not yet assessed shows those inputs as unknown, and its single stored SSVC decision is the most urgent one they allow. The 0–10 score, severity, confidence and rationale do not change; EG Risk moves through its automatability term (about 4 to 5 points lower where an Automatable value nobody published was 0.30) and the SSVC decision through its inputs.v3.3(2026-10-11) — Makes the outputs consistent with each other; no score, severity, confidence label, EG Risk or SSVC decision changes. Rule 2's identifier is now epss_uplift instead of epss_critical, because the rule lifts a score toward 9.0 and rates whatever score it reaches, which need not be CRITICAL. Each confidence label's number now stays inside a fixed range — LOW 0.01–0.49, MEDIUM 0.50–0.84, HIGH 0.85–1.00 — so an EPSS-lifted score with stale EPSS, which was LOW 0.60 and outranked a MEDIUM 0.55, is now LOW 0.49. Every rationale states EPSS through one formatter that never prints 100%: a probability of 0.9997 reads “>99.9%”, where it read “100%” or “100.0%”. The vendor-stated-severity rationale and factors read the band its score was computed from.v3.2(2026-09-28) — CISA's SSVC decision table is run exactly as CISA publishes it, at every mission impact level; the rationale states EPSS as a probability plus an ordinal percentile instead of “top N%”.v3.1(2026-07-30) — Adds Rule 6 (vendor-stated severity), and makes “not yet assessed” an explicit output instead of a score of 0.v3.0(2026-07-26) — Adds Rule 5 (CVSS v2.0 fallback, terminal) for pre-2016 CVEs that NVD only ever scored under v2.v2.2(2026-07-23) — The 0–10 rules are unchanged; score_factors.eg_risk now explains itself — what EG Risk is, and this CVE's weighted severity, exploitation and automatability breakdown.v2.1(2026-07-23) — EPSS never fabricates a severity without a CVSS base; a GHSA down-revision requires the advisory to be newer than NVD's last revision.v2.0(2026-07-22) — Continuous EPSS uplift replaces the single 0.85 cutoff; GHSA can revise a score downward; adds the in-house SSVC decision and the 0–100 EG Risk.v1.1(2026-07-22) — Adds Rule 0 (rejected records are not scored) and records our exploitation model (eg_kev) in the factors; every rescore keeps its inputs, so scores since then can be replayed.v1.0(2026-05-18) — The first cascade: KEV floor, EPSS ≥ 0.85 lifts to 9.0, GHSA, NVD, no data. Some behaviour changes after it shipped without a version bump, so a v1.0 stamp does not pin one exact rule set.
Confidence rubric
Confidence is set by the rule that produced the score, never by the score's magnitude, and tells you how much to trust it. A HIGH-confidence MEDIUM is more actionable than a LOW-confidence CRITICAL. Every label carries the 0–1 number published in the API's score_confidence_numeric; these are every value the scorer assigns before the stale-EPSS adjustment below. Since v3.3 each label's number stays inside a fixed range — LOW 0.01–0.49, MEDIUM 0.50–0.84, HIGH 0.85–1.00, and NONE is always 0 — so a LOW never carries a higher number than a MEDIUM, nor a MEDIUM than a HIGH.
| Rule | Confidence it assigns |
|---|---|
Rule 0 — Rejected rejected |
|
Rule 1 — KEV exploitation kev_exploitation |
|
Rule 1b — ENISA EU KEV exploitation eu_kev_exploitation |
|
Rule 2 — EPSS uplift epss_uplift |
|
Rule 3 — GHSA CVSS ghsa_cvss |
|
Rule 4 — Headline CVSS baseline nvd_cvss |
|
Rule 5 — CVSS v2.0 cvss_v2 |
|
Rule 6 — Vendor-stated severity vendor_prose_severity |
|
Rule 7 — No data no_data |
|
Stale EPSS. When EPSS drove or informed the score (Rules 2 and 4) and the EPSS data is more than 7 days old, confidence drops one tier and its number falls by 0.15, then is held inside the new label's range: HIGH 0.95 → MEDIUM 0.80, HIGH 0.88 → MEDIUM 0.73 and MEDIUM 0.75 → LOW 0.49 for Rule 2, MEDIUM 0.60 → LOW 0.45 for Rule 4. Before v3.3 the Rule 2 MEDIUM 0.75 became LOW 0.60, a higher number than the MEDIUM 0.55 of Rule 3. KEV and GHSA confidence is not affected, because EPSS did not produce those scores. The age is measured from the last daily EPSS file that covered the CVE (FIRST's score date, in score_factors.epss.score_date, with the EPSS model version) or the last change of its value, whichever is later. Until v3.6 it was measured from the last change alone, so a CVE FIRST re-scored every day to the same value lost a tier after a week although its EPSS was current.
The three components: EG Severity, EG Likelihood, EG Priority
The EG Score is severity, escalated by confirmed exploitation: a CVSS-derived severity with likelihood signals folded in: the KEV floors (Rule 1 for CISA's catalog, and since algorithm v4.1 Rule 1b for ENISA's EU KEV) and the EPSS ramp (Rule 2). It stays as it is, because many readers rely on “KEV means CRITICAL”. Since algorithm v4.0 every CVE that is not withdrawn also carries the three questions it mixes, published apart and each with its source, so a KEV-floored 9.0 is never read as impact. The 9.0 is the floor for confirmed exploitation, not an impact rating: a KEV-listed CVE with CVSS 5.4 scores 9.0 CRITICAL, and its EG Severity is 5.4 MEDIUM.
EG Severity
How bad is it if it is exploited?
Impact severity alone: the CVSS base score (CVSS-B, base metrics only) from the best-provenance CVSS we hold — GitHub's advisory CVSS where Rule 3 takes it, else the headline CVSS (NVD's own, a CNA's, CISA-ADP's or a secondary source's), else NVD's CVSS v2.0 base. No CISA KEV listing, ENISA EU KEV listing, EPSS probability or EG-KEV tier raises it. It carries its CVSS version, its vector where we store one, and whose CVSS it is.
When there is nothing to report: With no CVSS of any version it is not assessed: score and severity are null, never 0, and unassessed_reason is kev_listed_no_cvss on a CISA KEV-listed CVE (“exploited; severity not yet published”), eu_kev_listed_no_cvss on one only ENISA's EU KEV lists (since v4.1; the same words, naming ENISA's listing), else no_cvss. A vendor's own severity word is not a CVSS score.
EG Likelihood
How likely is exploitation?
A probability with a horizon: FIRST's EPSS probability of exploitation activity within 30 days (source first_epss, horizon_days 30), with FIRST's percentile, score date and model version. It is FIRST's model, not an EchelonGraph model. Confirmed exploitation — a CISA KEV listing (cisa_kev), an ENISA EU KEV listing (eu_kev), since v4.1 (Source: ENISA EUVD), or EG-KEV Tier 1 (eg_kev_tier1) — is reported beside it, in exploited and exploited_sources, and never folded into the probability.
When there is nothing to report: With no EPSS on record the probability is null, with null_reason no_epss_on_record: unknown, not low, and never 0.
EG Priority
What should I do, and by when?
The decision: CISA's SSVC decision table as EchelonGraph applies it — the decision at medium mission impact, and at every level — and CISA BOD 26-04's remediation timeline if your system is publicly exposed and if it is not, with the inputs both read (in KEV, exploitation, automatable, technical impact), each with its source. The same decision and timeline as the SSVC and BOD 26-04 sections below, side by side.
When there is nothing to report: On a CVE no rule has assessed there is no SSVC decision (null, null_reason not_assessed); the BOD 26-04 timeline applies to every CVE that is not withdrawn.
Where they are. In the API, score_factors.eg_severity, .eg_likelihood and .eg_priority on every row, and the same objects at the top level of GET /api/v1/public/cves/{id}. A CVE the v4.0 re-score has not reached yet carries none of them, and neither does a withdrawn record. Each is the scorer's output when the CVE was last scored: the CVE page states the EPSS figure FIRST published most recently, which can be newer than the one EG Likelihood holds until the CVE is re-scored.
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 scored CVE also carries EG Risk, a 0–100 priority number with the headroom to separate equal-severity vulnerabilities, plus an SSVC decision at each mission impact level (CISA's decision table, applied by EchelonGraph).
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 each scored CVE's page.
- Severity — EG Severity, the CVSS base score ÷ 10 — never the KEV-floored or EPSS-lifted EG Score (since v4.0)45%
- Exploitation — KEV + our exploitation model + continuous EPSS40%
- Automatability — the SSVC Automatable input: CISA's value, else the CVSS v4.0 vector's, else CISA's BOD 26-04 default “no”15%
A KEV-listed, automatable 9.8 lands near 100; a dusty, never-exploited 9.8 lands in the 40s. Same severity, very different urgency.
Hand-set weights. EchelonGraph set these weights by hand; we have not fitted them to outcomes. Re-deriving them waits on two things we do not have yet: enough settled outcomes in our evaluation harness to fit them on, and a calibrated likelihood model. Until then they stay where they are.
The SSVC decision
We run CISA's Stakeholder-Specific Vulnerability Categorization decision table in-house. CISA publishes the table and, for some CVEs, the input values (Vulnrichment), but no decision for any CVE, so each decision on our pages is CISA's decision table, applied by EchelonGraph. 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.
EG Risk's severity term: one count of exploitation
EG Risk = 45% × severity + 40% × exploitation + 15% × automatability. Until v4.0 the severity term was the EG Score itself, which a KEV listing floors at 9.0 and EPSS lifts toward 9.0, so exploitation was counted twice: once in the exploitation term and again through the escalated severity. Since v4.0 the severity term reads EG Severity, and score_factors.eg_risk.severity_source says which of three cases applied:
| severity_source | The severity term |
|---|---|
| eg_severity | The CVE has a CVSS of any version: EG Severity's score ÷ 10. |
| vendor_severity | No CVSS, and the vendor states a severity in its own advisory: Rule 6's score for that word ÷ 10, which nothing escalates either. |
| unknown_kev_most_urgent | No severity of any kind is published, on a CVE CISA's KEV lists (the only kind that reached EG Risk so until v4.1): the most urgent value, 1.0, the answer EG Risk's automatability term already takes for an unknown Automatable on a KEV-listed CVE. Never 0, which would rank “severity not yet published” as “no impact”, and never the 9.0 floor, which would count the listing twice. |
| unknown_eu_kev_most_urgent | Since v4.1: the same, on a CVE only ENISA's EU KEV lists (Rule 1b also scores one with no severity published): the most urgent value, 1.0, for the same reason. Source: ENISA EUVD. |
The exploitation term is unchanged: a CISA KEV listing (100%), EchelonGraph's fixed weight for an EG-KEV tier, or FIRST's EPSS probability, whichever is highest. The weights did not change in v4.0. The worked example below shows the arithmetic.
EG Risk for a KEV-listed CVE with CVSS 5.4
| EG Score | 9.0 (CRITICAL) — the CISA KEV floor for confirmed exploitation, unchanged in v4.0 |
| EG Severity | 5.4 (MEDIUM) — the CVSS base: the impact |
| EG Likelihood | Unknown (no EPSS on record); confirmed exploitation, apart from it: CISA KEV |
| EG Priority | SSVC Act at medium mission impact while CISA has not published Automatable or technical impact; BOD 26-04: 14 days, 3 days or 3 days & forensic triage if publicly exposed |
- The issue's arithmetic, under the 0.30 automatability prior EG Risk used until v3.4 — not today's value: 45% × 0.54 + 40% × 1.0 + 15% × 0.30 = 0.688 → 69. With the severity term read from the KEV-floored EG Score instead, 45% × 0.90 + 40% × 1.0 + 15% × 0.30 = 0.850 → 85: 16 of those points were the KEV listing counted a second time.
- Live since v4.0: CISA has not published Automatable for this KEV-listed CVE, so EG Risk takes the safer answer: 45% × 0.54 + 40% × 1.0 + 15% × 1.0 = 0.793 → 79. Under v3.7 the same CVE was 45% × 0.90 + 40% × 1.0 + 15% × 1.0 = 0.955 → 96.
- Once CISA publishes Automatable “no” and technical impact “partial”: 45% × 0.54 + 40% × 1.0 + 15% × 0 = 0.643 → 64. Its SSVC decision is then Track at medium mission impact, and BOD 26-04 gives 14 days whether or not the system is publicly exposed.
EG Risk 79 is the value the scorer publishes for this CVE today. The 69 is the issue's own arithmetic, kept to show that the fix removes the double count: v3.4 made an unknown Automatable on a KEV-listed CVE count as yes (1.0, CERT/CC's safer answer), which the 0.30 prior in that arithmetic predates.
CISA's decision table, 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 scored CVE's 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. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". An input CISA has not published takes the value the source table below gives it; only on a KEV-listed CVE CISA has not yet assessed does it stay unknown, and then the page lists every decision it allows.
| 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, and a CVE page gives it only to a fix it tells you to apply: a released fix on record, or one of two fixes it cannot confirm and sends you to look for. Where the fix status could not be loaded, the page says so and times a fixed version you find in the vendor's advisory. On a record 5 or more years old with no fix and no vendor advisory on record — where no fix on record is not evidence that none exists — it times the fixed version the vendor names if the vendor still supports the product, and otherwise tells you to isolate the affected system or retire the product. When no fix is confirmed, or a fix is merged or referenced with no release on record, the page says so (never that no fix exists: a vendor can publish one EchelonGraph does not yet hold), sends you to the vendor's advisory for a fixed release, and tells you to restrict network exposure of the affected system or apply the vendor's mitigation until one is applied. Every mitigation, isolation included, carries the same decision's urgency: as soon as possible for Act, sooner than your normal schedule for Attend, on your normal schedule for Track* and Track. EchelonGraph's own action never tells you to remediate, or times anything by an update cycle, with nothing to apply, and the verdict card's tagline says what that action says. CISA's BOD 26-04 timeline (below) is quoted as CISA's whatever the fix status, and it does not wait for a fix: the directive starts it when CISA lists the CVE in KEV or an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and phases it in over the 180 days after its issuance (the directive's words). Where no released fix is on record, the page says so beside it, in the BOD 26-04 block and in the score components panel — for a CVE in CISA's KEV catalog: “No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: this CVE is in CISA's KEV catalog, and CISA's required action for it, quoted below, applies whether or not a fix is released.” (where the record holds no required action to quote: “No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: this CVE is in CISA's KEV catalog, and its BOD 26-04 remediation timeline applies whether or not a fix is released; this page holds no required action from CISA to quote.”), and for any other: “No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says.” Where an answer is “Fix on system upgrade”, it adds this sentence, which quotes the directive's gloss: In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them. The KEV answer is the page's own listing, the one its KEV cell reads. CISA's required action is quoted, never restated.
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.
Where each input comes from
The SSVC decision and the BOD 26-04 timeline read the same inputs. Each is CISA's, or follows a rule CISA or CERT/CC documents, and each carries its source on the CVE page and in the API (the source beside every input in score_factors.ssvc and score_factors.bod_26_04). The first step that gives a value wins.
| Input | Source | Rule |
|---|---|---|
| Exploitation | cisa-adp | CISA's value in its Vulnrichment data — except that a CISA KEV listing, or an ENISA EU KEV listing, makes it active. |
| kev | Listed in CISA KEV: active. KEV is CISA's own record of exploitation in the wild, which meets CERT/CC's definition of active. | |
| eu_kev | Not in CISA KEV, but listed in ENISA's EU KEV catalogue (algorithm v4.1): active. The listing records exploitation in the wild, the same evidence. Source: ENISA EUVD. | |
| exploit_code | Exploit code on record — a Metasploit module, an Exploit-DB entry, a GitHub or vendor proof of concept, never a Nuclei detection template: public PoC. CERT/CC's public PoC is “Typical public PoC exists in sources such as Metasploit or websites like ExploitDB”. CISA's own value outranks it. | |
| no_exploitation_evidence | None of those: none. EPSS and EG-KEV's tiers never stand in for a public PoC. | |
| Automatable | cisa-adp | CISA's value in its Vulnrichment data. |
| cvss_v4_au | The CVE's CVSS v4.0 Automatable metric: AU:Y is yes, AU:N is no. CERT/CC: “We intend for these two decision points to be interchangeable.” | |
| cvss_v4_av_physical | CVSS v4.0 attack vector Physical: no. An attacker must touch each system, so the kill chain's delivery step cannot be automated, and CERT/CC: “Once one step is not satisfied, the analyst can stop and select no.” | |
| cisa_bod_26_04_default | Not in KEV: “no”, CISA's BOD 26-04 default. | |
| not_supplied | In KEV: unknown until CISA publishes it. Every decision and timeline it allows is shown; the single stored decision and EG Risk take the more urgent, yes. | |
| Technical impact | cisa-adp | CISA's value in its Vulnrichment data. |
| cvss_v4_vc_vi_high | CVSS v4.0 confidentiality and integrity impact to the vulnerable system both High: total. CISA's heuristic asks “Are Common Vulnerability Scoring System (CVSS) metric values for confidentiality and integrity impact both “High?” | |
| cvss_v4_vc_vi_not_high | Neither High: partial. Each of CISA's other questions for total impact — arbitrary software, every action, a full-privilege account — needs one of them High. Exactly one High decides nothing (a stolen administrator password is confidentiality High alone). | |
| cisa_bod_26_04_default | Not in KEV: “total”, CISA's BOD 26-04 default. | |
| not_supplied | In KEV: unknown until CISA publishes it, shown as for automatable; the single stored decision takes total. |
One default, and it is CISA's. For a CVE not in KEV whose automatability and technical impact nobody has published, every EchelonGraph component — the SSVC decision, the BOD 26-04 timeline and EG Risk — reads automatable “no” and technical impact “total”, because CISA's BOD 26-04 implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Until algorithm v3.4 three components disagreed: EG Risk counted an unknown automatability as 0.30, the stored SSVC decision as “no”, and CISA's SSVC guide recommends “yes”; and technical impact was read from the CVSS base score, a rule no source documents.
What we do not derive. CERT/CC's SSVC documentation says network attack vector with no privileges required makes only one step of the kill chain, delivery, “likely to be automatable”, and that “it is not clear that an algorithm or search process could be designed to automate scoring Automatable”; so no CVSS vector makes automatability yes unless it carries the Automatable metric itself. We read CVSS v4.0 vectors only: EchelonGraph keeps the CVSS v3.1 score but not yet its vector string.
CISA BOD 26-04: the remediation timeline
Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk” (10 June 2026), revokes BOD 19-02 and BOD 22-01. Its Table 1 gives a remediation timeline from four inputs: whether the system is publicly exposed, whether the CVE is in CISA's KEV catalog, automatable, and technical impact. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The first input belongs to your system — “Publicly Exposed is defined as Yes if the asset in scope of this directive is accessible to unauthenticated or untrusted entities via public networks, such as the internet, regardless of its physical or logical location; the value is No otherwise.” — so every CVE page that is not withdrawn gives the timeline both ways, if your system is publicly exposed and if it is not, beside the SSVC decision. Where an input CISA has not yet published is unknown (a KEV-listed CVE only), each answer lists every timeline it allows. The other three inputs are listed as the score's (“The score's inputs:”): EchelonGraph's score reads Table 1 with them, so they are what the timeline was computed from. Where the score's KEV answer is not the page's own listing (CISA listed the CVE, or removed it, after it was scored), the block and the score components panel say so with both answers and show no timeline under CISA's name: the score's was read with the other answer, and the page does not compute one of its own.
| Publicly exposed | In KEV | Automatable | Technical impact | Timeline (calendar days) |
|---|---|---|---|---|
| yes | yes | yes | total | 3 days & forensic triage |
| yes | yes | yes | partial | 3 days |
| yes | yes | no | total | 3 days & forensic triage |
| yes | yes | no | partial | 14 days |
| yes | no | yes | total | 3 days |
| yes | no | yes | partial | 14 days |
| yes | no | no | total | 14 days |
| yes | no | no | partial | 60 days |
| no | yes | yes | total | 3 days & forensic triage |
| no | yes | yes | partial | 14 days |
| no | yes | no | total | 14 days |
| no | yes | no | partial | 14 days |
| no | no | yes | total | 60 days |
| no | no | yes | partial | 60 days |
| no | no | no | total | Fix on system upgrade |
| no | no | no | partial | Fix on system upgrade |
A CVE nobody has assessed. With CISA's default — automatable “no”, technical impact “total”, for a CVE not in KEV — Table 1 gives 14 days if the system is publicly exposed and Fix on system upgrade if it is not. Some vendor write-ups give another figure for this case; computed from the table, it is one of those two.
The terms, in the directive's words. “The text “& forensic triage” means that the agency must complete remediation or mitigation action within the timeline (three days) and carry out a forensic triage of the asset to assess whether the system is compromised.” Fix on system upgrade means that, “unless conditions change”, “the vulnerability should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild.” The timelines are “dynamic as facts change”: “if CISA adds a vulnerability to the KEV that was not in the KEV, the timeline for action will shorten according to Table 1.” Days are calendar days. When the timeline starts: “The timelines defined in Table 1 begin when either (1) CISA adds the vulnerability to the KEV Catalog, or (2) pursuant to BOD 23-01, the agency enumerates or identifies the vulnerability on an asset and updates the Continuous Diagnostics and Mitigation (CDM) Program Agency and Federal Dashboard. Whichever event occurs first starts the remediation timeline.” What remediating means: “For each asset detected to contain an instance of a CVE ID, the vulnerability shall be remediated (that is, the vulnerability is eliminated through patching, decommissioning the system, or another action) within the timeline defined in Table 1: Remediation Timelines.” When agencies must meet the table: “Phase III – Within 180 days of issuance: Remediate each vulnerability as quickly as possible and no later than the timelines set forth in Table 1: Remediation Timelines.” None of these waits for a fix to be released, so a CVE page with no released fix on record never says the timeline does. For a CVE in its KEV catalog, CISA also publishes a required action, which the CVE's page quotes verbatim where its record holds it. Its wording differs from entry to entry — many say to apply updates per vendor instructions, others to apply mitigations or discontinue use of the product, some that an end-of-life product should be disconnected — so a page with no released fix on record points to it where it is quoted, says it holds none to quote where the record holds none, and never restates it. Where the score's KEV answer is not the page's own listing, the page shows no timeline under CISA's name until the score is recomputed.
CVSS. CISA's BOD 26-04 implementation guidance — not the directive itself — says: “Note: By revoking BOD 19-02, the FCEB no longer requires CVSS use for vulnerability prioritization.” The directive says only that technical impact “is similar to the Common Vulnerability Scoring System (CVSS) base score’s concept of “severity.””
Sources: CISA, BOD 26-04 (Table 1, an image on the directive's page) and its implementation guidance; the scorer runs CERT/CC's machine-readable copy of Table 1, decision table cisa:DT_BOD2604 v1.0.0, vendored at a pinned commit and checked against CISA's image cell by cell. In the API: score_factors.bod_26_04.if_publicly_exposed and .if_not_publicly_exposed (CERT/CC's keys 3DF, 3D, 14D, 60D and FSU, named in .timelines), with each input and its source.
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.
The verdict on each CVE page
Each CVE page opens with an EchelonGraph verdict: how urgently to act. It runs no second urgency formula beside the SSVC decision the same page shows (CISA's decision table, applied by EchelonGraph): its urgency is that decision at medium mission impact — the level the API stores as echelongraph_ssvc_decision — and, for a CVE not in KEV, its tagline says what the SSVC block's action says, with that decision's timing at every mission impact level in the block's own words: CISA's timing for a fix the page tells you to apply, and the decision's urgency for the mitigation (the action is fix-aware). The two exceptions, a KEV listing and a page with no SSVC decision, are in the table below. Act means now. Attend means soon: sooner than your standard update timelines for a fix to apply, sooner than your normal schedule for a mitigation. Track* or Track means within your standard update timelines for a fix to apply, and on your normal schedule for a mitigation. Where an input CISA has not published leaves more than one decision possible at medium mission impact, the verdict takes the most urgent of them, as the SSVC block's timing does.
| When | Released fix on record | No released fix |
|---|---|---|
| The CVE is listed in CISA KEV, whatever the SSVC decision. Where the SSVC decision on the page is slower at some mission impact level, the card says so: the KEV listing is “the reason this is sooner than the SSVC decision on this page”. | Patch now | Mitigate now |
| Not in KEV, and the SSVC decision at medium mission impact is Act. | Patch now | Mitigate now |
| Not in KEV, and the SSVC decision at medium mission impact is Attend. | Patch soon | Mitigate soon |
| Not in KEV, the SSVC decision at medium mission impact is Track* or Track, and there is a signal beyond severity — exploit code on record, EPSS ≥ 50%, CISA's Vulnrichment rating exploitation active or PoC, or internet-facing services on record — or the CVSS (the EG score where no CVSS is published) is 7.0 or higher. | Plan a fix | Plan mitigation |
| Not in KEV, the SSVC decision at medium mission impact is Track* or Track, with none of those signals and a CVSS below 7.0. | Monitor | Monitor |
| No SSVC decision on the page (a CVE not yet assessed, or a score from before algorithm v3.2), not in KEV, and CISA's Vulnrichment rates exploitation active. | Patch soon | Mitigate soon |
| No SSVC decision on the page, not in KEV, and Vulnrichment does not rate exploitation active: within your standard update timelines for a released fix, and on your normal schedule for the mitigation where there is none — Plan a fix or Monitor, Plan mitigation or Monitor, by the same signals and CVSS threshold as above. | Plan a fix / Monitor | Plan mitigation / Monitor |
| The page could not load EchelonGraph's exploitation data (NVD's own record is shown instead) and the CVE is not known to be in KEV. | Assessment incomplete | Assessment incomplete |
Patch or Mitigate. The verdict says “Patch” only when the page has a released fix on record. With no fix confirmed, a fix only referenced or merged with no release on record, or a fix status that could not be read, it says “Mitigate” or “Plan mitigation”: the page has no released fix it can confirm to patch with.
Why nothing louder. Exploit code already feeds the SSVC decision: where CISA has published no exploitation value, exploit code on record counts as a public PoC, and CISA's table gives Track or Track* at medium mission impact for every PoC row. A verdict sooner than that from the same evidence would contradict the decision on the same page. EPSS is a probability, not evidence of a PoC, so it is no SSVC input; at 50% or more it is one of the signals in the ladder above. Internet-facing services our KEV-Exposure radar has on record are listed first among the reasons and can put a standard-timeline verdict on Plan a fix rather than Monitor; they never make the verdict sooner than the SSVC decision, because they are other organisations' systems, not yours.
EG-KEV and its confidence figure
EG-KEV is EchelonGraph's own tiering of exploitation signals, shown as a badge on a CVE page. It feeds EG Risk. Since algorithm v3.4 it is no SSVC input: where CISA has published no exploitation value, the SSVC decision reads a CISA KEV listing or exploit code on record, never a tier. It never moves the 0–10 EG Score. A CVE is placed in the highest tier any of its signals reaches:
- Tier 1 — Exploited in the wild: listed in CISA KEV, rated exploitation active by CISA's Vulnrichment, or flagged by CISA KEV as used in ransomware.
- Tier 2 — Weaponized: a Metasploit module or an Exploit-DB entry Exploit-DB marks verified, or a Vulnrichment rating of PoC with EPSS ≥ 50%.
- Tier 3 — Elevated: a Vulnrichment rating of PoC, an EPSS percentile in the top 5%, or any public exploit or proof-of-concept code on record.
The confidence figure is a heuristic, not a probability. The badge's “EchelonGraph confidence” percentage is a fixed formula, not a measured or calibrated probability of exploitation: it starts at 0.90 for Tier 1, 0.62 for Tier 2, 0.38 for Tier 3, adds 0.04 for every distinct signal behind the CVE after the first (one EPSS value is one signal, even where it sets both the top-5% and the high-probability evidence keys), and stops at 1.00 for Tier 1, 0.85 for Tier 2, 0.55 for Tier 3; the badge shows it as a percentage (0.66 as 66%). Each piece of exploit code counts once: a Metasploit module and a verified Exploit-DB entry are signals of their own, and “public exploit code” counts only for code beyond those two — a GitHub or vendor proof of concept, or an Exploit-DB entry not marked verified. We set these numbers by hand and have not fitted them to outcomes, so a figure of 66% does not mean two in three such CVEs are exploited; read it as how many signals stand behind the tier.
Recompute on change, and on a rolling sweep
Both numbers are re-computed ahead of the sweep when an input changes: the scheduler's next batch (one starts every minute, or as soon as the last one ends) takes a new CVE with no score yet, a change to the CVE record (a CNA or NVD revision, a CVSS arriving, or a REJECTED status), a CISA KEV listing the score does not yet reflect, an ENISA EU KEV listing or withdrawal the score does not yet reflect (algorithm v4.1), exploit code recorded after the last score, a change to our EG-KEV tier, and an EPSS move that changes the 0–10 score (a move inside the 0.30–0.85 ramp, a crossing of 0.30, or a probability of 0.85 or more on a CVE not yet CRITICAL). A GHSA update, or an EPSS move that changes only EG Risk, waits for the rolling sweep, which revisits each CVE at its priority tier's interval, so the stored numbers can trail those signals. The intervals, and how production meets them today, are in the FAQ below.
Every recompute writes a typed history record — which field changed, from what to what, the exact inputs (since v3.6 including which daily EPSS file and model the EPSS came from) and factor breakdown, and what caused the change — so any past score is fully reproducible and auditable. A CVE's first assessment is recorded as such, with no score change: since v3.6 its score_delta is null, where it held the whole new score. 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
| Headline CVSS | 9.8 (CRITICAL), CVSS v3.1 — the CNA's (CISA ICS-CERT); NVD lists it as a secondary score and has not scored this CVE itself |
| CVE record last modified | 2026-04-15 in EchelonGraph's copy, the date the scorer compares (NVD's record has changed since) |
| GHSA CVSS | 7.3 (HIGH) — disagrees by 2.5 points; advisory published 2025-09-11 |
| EPSS | about 0.007 (FIRST EPSS, updated 2026-11-01) — under a 1% probability of exploitation in the next 30 days |
| KEV | Not listed |
| EG score | 9.8 (CRITICAL) — MEDIUM confidence (0.60) |
Why the EG score keeps the CNA's 9.8 over GitHub's 7.3: KEV is not listed, so Rule 1 does not apply. EPSS is below 0.30, so Rule 2 does not lift the score. Rule 3 honors a GHSA score below the headline CVSS only when the advisory is genuinely fresher than the CVE record — here the GHSA advisory (2025-09-11) predates the last change to the record EchelonGraph holds (2026-04-15), so a lower, older GHSA score does not override it. Rule 4 (the headline CVSS) applies, with MEDIUM confidence (0.60) because EPSS has scored the CVE. That headline CVSS is the CNA's, CISA ICS-CERT's, as NVD lists it; EchelonGraph's record labels it NVD's (cvss_source “nvd”), which is wrong. Had GHSA published its 7.3 after the record's last change, Rule 3 would have honored it as a downward revision, at MEDIUM confidence (0.55, as the two sources differ by more than 2.0). The disagreement is still published: score_factors.cvss records both scores and marks them as conflicting.
Measured in production
Read-only measurements against our production database on 2026-10-05. Every prediction figure uses the score as it stood at the decision time — the last rescore written before it — never today's score, which already knows the outcome. The negative result is reported with the same care as the positive ones.
Coverage: 96.75% of 2026's live CVEs carry an EG score
71,636 of the 74,041 non-rejected CVEs published in 2026. 36.65% carry a CVSS score from NVD itself; the rest of the coverage comes from carrying the CNA's, CISA-ADP's and GitHub's own CVSS. The remaining 3.25% are marked not yet assessed — never given a score of zero.
Speed: a median of 21 minutes from publication to the first EG score
11,543 CVEs published 2026-07-22 to 2026-08-21. 80.8% had an EG score within 24 hours and 92.9% within 7 days. In the same cohort NVD had scored 0.3% within 24 hours, and 90.9% still had no NVD score 45 to 75 days after publication.
Predicting exploitation before KEV listing: no better than CVSS
On 11,532 CVEs scored 7 days after publication, with the outcome a CISA KEV listing within 45 days (9 CVEs), “EG ≥ HIGH” and “CVSS ≥ 7” caught the same 7 of 9, at the same 0.11% precision. The EG severity band equalled the CVSS band for 99.76% of the scored CVEs among them (11,482 of 11,510). The EPSS uplift never fired: seven days after publication EPSS had a 99th percentile of 0.016 and a maximum of 0.206, all below the 0.30 where the ramp starts. Of the 51 CVEs CISA added to KEV between 2026-07-24 and 2026-10-04 that had a score the day before listing, EG ≥ HIGH had flagged 45 and CVSS ≥ 7 had flagged 44.
Confirmed exploitation reaches the score in about a minute
Of the 81 CISA KEV additions from 2026-07-24 to 2026-10-04, the 38 not already rated CRITICAL were rescored by the KEV rule a median of 1.1 minutes after we recorded the listing (90th percentile 2.2 minutes, slowest 3.9). The 43 already rated CRITICAL took longer — median 19.7 minutes, slowest 195 — because the rescore trigger skipped CVEs that were already CRITICAL, so their EG Risk and rationale lagged the listing. We are fixing that.
Limits. The prediction cohorts are small — 9 and 11 later-listed CVEs — so recall carries an uncertainty of about ±25–30 points: these results show parity with CVSS, not a measured difference either way. CISA KEV is one definition of “exploited”, it lags exploitation, and it covers well under 1% of CVEs. Each score is the one we actually published at the time, under the algorithm version then live.
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 from NVD; often we converge. And a disagreeing source is not enough on its own — CVE-2025-10127 above keeps the CNA's 9.8 because the lower GHSA score is not newer than the CVE record's last change.
❌ Predicts which CVEs will be exploited next
EPSS (one of our inputs) does that. We surface it; we don't second-guess it. Measured before KEV listing, the EG score is no better than CVSS (above), and we will not claim otherwise until a pre-registered evaluation shows it.
Frequently asked
What is the EG score?
The EG (EchelonGraph) score is a 0–10 severity number we compute for each CVE we can score (a rejected record is never scored, and a CVE with no CVSS, EPSS or vendor severity yet stays unassessed) by synthesizing NVD/CNA CVSS, CISA KEV (real-world exploitation status), ENISA's EU KEV catalogue (since algorithm v4.1: exploitation in the wild as ENISA records it, for a CVE CISA's catalog does not list; Source: ENISA EUVD), FIRST EPSS (next-30-day exploit probability, applied continuously), and GitHub Security Advisory (vendor-specific CVSS), with NVD's legacy CVSS v2.0 base and a vendor's own stated severity as last-resort fallbacks. EPSS is the only continuous modifier of the 0–10 number. EchelonGraph's own exploitation model does not move it: that signal feeds EG Risk, a separate 0–100 priority score. Every scored CVE also carries an SSVC decision (Act/Attend/Track*/Track) at each mission impact level: CISA's decision table, applied by EchelonGraph to CISA's own inputs where its Vulnrichment data publishes them. CISA publishes no SSVC decision for any CVE. It is not re-computed on every signal: a change to the CVE record, a CISA KEV listing, an ENISA EU KEV listing or withdrawal (since v4.1), newly recorded exploit code, a change to our EG-KEV tier, or an EPSS move that changes the 0–10 score queues a re-score ahead of the sweep; any other change, such as a GHSA update or an EPSS move that changes only EG Risk, is picked up by the rolling sweep at the CVE's priority-tier interval (below), so a stored score can trail it.
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 are floored at 9.0 and rated CRITICAL, CVEs with an EPSS exploit probability above 0.30 are lifted continuously toward 9.0, and disagreements between NVD and GHSA are flagged with explicit confidence indicators.
Why does EG sometimes equal NVD CVSS?
When nothing but a CVSS base is on record for a CVE — EPSS has not scored it (the model runs nightly, so a fresh CVE usually waits a day or two) or does not lift it, no GitHub advisory carries a CVSS that Rule 3 takes, and CISA has not KEV-listed it — there is no other signal to synthesize, so the EG score is that CVSS: NVD's own where NVD has scored the CVE, otherwise the CNA's, CISA-ADP's or a secondary source's, and the score's rationale and its “Triggered by” line name which. With no EPSS score it is flagged 'Aggregating' with LOW confidence (0.35); once EPSS has scored the CVE, the same rule carries MEDIUM confidence (0.60). A GitHub advisory CVSS lower than that score replaces it only when the advisory is newer than the CVE record's last change; one at or above it always does, and the rationale says which applies.
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 — above an exploit probability of 0.30 we raise the score continuously toward 9.0, reaching it at 0.85 (a smooth ramp, not a single 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 impact severity — EG Severity, the CVSS base score, never the KEV-floored or EPSS-lifted EG Score (45%) — exploitation — KEV, our exploitation model, and continuous EPSS (40%), and automatability — CISA's SSVC Automatable value where its Vulnrichment data has one, otherwise the CVE's CVSS v4.0 vector or CISA's own BOD 26-04 default (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 scored CVE also carries an SSVC decision — Act / Attend / Track* / Track — from CISA's decision table, applied by EchelonGraph, at low, medium and high mission impact, because SSVC is stakeholder-specific: the Mission & Well-being impact of the affected system is yours to judge, by CISA's definition. EG Risk's weights are set by hand, not fitted to outcomes.
What are EG Severity, EG Likelihood and EG Priority?
Since algorithm v4.0 every CVE that is not withdrawn carries the three questions the 0–10 EG score mixes, published apart, each with its source. EG Severity is impact severity alone: the CVSS base score (CVSS-B) from the best-provenance CVSS we hold, which no CISA KEV listing, ENISA EU KEV listing (since v4.1), EPSS or EG-KEV tier raises. With no CVSS of any version it is not assessed — “exploited; severity not yet published” on a CVE CISA's KEV or ENISA's EU KEV lists — and never a score of 0. EG Likelihood is FIRST's EPSS probability of exploitation activity within 30 days, labelled as FIRST's: it is not an EchelonGraph model. With no EPSS on record it is unknown, never 0. Confirmed exploitation — a CISA KEV listing, an ENISA EU KEV listing (since v4.1) or EG-KEV Tier 1 — is reported beside it and never folded into it. EG Priority is the decision: CISA's SSVC table as EchelonGraph applies it, and CISA BOD 26-04's remediation timeline, with the inputs both read. The EG score itself does not change: it is severity, escalated by confirmed exploitation, so a KEV-listed CVE with CVSS 5.4 still scores 9.0 CRITICAL, and its EG Severity says the impact is CVSS 5.4 MEDIUM.
What does the confidence indicator mean?
Every EG score carries a confidence rating — HIGH, MEDIUM, LOW or NONE, with a 0–1 number — set by the rule that produced the score. KEV-listed CVEs are HIGH (1.00). An EPSS-lifted score is HIGH (0.95 or 0.88) when the CVE ranks in EPSS's 99th or 95th percentile, otherwise MEDIUM (0.75). A GHSA score is HIGH (0.90) only when it is within 1.0 of the headline CVSS (NVD's own, else the CNA's, CISA-ADP's or a secondary source's) and the advisory is under 30 days old. A score that is the headline CVSS alone is MEDIUM (0.60) once EPSS has scored the CVE, otherwise LOW (0.35). CVSS v2.0 and vendor-prose fallbacks are always LOW. Since v3.3 each label's number stays inside a fixed range — LOW 0.01–0.49, MEDIUM 0.50–0.84, HIGH 0.85–1.00 — so a LOW never carries a higher number than a MEDIUM, nor a MEDIUM than a HIGH. A stale EPSS — no daily EPSS file has covered the CVE, and its value has not changed, for over 7 days — drops an EPSS-lifted or headline-CVSS-only score one tier, and its number into the lower tier's range. A rejected or unscored CVE is NONE (0). The full table is on this page. 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?
Two ways. When an input changes, the CVE is queued ahead of the sweep and the scheduler's next batch re-scores it (a batch starts every minute, or as soon as the last one ends): a new CVE's first score, a change to the CVE record (a CNA or NVD revision, a CVSS arriving, or a REJECTED status), a CISA KEV listing the score does not yet reflect, an ENISA EU KEV listing or withdrawal the score does not yet reflect (since algorithm v4.1), exploit code recorded after the last score, a change to our EG-KEV tier, and an EPSS move that changes the 0–10 score (a move inside the 0.30–0.85 ramp, a crossing of 0.30, or a probability of 0.85 or more on a CVE not yet CRITICAL). Any other change, such as a GHSA update or an EPSS move that changes only EG Risk, is picked up by the rolling sweep, which re-scores each CVE at its priority tier's interval: P0 (KEV-listed or score ≥ 9.0): every 24 hours; P1 (score 7.0–8.9): every 7 days; P2 (score 4.0–6.9): every 30 days; P3 (score below 4.0, or none yet): every 30 days; P-cold (published more than 5 years ago, score below 4.0): every 90 days. The sweep takes P0 rows ahead of every other tier, and we set these intervals from the scheduler's measured throughput. Measured 2026-10-29: P0 and P1 meet their intervals; P2, P3 and P-cold do not — no row is more than one whole interval late, but their oldest rows wait almost that long again past due, because a row less than an interval late is re-scored after the tiers above it, so for those three read the interval above as the target and roughly twice it as today's worst case.
See the EG score in action
Every scored CVE carries an EG Score, an EG Risk priority, an SSVC decision by mission impact (CISA's decision table, applied by EchelonGraph), a confidence indicator, and a rationale you can hover.