Why HailBytes ASM Scores Vulnerabilities the Way It Does: CVSS, EPSS, CISA KEV, and MITRE ATT&CK

A scanner that finds a thousand issues and tells you they are all “high” has not helped you — it has handed you a second triage job. The hard part of vulnerability management was never finding problems; it is deciding which five of the thousand to fix this week. HailBytes ASM answers that question with a single deterministic risk score in the range 0–100, computed from four independent signals. This post explains exactly how that number is produced and why each input is there.

The prioritization problem

CVSS alone is a famously poor prioritizer. The base score tells you how bad a vulnerability could be in the abstract, but the majority of high-CVSS vulnerabilities are never exploited in the wild, and a small number of medium-CVSS ones are exploited constantly. Sorting your backlog by CVSS descending means working through a pile of theoretically-severe issues while a known, actively-exploited bug sits lower on the list. The fix is to combine severity with two things CVSS does not know: how likely the vulnerability is to be exploited, and whether it already is.

The four inputs

• CVSS 3.1 base score (from the NVD 2.0 API) — the intrinsic severity of the flaw, 0–10.
• EPSS probability (from FIRST.org) — the modeled probability, 0.0–1.0, that the vulnerability will be exploited in the next 30 days.
• CISA KEV status — a boolean ground-truth signal: is this CVE on the Known Exploited Vulnerabilities catalog? KEV is the highest-confidence “exploited in the wild” feed available.
• Business criticality — a 1–5 scalar inherited from the affected target’s criticality rating (defaulting to 3), so the same flaw on a crown-jewel asset outranks it on a throwaway host.

The formula

The score is a base severity scaled by three independent multipliers. It is fully deterministic — identical inputs always compute the same score, which matters for reproducible reports and audit trails.

base       = max(cvss * 10, severity_floor)      # 0..100
multiplier = 1 + 0.1 * (business_criticality - 3) # 0.8 .. 1.2
epss_boost = 1 + 0.5 * epss_score                 # 1.0 .. 1.5
kev_boost  = 1.25 if is_known_exploited else 1.0

risk_score = min(100, base * multiplier * epss_boost * kev_boost)

A few design choices are worth calling out. The base uses a severity floor so findings without a CVE still get a sensible score — info maps to 5, low to 20, medium to 40, high to 60, and critical to 80 — and the higher of (CVSS×10, floor) wins. Business criticality is symmetric around the default of 3: a criticality-5 asset boosts the score by 20% while a criticality-1 asset discounts it by 20%, so the rating can demote noise as well as promote what matters. EPSS contributes up to a 50% boost, and KEV applies a flat 25% multiplier — a deliberate vote that “confirmed exploited” outweighs “modeled likely.” The final value is clamped to 100.

Worked example: a high-severity finding (base 60) with no CVSS, on a default-criticality asset, with a 0.4 EPSS score and a KEV listing, scores 60 × 1.0 × 1.2 × 1.25 = 90 — clearly ahead of a critical-CVSS finding (base 90) on the same asset with negligible EPSS and no KEV entry at 90 × 1.0 × 1.0 × 1.0 = 90, and pulling decisively ahead the moment the latter’s asset criticality is lower.

MITRE ATT&CK mapping

Where the data supports it, findings are tagged with MITRE ATT&CK technique IDs and, for KEV entries with documented attribution, named threat actors. The mapping is a curated lookup keyed on template type, matcher name, and CWE — for example, a remote-code-execution finding maps to T1190 (Exploit Public-Facing Application) and T1059 (Command and Scripting Interpreter). This is deliberately conservative: HailBytes does not invent CVE→technique mappings it has no ground truth for, because a confident-but-wrong attribution is worse than none.

Pipeline execution

The enrichment clients (NVD, EPSS, KEV) are rate-limited and cached — the KEV catalog is fetched once and held for 24 hours, and EPSS supports batched multi-CVE lookups in a single request. The pipeline degrades gracefully: if NVD is unreachable, the severity floor still produces a score; if EPSS or KEV are unavailable, their boosts simply default to 1.0 rather than failing the scan. Nothing in the scoring path can block a scan from completing.

Downstream impact

The risk score is not a vanity metric — it drives behavior across the platform. Dashboards sort by it, PDF reports lead with it, and SIEM dispatch severity floors key off it so your Splunk, Sentinel, or Cortex XSIAM pipeline only pages on what crosses your configured threshold. One number, computed the same way every time, from signals that actually predict exploitation.