Skip to main content

​
Overview

Severity alone does not tell you what to fix first. CybeDefend computes a Priority Score for every detection — a weighted blend of four orthogonal signals — and exposes both the final score and the per-signal contributions so triage decisions are fully transparent.

Multi-signal

CVSS 4.0 environmental score · EPSS percentile · Exploitability · Business context

0–100 Score

A single user-facing number (priorityScore) sortable across all scanners

Priority Levels

Mapped into Critical Urgent · Urgent · Normal · Low · Very Low buckets

Full Decomposition

Each detection exposes the exact contribution of every signal

​
The formula

The internal composite score is a weighted sum of four normalized signals, each in [0, 1]: 
compositeScore = w1·CVSS4_norm  +  w2·EPSS_percentile  +  w3·Exploitability  +  w4·Context
The user-facing priorityScore is compositeScore × 100 (rounded to one decimal, bounded to [0, 100]).

​
Default weights

WeightSignalDefault
w1CVSS 4.0 (environmental score / 10)0.35
w2EPSS percentile (probability of exploit in the wild)0.25
w3Exploitability (verdict-driven)0.25
w4Context (business criticality + data classification)0.15
Weights are configured at the platform level (PRIORITY_WEIGHT_* env vars) and must always sum to 1.0. When EPSS is unknown for a detection, w2 is dropped and w1 / w3 / w4 are renormalized so the score remains comparable.

​
Signals in detail

​
1. CVSS 4.0 (environmental)

The CVSS 4.0 environmental score is preferred; the base score is used as a fallback, and finally a severity-default if no vector is available. The score is divided by 10 to land in [0, 1]. See CVSS 4.0 Scoring for how that score is built.

​
2. EPSS percentile

EPSS (Exploit Prediction Scoring System) percentile estimates the probability that a vulnerability will be exploited in the next 30 days, relative to all other CVEs. CybeDefend ingests EPSS for SCA and Container findings where a CVE identifier is available.

​
3. Exploitability

A qualitative verdict mapped to a numeric score:
VerdictScoreMeaning
not_exploitable0.05Demonstrated false positive / unreachable code path
theoretical0.35Default before deeper analysis
proven0.75Confirmed exploitable in this codebase
actively_exploited0.95Known to be exploited in the wild
For SCA detections, when Exploitable Path marks a dependency as unused, the exploitability contribution is forced to 0 — even before the verdict pipeline runs.
The verdict can come from three sources, persisted in exploitabilitySource:
  • static — heuristics on file path (test / vendor / example code is demoted) and reachability.
  • agent — Cybe Analysis LLM verdict with rationale.
  • manual — overridden by a user.

​
4. Context

The Context signal averages two project-level inputs:
Business CriticalityModifierData ClassificationModifier
Mission Critical1.0Regulated1.0
High0.7Confidential0.7
Medium0.4Internal0.4
Low0.2Public0.2
Unspecified0.5 (neutral)Unspecified0.5 (neutral)
Context = (BusinessCriticality + DataClassification) / 2

​
Priority levels

The composite score is mapped to a discrete priority level used by filters, dashboards, and policy rules:
Composite ScorePriority
≥ 0.80Critical Urgent
≥ 0.60Urgent
≥ 0.40Normal
≥ 0.20Low
< 0.20Very Low
Thresholds are configurable platform-wide (PRIORITY_THRESHOLD_* env vars).

​
Manual override

A user with the right permission can pin a priority manually on a detection. When set:
  • The composite score is no longer recalculated automatically.
  • The detection is flagged with priorityManualOverride: true and isManualOverride: true in the decomposition response.
  • Subsequent scans, Security Context changes, or EPSS refreshes will not touch the priority until the override is cleared.

​
Inspect the calculation

Every detection exposes a priority decomposition endpoint that returns the exact composition of its score: 
GET /project/{projectId}/results/{type}/{vulnerabilityId}/priority-decomposition
Response (abbreviated): 
{
  "decomposition": {
    "priority": "urgent",
    "compositeScore": 0.674,
    "cvss4Contribution": 0.287,
    "epssContribution": 0.142,
    "exploitContribution": 0.188,
    "contextContribution": 0.057,
    "w1": 0.35,
    "w2": 0.25,
    "w3": 0.25,
    "w4": 0.15,
    "isManualOverride": false
  }
}
Use the decomposition to explain to a developer why a vulnerability landed at a given priority — particularly useful when the Security Context or exploitability verdict moves a finding up or down.

​
How it impacts your workflow

  • Sorting — the Vulnerability List can be sorted by Priority Score across all scanners.
  • Filtering — filter by priority level (Critical Urgent, Urgent, Normal, Low, Very Low).
  • Top Vulnerabilities widget — see the Top Vulnerabilities page.
  • Policies — Policy Management can gate merges/deploys on priority-level rules.
  • Reports — emailed reports group findings by priority instead of raw severity.
Related: CVSS 4.0 Scoring · Exploitable Path · Policy Management · Top Vulnerabilities