UVM 2.0 Release Notes

Release date: August 2026

UVM 1.0 turned raw scanner findings into a prioritized, team-routed list of remediation plans. UVM 2.0 makes JupiterOne the system of record for what happens next. Every vulnerability on every asset now carries a lifecycle state — open, remediated, exempted, mitigated, or closed — tracked in one place across all of your scanners, verified against scanner evidence, and synchronized with Jira in both directions. You no longer log into five consoles to answer "what is the status of this vulnerability?", and your decisions are never silently overwritten by a rescan.

What is new

Feature	What it means for you
Vulnerability lifecycle tracking	Eight lifecycle states per vulnerability per asset — one source of truth for vulnerability status across every scanner you run
Verified fixes	Mark remediated claims a fix; JupiterOne verifies the claim against scanner evidence and distinguishes claimed-and-confirmed fixes from assumed ones
Exemption management	Accept risk or mark a vulnerability non-exploitable with a justification and an expiry date. Exemptions expire to a review queue — never silently, and never straight back to open.
Control-backed mitigations	Link a mitigation to a passing Continuous Control Monitoring control. If the control later fails or is deleted, the vulnerability reopens automatically.
The Inbox	A single decision queue for everything that needs a human: vulnerabilities your scanners no longer observe, claimed fixes still being detected, expiring exemptions, and ticket disagreements — with bulk actions
Bidirectional Jira sync	Closing a Jira ticket proposes the matching lifecycle state in JupiterOne, and case progress writes back to Jira — with a configurable status mapping per project and issue type
Executive dashboard	Historical reporting on remediation outcomes: open vulnerabilities over time, time to remediate by team, reopens by fix confidence, and accepted risk over time
Layered risk scoring	A new Threat × Context × Controls model with a KEV floor replaces the additive weighted blend from UVM 1.0

The vulnerability lifecycle

The centerpiece of UVM 2.0 is the lifecycle state machine. JupiterOne tracks two things independently for every vulnerability on every asset: what your scanners currently observe, and what your team has decided. Scanner evidence never silently overwrites a human decision — a rescan reopens a fixed vulnerability, but it never reopens a false positive, an accepted risk, or a mitigation.

For the full model — the eight states, verification, exemptions, and what happens when a scanner detects a closed vulnerability again — see The vulnerability lifecycle.

The Inbox

The Inbox is the analyst work queue for UVM 2.0. Nothing in the lifecycle changes silently: scanner signals arrive here as proposals for a human to confirm, in bulk. Sections include vulnerabilities no longer observed by any scanner (bulk mark fixed), claimed but still observed fixes (bulk reopen), expiring exemptions, and ticket disagreements where a Jira closure conflicted with a decision made in JupiterOne.

Bidirectional Jira sync

Remediation owners live in Jira, so the ticket is now a first-class way to drive the lifecycle. When a linked ticket closes, its Jira resolution translates into the matching vulnerability state — a ticket resolved as Patched enters verification rather than closing outright, and a ticket resolved as Won't Do proposes an accepted-risk exemption with an expiry date. In the other direction, case progress updates the Jira ticket's status and resolution. You configure the mapping per Jira project and issue type.

Executive dashboard

UVM 2.0 adds daily snapshots and a dedicated executive dashboard, so leadership sees remediation progress rather than raw findings: open vulnerabilities over time, current exposure by severity, time to remediate by organizational unit (verified fixes and dispositions reported separately), reopens by fix confidence, and accepted risk over time. Historical views are point-in-time records and support CSV download.

Layered risk scoring

UVM 2.0 replaces the additive weighted risk score from UVM 1.0 with a layered model:

Risk = Threat × Context × Controls

• Threat blends technical impact (CVSS) with exploitation likelihood (EPSS). A CVE listed in CISA's Known Exploited Vulnerabilities catalog is floored at a high threat score regardless of EPSS.
• Context applies bounded multipliers for crown jewel assets and public exposure. Context can amplify a real threat but never creates risk where there is none, and untagged assets are scored neutrally.
• Controls can apply a small discount when a vulnerability is mitigated by currently passing, technique-relevant control evidence. Missing evidence never lowers a score. This layer is off by default.

If you tuned score weights in UVM 1.0, review the new configuration — the old sum-to-one weight sliders no longer exist. See Configure risk scoring.

Upgrading from UVM 1.0

UVM 2.0 is enabled per account on a coordinated schedule. Two things to know:

warning

As part of enablement, existing remediation plans and cases are regenerated on the new lifecycle model. Plan and case history from UVM 1.0 does not carry over — export anything you need before your scheduled enablement, and expect plan and case identifiers to change. Your JupiterOne account team coordinates the timing with you.

• Vulnerability findings, unified vulnerabilities, and risk configuration are unaffected.
• Lifecycle states start fresh: every observed vulnerability begins as Open until your team or your tickets act on it.

Supported scanner integrations

Scanner support is unchanged from UVM 1.0: CrowdStrike Falcon, Qualys VMDR, SentinelOne, Tenable.io, and Wiz, plus SBOM-sourced findings. UVM tracks vulnerabilities on unified devices — servers, laptops, and cloud instances. Application-level weaknesses without a CVE and ephemeral container workloads are not yet in scope.

Getting started with 2.0

1. Confirm your scanner integrations are syncing and your risk configuration reflects the new layered model
2. Confirm your analysts have graph-write permission — vulnerability state transitions require it
3. Configure the Jira status mapping for each project and issue type you route cases to, and verify a test ticket round-trips
4. Make the Inbox part of your team's weekly routine — it is where verification, expiring exemptions, and ticket disagreements wait for a decision
5. Open the Executive dashboard after your first week of snapshots to baseline time to remediate and accepted risk

For full feature documentation, see Unified Vulnerability Management.