Roles and permissions
The vulnerability and patch permission keys, their default role grants, the segregation-of-duties rules enforced in code and how to grant access.
Access to vulnerability and patch work is controlled by fine-grained permissions, bundled into standard roles. You can use the standard roles as they are or clone them into custom roles. For the full platform picture, see the role catalogue and segregation of duties.
Permissions
| Permission | Allows | Status |
|---|---|---|
vulnerability.finding.read | Open the Vulnerabilities workspace, list and view findings. | Available |
vulnerability.finding.triage | Record manual findings and triage findings. | Available |
vulnerability.import.run | Stage and commit scanner imports. | Gates the Nessus import, which is Planned |
vulnerability.import.resolve_match | Resolve ambiguous or unmatched assets in an import. | Gates the Nessus import, which is Planned |
vulnerability.group.manage | Create and revise remediation groups and link them to Patches and Changes. | Gates remediation groups, which are Planned |
vulnerability.exception.request | Request a risk acceptance. | Gates vulnerability risk acceptance, which is Planned |
vulnerability.exception.approve | Approve or reject a risk acceptance requested by someone else. | Gates vulnerability risk acceptance, which is Planned |
vulnerability.finding.manual_close | Close a finding without scan proof (manual closure, false positive, decommissioned). | Gates manual outcomes, which are Planned |
cmdb.cve.read / cmdb.cve.record | View CVE exposures on CIs / record and change their disposition. | Available |
patch.definition.read / patch.definition.manage | View the patch catalogue / create, edit and supersede patches and manage the known-issue feed. | Available |
patch.status.read / patch.status.write | View / record patch status per CI. | Available |
patch.deploy | Deploy a patch as a Change and record per-CI outcomes. | Available |
patch.source.configure | Configure patch advisory sources. | The subscription settings page is not yet built |
reporting.run | Generate evidence reports (together with read access to findings). | Available |
Permissions for planned capabilities already exist and appear in the default role grants below, but the capabilities they gate are not yet available.
Default role grants
| Role | Vulnerability Management | Patch Management |
|---|---|---|
Platform Owner (platform_owner) | All eight vulnerability permissions; CVE read and record | All patch permissions |
Tenant admin (tenant_admin) | None by default | Read and manage catalogue, read and write status, deploy |
CMDB admin (cmdb_admin) | Read, triage, resolve import matches; CVE read and record | Read and manage catalogue, read and write status, deploy |
Infrastructure admin (infrastructure_admin) | Read, triage, run imports; CVE read | None by default |
Network admin (network_admin) | Read, triage, run imports; CVE read | None by default |
Change manager (change_manager) | None by default | Read catalogue and status, deploy |
Compliance officer (compliance_officer) | Read, approve risk acceptance; CVE read | Read catalogue and status |
Auditor (auditor) | Read only; CVE read | Read catalogue and status |
Incident manager (incident_manager) | None | Read patch status |
Split by design
The requester and approver of a risk acceptance are deliberately given to different roles: coordinators request, compliance officers approve. No operational role receives both permissions just because it is labelled "admin".
Segregation of duties enforced in code
| Rule | How TENSOR enforces it | Status |
|---|---|---|
| Change approval stays with the CAB | Patch Changes use the normal Change process: the requester cannot approve their own Change, and freeze windows apply. | Available |
| CVE exposure risk acceptance | On the CMDB CVE exposure page a different person from the one who recorded the exposure must sign the acceptance. | Available |
| A risk acceptance needs a second person | The approver must differ from the requester. TENSOR derives the set of people who shaped the finding from the audit chain, not from editable fields, so recording someone else as requester does not bypass the rule. The requester field cannot be changed after the fact. | Planned for vulnerability risk acceptance |
| Manual closure is not ordinary triage | Closing without scan proof requires the separate vulnerability.finding.manual_close permission and a reason. | Planned |
| No bulk exceptions or bulk manual closures | There is no bulk interface for risk acceptance, false positive or manual closure. Each is decided and audited individually. | Planned capabilities; no bulk interface exists |
| Hard ceiling on accepting risk | Above a platform-defined residual-risk band nobody may accept the risk; it has to be treated. This ceiling is not configurable per tenant. | Planned for vulnerability risk acceptance |
The co-signature on the CMDB CVE exposure page is described in CVEs and lifecycle risk. Change approval rules are described in Approvals.
Granting access
- Open Admin > Roles.
- Either assign a standard role to the user under Admin > Users, or clone a standard role into a custom role (stored with the prefix
custom_). - Add or remove the vulnerability and patch permissions you need on the custom role.
- Assign the custom role to users or to a group.
Changes to role assignments are audited and notified to the Platform Owner. Permissions tagged as compliance-relevant, such as report exports, need approval by a second administrator before they take effect. You cannot edit a custom role you currently hold.
Choosing roles for common teams
- Infrastructure and network staff who triage findings on their own systems: the standard Infrastructure admin or Network admin role already reads and triages findings and reads CVE exposures. Neither has patch permissions by default; add patch permissions such as
patch.deployon a custom role if they deploy patches. - CMDB administrators who keep CI data and CVE exposures accurate: the standard CMDB admin role reads and triages findings, records CVE exposures and manages the patch catalogue.
- Change managers who deploy patches: the standard Change manager role reads the catalogue and status and may deploy.
- Compliance officers and auditors who need evidence: both standard roles read findings, CVE exposures and patch data. Generating evidence reports also needs
reporting.run.
The step-by-step version is in Give a team access to vulnerability work.
How it works
How Vulnerability Management fits into TENSOR — module boundaries, tenant isolation, entities, integrations, background jobs, feature flags, data protection and the audit trail.
Findings and triage
The findings workspace, manual findings, triage, the scanner integration, CMDB context and CVE exposures on CIs.