Risk scoring
Risk scoring is fully configurable from the Risk configuration panel, which you open by selecting the edit (pencil) icon on the Overall risk score card.
The risk score model
UVM scores every unified vulnerability with a layered model:
Risk = Threat × Context × Controls
Each layer answers one question, in order: how dangerous is this vulnerability, how much does it matter on this asset, and is anything already containing it? The model is layered, bounded, and zero-preserving — context can amplify a real threat but never creates risk where there is none, and control evidence can only reduce a score that exists. The configuration panel walks a worked example through each enabled layer as you adjust settings, so you can see the effect of every change on a real score.
Every signal that feeds the score enters at exactly one layer:
| Signal | Where it enters | Effect |
|---|---|---|
| CVSS | Threat | Technical impact, blended with EPSS |
| EPSS | Threat | Exploitation likelihood, blended with CVSS |
| KEV | Threat | A floor applied after the blend |
| Asset criticality | Context | Multiplier on the threat score, set per criticality level |
| Public exposure | Context | Multiplier on the threat score |
| Control evidence | Controls | Discount on the final score (off by default) |
Layer 1: Threat
The threat layer is a weighted blend of Technical impact (from CVSS) and Exploitation likelihood (from EPSS), each normalized to a 0–1 value first:
Threat = (CVSS weight × Technical impact) + (EPSS weight × Exploitation likelihood)
- Technical impact is the CVE's CVSS impact subscore normalized to 0–1 (divided by its 6.05 maximum). When a CVE reports no impact subscore, the CVSS base score divided by 10 is used instead.
- Exploitation likelihood is the CVE's EPSS probability, which is already a 0–1 value.
- The two weights default to 0.50 each and always sum to 1. A factor that is unavailable for a CVE contributes zero — the KEV floor below is the backstop that keeps actively exploited CVEs with missing or low EPSS data from scoring under your threshold.
A CVE listed in CISA's Known Exploited Vulnerabilities catalog is floored at a high threat value (0.90 by default on the 0–1 threat scale, configurable) regardless of its EPSS score. Many actively exploited CVEs carry low EPSS probabilities, and the KEV floor keeps confirmed exploitation from being scored below your threshold.
Layer 2: Context
The context layer applies multipliers for what the vulnerability sits on:
| Signal | Default multiplier |
|---|---|
| Asset criticality level | One multiplier per level, set in Risk configuration |
| Publicly exposed asset | ×1.2 |
Each level you define in Asset criticality has its own multiplier. The most critical level carries the highest multiplier, and you edit the multipliers in the context section of the Risk configuration panel. The criticality and exposure multipliers multiply together, so a critical asset that is also publicly exposed outranks an asset that is only one of the two.
An asset with no criticality level and no public exposure is scored exactly neutrally (×1.0). Unlike a weighted average, context can never dilute severity—an unclassified asset costs a vulnerability nothing.
Layer 3: Controls
The controls layer can apply a small discount (10 percent by default) while a vulnerability is mitigated by currently passing, technique-relevant control evidence — a Continuous Control Monitoring control test on the affected asset whose MITRE ATT&CK technique matches the vulnerability. Missing evidence never lowers a score, and the moment no relevant control passes, the full score returns on the next evaluation.
This layer is off by default. Enable it once your CCM controls carry MITRE ATT&CK technique mappings.
A worked example
Consider a CVE with a CVSS base score of 9.8, no impact subscore reported, and an EPSS probability of 0.10, found on an asset at your most critical level that is not publicly exposed. Suppose that level's multiplier is ×1.5, with default settings everywhere else:
- Threat — technical impact is 9.8 ÷ 10 = 0.98, and exploitation likelihood is 0.10. The blend is (0.50 × 0.98) + (0.50 × 0.10) = 0.54. The CVE is not in the KEV catalog, so no floor applies.
- Context — the criticality level's multiplier applies: 0.54 × 1.5 = 0.81.
- Controls — the layer is off, so the score stands at 0.81.
At 0.81 the vulnerability falls below the default 0.90 threshold and is not prioritized — a severe-but-unlikely-to-be-exploited CVE on an important asset. Now suppose CISA adds the CVE to the KEV catalog: the threat blend is floored at 0.90 before context applies, so the score becomes min(0.90 × 1.5, 1) = 1.0, and the vulnerability is prioritized. That is the model working as intended — confirmed exploitation outranks a low EPSS estimate.
Prioritization threshold
The Prioritization threshold sets the minimum score a vulnerability must reach to appear in the Prioritized view. The default is 90% (a score of 0.90). Score displays vary by surface: the Prioritized table shows scores on a 0–10 scale, and the entity inspector shows the same score on a 0–100 scale. Lower the threshold to widen the working list; raise it to focus on only the highest-risk vulnerabilities.
Querying risk scores
The J1QL function j1.riskScore(uv, ud) returns the risk score of a vulnerability on a device, on the same 0–100 scale as the entity inspector, so you can filter, sort, and aggregate on it in your own queries.
Plan priority thresholds
UVM assigns each remediation plan a priority of Critical, High, Medium, or Low based on how much risk reduction the plan delivers. The thresholds are expressed in standard deviations from the mean risk reduction across all plans, so they adapt to the shape of your environment.
| Priority | Default threshold | Approximate share |
|---|---|---|
| Critical | +1.5 standard deviations | Top ~7% of plans |
| High | +0.5 standard deviations | Top ~31% of plans |
| Medium | -0.5 standard deviations | Middle ~31% of plans |
| Low | Below medium threshold | Remaining plans |
You can adjust each threshold independently. UVM enforces the ordering rule that the Critical threshold must be greater than or equal to High, which must be greater than or equal to Medium.
Case routing namespace
The Cases — Ownership assignment setting controls which Hierarchical Resource Group namespace is used to determine asset ownership. When UVM creates a case for a remediation plan, it looks up the owning organizational unit in the selected namespace and routes the case to the team responsible for that unit. The panel shows the count of organizational units available in each namespace.
Click Reset to defaults at the bottom of the panel to return the scoring model and thresholds to JupiterOne's recommended starting configuration. The ownership namespace keeps its saved value.
Asset criticality and public assets
Two graph-derived signals—an asset's criticality level and its public exposure—feed directly into the risk score and appear in the Context column of the Prioritized view.
Asset criticality
An asset's criticality level comes from Asset criticality, where you define ordered levels and the J1QL queries that fill them. JupiterOne writes each asset's level to its j1.criticality and j1.normalizedCriticality properties, and the risk score applies that level's multiplier.
Risk scoring reads the level from the unified device. Setups proposed by the asset criticality agent already classify unified devices. When you write your own queries for devices, select unified devices so the level reaches the risk score, for example:
FIND UnifiedDevice THAT IS Host WITH tag.Environment = 'production'
The tag.crownJewel property no longer affects the risk score, and smart classes were not migrated into asset criticality. To weight your most important assets, set up asset criticality, or contact your Customer Success team to have your smart classes migrated.
Public assets
An asset is treated as publicly exposed when JupiterOne resolves its public property to Public. UVM merges signals from multiple sources to compute this property, including cloud provider configuration, network scanners, and external attack surface tools.
When sources disagree about an asset's exposure, the property resolves to Conflicting, which is a diagnostic state. Investigate conflicting assets to confirm their true exposure and update integrations as needed.