Unified Vulnerability Management
JupiterOne Unified Vulnerability Management (UVM) takes the raw output of every vulnerability scanner you run and turns it into a short list of remediation plans, routed to the right team. You see one row per vulnerability per asset across all sources, you prioritize using a risk score you control, and you act on plans rather than triaging a million findings.
UVM is designed for security analysts who triage findings, security leaders who need a defensible prioritization model, and the service owners who actually apply the fixes.
Overview
Unified Vulnerability Management enables your team to:
- Deduplicate vulnerability findings across infrastructure scanners, cloud-native tools, and endpoint platforms into a single row per vulnerability per asset
- Prioritize using a transparent risk score that combines CVSS, EPSS, crown jewel status, and public exposure, with weights and thresholds you configure
- Group prioritized vulnerabilities into remediation plans that share a common fix, so your teams act on dozens of plans instead of thousands of CVEs
- Route cases to the team that owns the affected assets through Hierarchical Resource Groups, with AI-generated remediation context attached
- Ask the AI assistant to sort, filter, and navigate the UVM views in natural language
The summary header on every UVM page shows:
- Overall risk score — the aggregate risk across your unresolved vulnerabilities (0–10)
- Unresolved vulnerabilities — total deduplicated vulnerabilities still open
- Critical findings — count of critical-severity vulnerabilities, broken down by how many are prioritized and how many lack a plan
- Active remediation cases — count of cases currently routed to your service teams
The prioritization funnel
Every UVM view is a stage in a single funnel. You start with raw findings on the left and end with team-routed cases on the right. The Sankey diagram at the top of every UVM page shows the live shape of the funnel for your environment, including which scanners are contributing to each stage.
The four stages are:
| Stage | What it contains | What it answers |
|---|---|---|
| Vulnerabilities | Raw findings, one row per scanner per asset per CVE | Which vulnerabilities did each tool report? |
| Unified | Deduplicated vulnerabilities, one row per CVE per asset, with all reporting sources rolled up | What is the real, unique set of vulnerabilities I have? |
| Prioritized | Unified vulnerabilities whose composite risk score exceeds your configured threshold | Which vulnerabilities should I work on first? |
| Remediation plans | Prioritized vulnerabilities grouped by a common fix, routed to owning teams as cases | What is the smallest set of actions that addresses the most risk? |
Each stage is a tab in the UVM navigation. You can click any node in the Sankey diagram to filter the underlying table to that segment of the funnel.
All vulnerabilities
The Vulnerabilities tab shows raw findings exactly as your scanners report them. One row exists for every (scanner, asset, CVE) tuple. This is the data ingestion layer of UVM — the same vulnerability seen by three scanners on one host appears as three rows here.
Use this view when you need to:
- Audit which scanner reported a specific finding
- Compare coverage between tools
- Investigate why a finding does or does not appear in the Unified view
Columns: Vulnerability, CVE, Asset, Source, CVSS, Severity, Age, Remediation plan.
Filters: Source (scanner integration), CVSS range, Severity, Age. The Search field matches against CVE identifier, vulnerability title, and asset name.
The Remediation plan column links each finding to the plan that addresses it, when one exists. Findings without a plan show an em dash.
Unified vulnerabilities
The Unified tab is where deduplication happens. JupiterOne aligns vulnerability data from every configured scanner against a single ontology and collapses duplicate findings into one row per CVE per asset. The Sources column shows which scanners reported each finding.
Columns: Vulnerability, CVE, Asset, Severity, CVSS, EPSS, KEV, Sources.
Filters: Severity, CVSS range, Source, Age.
EPSS and KEV
The Unified view enriches every CVE with:
- EPSS — The Exploit Prediction Scoring System probability, expressed as a percentage. This is the likelihood that the vulnerability will be exploited in the wild in the next 30 days, sourced from FIRST.org and updated weekly. The exact data refresh date is shown above the table.
- KEV — A chip indicating that the CVE appears in CISA's Known Exploited Vulnerabilities catalog. KEV CVEs have confirmed in-the-wild exploitation.
Sort by EPSS descending to see the vulnerabilities most likely to be exploited soon. Combine the KEV filter with the Severity = Critical filter for a focused view of CVEs that are both severe and actively exploited.
Source attribution
Each row shows a chip for every scanner that reported the underlying finding. A CVE seen by CrowdStrike, SentinelOne, Tenable, and Wiz on the same host appears as one row in this view with four source chips. Click any row to inspect the underlying raw findings.
UVM ships with first-class support for the following scanner integrations:
- CrowdStrike Falcon
- Qualys VMDR
- SentinelOne
- Tenable.io
- Wiz
Findings from Software Bill of Materials (SBOM) ingestion also appear as a source chip on affected assets.
Prioritized vulnerabilities
The Prioritized tab shows the subset of unified vulnerabilities whose composite risk score exceeds the prioritization threshold you have configured. This is the working list for your security analyst.
Columns: CVE, Owner team, Asset, Risk (composite score 0–10), Severity, CVSS, EPSS, KEV, Context.
Filters: Team, Severity, CVSS, Context, Source, Age.
What "prioritized" means
A vulnerability is prioritized when its composite Risk score is greater than or equal to the prioritization threshold. The default threshold is 65%, meaning a vulnerability must score at least 6.5 out of 10 to appear here. You can adjust both the score weights and the threshold from the Risk configuration panel.
Owner team
The Owner team column shows which organizational unit owns the affected asset. This drives where the case is routed when a remediation plan is created. The team is derived from your Hierarchical Resource Groups configuration.
Context
The Context column surfaces asset-level signals that influenced the risk score, including whether the asset is tagged as a crown jewel and whether it is reachable from the public internet.
Remediation plans
The Remediation plans tab is where your team takes action. A plan groups multiple prioritized vulnerabilities that share a common fix — for example, all CVEs resolved by patching Apache ActiveMQ to 5.18.3.
Each plan card shows:
- Title — A descriptive action statement (for example, "Upgrade Apache ActiveMQ to 5.18.3+ or 5.17.6+")
- Owner team — The organizational unit responsible for the plan, or an em dash if no owner is assigned
- Severity — The highest severity across the plan's CVEs
- Matched by product name — How the plan was grouped. UVM groups vulnerabilities by Common Platform Enumeration (CPE), using the product name resolved from each finding.
- Case coverage — Percentage of affected assets covered by a routable case
- Risk reduction — The total risk score reduction your environment achieves when this plan is completed
- CVEs covered — Number of unique CVEs addressed by this plan
- Highest CVSS — The most severe CVSS score among the plan's CVEs
Filters: Severity, CVSS (sortable by Highest CVSS), Age.
Plan detail
Click any plan card to open the plan detail panel.
The plan detail panel provides:
- Remediation summary — An AI-generated description of the vulnerability, its impact, and why the plan should be prioritized
- Plan metrics — Risk reduction, CVEs covered, CVEs in KEV, Highest CVSS, Highest EPSS
- Stat tabs — Counts and lists for Assets, Cases, and CVEs included in the plan
- AI remediation steps — Step-by-step fix instructions generated for this specific plan
- Properties, Tags, Metadata, and Raw Data tabs for the underlying graph entity
The plan persists as a graph entity in your JupiterOne account, so you can query plans with J1QL alongside the rest of your asset data.
Configure risk scoring
Risk scoring is fully configurable from the Risk configuration panel, which you open by clicking the gear icon next to the Overall risk score card.
The risk score formula
The composite risk score for every unified vulnerability is computed as:
Risk Score = w₁ × (CVSS / 10)
+ w₂ × EPSS
+ w₃ × tag.crownJewel
+ w₄ × (public = 'Public')
Where the four factor weights sum to 1.00.
Factor weights
| Factor | What it represents | Default weight |
|---|---|---|
| CVSS Score | Technical severity from the National Vulnerability Database, normalized to 0–1 | 0.50 |
| EPSS Score | Exploitation probability over the next 30 days, from FIRST.org | 0.35 |
| Crown jewel | Whether the affected asset is tagged as a critical asset (0 or 1) | 0.15 |
| Public exposure | Whether the affected asset is reachable from the public internet (0 or 1) | 0.00 |
Adjust any weight using the slider next to it. The remaining weights rebalance so the total always equals 1.00. The score formula at the top of the panel updates live as you adjust.
Prioritization threshold
The Prioritization threshold sets the minimum risk score a vulnerability must reach to appear in the Prioritized view. The default is 65%. Lower the threshold to widen the working list; raise it to focus on only the highest-risk vulnerabilities.
Case priority thresholds
When remediation cases are created from plans, UVM assigns each case a priority of Critical, High, Medium, or Low based on how much risk reduction the case delivers. The thresholds are expressed in standard deviations from the mean risk reduction across all cases, so they adapt to the shape of your environment.
| Priority | Default threshold | Approximate share |
|---|---|---|
| Critical | +1.5 standard deviations | Top ~7% of cases |
| High | +0.5 standard deviations | Top ~31% of cases |
| Medium | -0.5 standard deviations | Middle ~31% of cases |
| Low | Below medium threshold | Remaining cases |
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 — Organizational unit namespace 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 all weights, thresholds, and the namespace to JupiterOne's recommended starting configuration.
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 = trueand immediately influence prioritization.
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.
Cases and Jira routing
A remediation case is a unit of work scoped to a single owning team. When you create cases from a plan, UVM partitions the plan's affected assets by their owning organizational unit and creates one case per unit. Each case carries:
- The plan's AI-generated remediation summary and step-by-step instructions
- The list of affected assets in that unit's scope
- The risk reduction the team will deliver by completing the case
- A computed case priority (Critical, High, Medium, or Low) based on the configured thresholds
Cases route to Jira through your configured Jira integration. The owning team's Jira project is taken from the Hierarchical Resource Group routing configuration for the organizational unit.
See Jira for details on configuring the Jira outbound integration.
AI Assistant
The Ask AI button in the UVM header opens the AI Assistant sidebar. The assistant operates on the current UVM view and helps you sort, filter, and navigate without writing queries.
The assistant supports natural-language commands such as:
- "Sort by EPSS descending"
- "Filter to plans addressing critical vulnerabilities"
- "Which plan should I start with for the most impact?"
- "How are plans created, and what do confidence levels mean?"
When the assistant references a specific entity in its response, click the reference to open the entity inspector with full context.
The AI Assistant is in beta. Responses can occasionally be incorrect, and very large contexts can slow the response. JupiterOne does not use your workspace data to train its models.
Getting started
Step 1: Confirm your scanner integrations are configured
UVM aggregates findings from your configured integrations. From Integrations, confirm that at least one of the following is configured and syncing:
- CrowdStrike Falcon
- Qualys VMDR
- SentinelOne
- Tenable.io
- Wiz
You can see how many findings each scanner is contributing by hovering any source node in the Sankey diagram on the UVM landing page.
Step 2: Tag your crown jewel assets
Crown jewel status is a major lever in the default risk score. To make sure your most important assets surface near the top of the Prioritized view:
- Identify the assets that are business-critical (production databases, payment systems, customer-data stores)
- Apply
tag.crownJewelin your cloud or infrastructure provider, or - Author a Smart Class J1QL query that selects them
Tagged assets immediately influence prioritization on the next risk score evaluation.
Step 3: Set your prioritization threshold and weights
- Open the Risk configuration panel by clicking the gear icon next to the Overall risk score card
- Review the default factor weights (CVSS 0.50, EPSS 0.35, Crown jewel 0.15, Public 0.00)
- Adjust weights to match your organization's risk priorities. For example, increase Crown jewel weight if you want asset criticality to dominate; increase Public weight if internet exposure is a top concern.
- Set the Prioritization threshold percentage. A lower threshold widens the Prioritized view; a higher threshold tightens it.
- Click Apply changes
Step 4: Confirm case routing is configured
- From the Risk configuration panel, select the Cases — Organizational unit namespace you use for team routing
- Confirm each organizational unit in that namespace has an owner email and Jira project configured
- Open the Plans tab and confirm that plans show owner teams (rather than em dashes) on the cards you intend to route
Step 5: Create your first cases
- Open the Plans tab and sort by Highest CVSS or Risk reduction
- Open the highest-priority plan
- Review the AI-generated remediation summary and steps
- Confirm the affected assets and the owning teams
- Create cases for the plan — UVM partitions the assets by owning team and creates one Jira ticket per team
Step 6: Monitor progress
- The Active remediation cases count on the summary header tracks open cases
- The Critical findings card shows how many critical-severity vulnerabilities lack a plan
- Open the Plans tab regularly to review case coverage and apply new plans as new vulnerabilities surface
Best practices
Start narrow, then widen
Begin with the default risk configuration and a small set of crown jewel assets. Work through the top-of-funnel plans for that subset before widening crown jewel coverage or lowering the prioritization threshold. This produces a manageable Prioritized list and gives your team a clear early win.
Use plans, not individual findings
The Plans view is the right working list for most teams. A plan represents the smallest action that addresses the most risk, and one case routed to one team replaces dozens of duplicate tickets across owners. Investigate individual findings only when a plan is unclear or when you need to audit a specific scanner result.
Tune the weights, not the thresholds
The fastest way to change which vulnerabilities surface as prioritized is to adjust the factor weights, not the threshold percentage. For example, raising the EPSS weight gives more priority to in-the-wild exploitation; raising the Crown jewel weight gives more priority to business-critical assets. The threshold should change only when you want to widen or tighten the size of the Prioritized view.
Watch the Sankey diagram
The Sankey diagram at the top of every UVM page is your fastest signal that something is wrong upstream. Sudden drops in source contributions, missing scanners, or unusually wide gaps between Unified and Prioritized stages usually point to integration or configuration issues rather than vulnerability changes.
Document exemptions in your ticketing system
When a case is closed without remediation (false positive, compensating control, accepted risk), record the rationale in the Jira ticket. This preserves an auditable trail that your security team can reference during future evaluations of the same plan.