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 |
| Crown jewel | Context | Multiplier on the threat score |
| 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 bounded multipliers for what the vulnerability sits on:
| Signal | Default multiplier |
|---|---|
| Crown jewel asset | ×1.5 |
| Publicly exposed asset | ×1.2 |
The combined context multiplier is capped at ×1.5, and an asset with neither signal is scored exactly neutrally (×1.0). Unlike a weighted average, context can never dilute severity — an untagged 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 a crown jewel asset that is not publicly exposed, with default settings throughout:
- 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 crown jewel 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.
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.
Crown jewels and public assets
Two graph-derived signals — crown jewel status and public exposure — feed directly into the risk score and appear in the Context column of the Prioritized view.
Crown jewel assets
An asset is treated as a crown jewel when it carries the tag.crownJewel property. You can apply this tag in two ways:
- Vendor tags — Cloud and infrastructure tags imported through your integrations are evaluated automatically
- Smart classes — Author a J1QL Smart Class query that selects critical assets in your environment. Matching assets receive
tag.crownJewel = true.
Risk scoring reads crown jewel status from the unified device. Tags applied at the source asset propagate to unified devices on the unification cycle, which can take up to 7 days. For the fastest effect, author your Smart Class query against unified devices directly.
See Smart classes for details on authoring Smart Class queries.
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.