Permissions
Access to Unified Vulnerability Management is governed by the App Level Permissions layer of JupiterOne's role-based access control system. Two permissions decide whether a user can open UVM at all, and a small set of additional permissions decides what that user can change once inside.
Opening UVM requires two permissions
Reaching the vulnerability pages is not a single permission. A user needs both of the following.
1. Permission to open the app — any one of:
| Permissions grid row | Level | Permission string |
|---|---|---|
| Vulnerabilities | Read-only | accessVulnerabilities |
| Vulnerabilities | Admin | adminVulnerabilities |
| Full Admin Access | Read-only | fullReadAccess |
| Full Admin Access | Admin | accessAdmin |
2. Permission to read graph data — any one of:
| Permissions grid row | Level | Permission string |
|---|---|---|
| Shared: Graph Data | Read | readGraph |
| Full Admin Access | Read-only | fullReadAccess |
| Full Admin Access | Admin | accessAdmin |
The vulnerability screens are built almost entirely from graph queries. A user who holds Vulnerabilities access but no graph read permission reaches the pages and sees empty tables, because the permission controls the door and graph read controls the data behind it.
Your account also needs the Unified Vulnerability Management entitlement. If Vulnerabilities does not appear in the navigation for a user who holds the permissions above, confirm the entitlement with your JupiterOne representative.
What each action requires
Every action below also requires app access and graph read, described above. The permissions listed here are what each action needs in addition.
| Action | Additional permissions required |
|---|---|
| View vulnerabilities, remediation plans, the executive dashboard, and emerging threats | None — app access and graph read are enough |
| Change a vulnerability's lifecycle state, individually or in bulk | Full Admin Access: Admin, or both Vulnerabilities: Admin and Shared: Graph Data: Write |
| Edit the risk configuration — scoring weights and plan priority thresholds | Vulnerabilities: Admin or Full Admin Access: Admin |
| Edit the Jira status mapping | Vulnerabilities: Admin or Full Admin Access: Admin |
| Rebuild remediation plans on demand, or bulk-delete plans | Vulnerabilities: Admin or Full Admin Access: Admin |
| Manage crown jewel queries | Vulnerabilities: Admin or Full Admin Access: Admin |
| Create a Jira ticket from a remediation case | Vulnerabilities: Admin or Full Admin Access: Admin |
| Create a Jira ticket from a compliance control | Full Admin Access: Admin |
Two of these deserve elaboration:
- Lifecycle changes need both halves. Changing a vulnerability's state writes to the graph, so a vulnerability admin without graph write sees the status controls disabled. Graph write on its own does not confer authority over vulnerability decisions either. Users who triage vulnerabilities need Vulnerabilities: Admin and Shared: Graph Data: Write together.
- Ticket creation is scoped to remediation cases. A vulnerability admin can create the Jira ticket for a remediation case, and needs no Shared: Graph Data: Write to do it — unlike a lifecycle change, which records the vulnerability's new state in the graph. The permission reaches no further: ticketing a compliance control still requires Full Admin Access: Admin, and so does configuring Data Out itself — creating, editing, enabling, disabling, or deleting a ticketing workflow instance, and managing the Jira and ServiceNow connections behind it. A vulnerability admin can send a case's ticket but cannot change where it goes. Vulnerabilities: Read-only cannot create tickets at all; a read-only user sees the ticketing workflows configured for the account, but creating a ticket is a write.
Read access to configuration is deliberately broader than write access. Anyone who can open UVM can read the risk configuration and the Jira status mapping — the risk configuration opens as a read-only view with a banner, and the status mapping page hides its Save and Restore defaults controls rather than disabling them.
Granting the permissions
The two vulnerability permissions appear as the Vulnerabilities row in the App Access section of the permissions grid, in the same read-only and admin pair as every other JupiterOne app. Only an account administrator can grant them.
- Navigate to Settings > User groups
- Select the group you want to edit
- In the App Level Permissions section, set the level on the Vulnerabilities row
- On the Shared: Graph Data row, set Read for users who view vulnerabilities, or Write for users who change vulnerability states
- Select Save group
Grant Vulnerabilities: Read-only to users who need to browse vulnerabilities, plans, and dashboards. Grant Vulnerabilities: Admin to users who also act on vulnerabilities, and pair it with Shared: Graph Data: Write so that lifecycle changes succeed.
Permissions are evaluated at login. A user whose group permissions change needs to sign out and sign back in before the change takes effect.
Granting the vulnerability permissions takes nothing away from existing administrators. Anyone with Full Admin Access: Admin retains every UVM action.
Troubleshooting
| Symptom | Cause | Resolution |
|---|---|---|
| Vulnerabilities appears in the navigation, but every table is empty | The user holds a vulnerability permission but no graph read permission | Add Shared: Graph Data: Read (or Full Admin Access: Read-only) to the group |
| Vulnerabilities does not appear in the navigation at all | The account lacks the UVM entitlement, or the user holds none of the four permissions that open the app | Confirm the entitlement, then add Vulnerabilities: Read-only along with a graph read permission |
| The lifecycle status controls are disabled when vulnerabilities are selected | The user holds Vulnerabilities: Admin but not Shared: Graph Data: Write | Add Shared: Graph Data: Write. Hovering the disabled control shows a tooltip naming what is missing |
| The Jira status mapping page has no Save button | Working as designed — the controls are hidden, not disabled, without Vulnerabilities: Admin or Full Admin Access: Admin | Add Vulnerabilities: Admin |
| The risk configuration opens, but every field is locked | Working as designed — it is a read-only view for anyone without Vulnerabilities: Admin | Add Vulnerabilities: Admin |
| A group permission changed, but the user sees no difference | The user has not signed out since the change, or only one of the two required halves was granted | Confirm both the Vulnerabilities and Shared: Graph Data levels, then have the user sign out and sign back in |
| A user can change vulnerability states but cannot create a ticket for a case | The user holds Vulnerabilities: Read-only rather than Vulnerabilities: Admin, or has not signed out since the level changed | Set the Vulnerabilities row to Admin, then have the user sign out and sign back in |
| A vulnerability admin can ticket a remediation case but not a compliance control | Expected — ticketing a compliance control requires Full Admin Access: Admin | No group-level change grants control ticketing to a vulnerability admin today |
| Ticket creation is refused for one particular case | The case covers an entity the user cannot see in the graph under their query policy | Widen the group's Data Layer RBAC query policy, or have a user with broader data access create the ticket |
Related topics
- Role-Based Access Control (RBAC)
- IAM operations — the permission strings above are set through the
abacPermissionsfield - Unified Vulnerability Management
- The vulnerability lifecycle
- Risk scoring
- Cases and Jira sync