Vulnerability management
What TENSOR Vulnerability Management does, who uses it, the terms it uses and where to find it in the product.
TENSOR Vulnerability Management is the remediation control plane of the platform. It takes the weaknesses your existing scanners and advisory feeds report, connects them to the configuration items (CIs) and services in the CMDB, and routes the fix through governed Patch and Change processes. Every change leaves an append-only, hash-chained audit record, so the same data that drives daily work also produces the evidence auditors and supervisors ask for.
TENSOR does not scan hosts and is not a vulnerability encyclopedia. It works with the tools you already run (for example Tenable Nessus, Qualys or Rapid7) and focuses on what small, often regulated IT teams struggle with: deciding what to fix first, getting the fix approved and deployed, and proving it afterwards.
What is available today. The findings workspace, manual findings, triage, CVE exposures on CIs, the scanner integration, the patch catalogue, known-issue advisories, patch deployment as a Change and the critical-CVE and DORA evidence reports are available, some with limitations. Nessus file import, remediation groups, scan-verified closure, vulnerability risk acceptance, the evidence preflight and program rollups are Planned — not yet available. The Availability page has the full status table.
Who uses it
| Persona | Typical tasks |
|---|---|
| Vulnerability coordinator / infrastructure operator | Triages findings, plans patches and Changes, watches due dates. |
| Infrastructure and network administrators | Triage findings on the servers, network devices and clusters they own; record deployment outcomes. |
| CMDB administrator | Keeps CIs accurate so findings match the right asset. |
| Change manager / CAB member | Approves and schedules the Changes that deploy patches; decides on pending Changes when a patch has a known issue. |
| Compliance officer / risk approver | Generates regulatory evidence. Approving or rejecting time-bounded risk acceptances is Planned — not yet available. |
| Auditor | Read-only access to findings, the audit trail and sealed evidence reports. |
Problems it solves
- Scanner output arrives as tens of thousands of lines. TENSOR keeps one stable finding per weakness, asset and port. Recording the same source asset and finding key again returns the existing finding instead of creating a duplicate.
- Patching is a change to production. TENSOR creates the Change for you, with the affected CIs attached, so CAB approval, freeze windows and segregation of duties apply as for any other Change.
- Auditors want to see the whole chain. For every CVE on a CI, the DORA RTS Art. 10 remediation evidence report assembles the patch that closes it, the Change that deployed it, the Change's approval and state, the per-CI installation outcome and the resulting CVE status into a sealed, content-hashed report.
- A missing line in the next scan does not prove a fix. The host may have been offline or the credentials may have failed. Closing a finding only when a later scan explicitly covered the asset and completed is the target behaviour of scan-verified closure, which is Planned — not yet available.
- Accepted risks tend to be forgotten. Time-bounded, second-person-approved risk acceptance for findings is Planned — not yet available. Today, accepting the risk of a CVE exposure on a CI requires a co-signature from someone other than the person who recorded it.
Key concepts
| Term | Meaning |
|---|---|
| Vulnerability finding | One weakness observed by a source on one source asset, and where relevant one port and protocol. It is operational work with a lifecycle, not a global CVE entry. Shown in the product as Finding. |
| Vulnerability reference | An external identifier attached to a finding, such as a CVE ID. A finding can have none, one or several references; the same CVE can appear in many findings. |
| Patch | A vendor fix in the patch catalogue, with severity, product, KB article and the CVEs it closes. |
| Adoption | The share of applicable CIs on which a patch is installed. Shown as Not assessed when no CI has been assessed yet. |
| CVE exposure | A CVE recorded directly on a CI in the CMDB, with status Open, Mitigated or Risk accepted. The predecessor of findings, kept for compatibility. |
The following terms belong to capabilities that are Planned — not yet available. They are defined here so that you recognise them in the status table:
| Term | Meaning |
|---|---|
| Scan run | One staged and then committed import from one scanner source, with scanner timing and explicit asset coverage. |
| Scan asset | One source asset taking part in one scan run, with its completion state and its match to a CMDB CI. |
| Observation | Immutable evidence that a finding was present on a scan asset in a given scan run. |
| Covering scan | A committed scan that explicitly included the same source asset and completed. Only a later covering scan can prove that a weakness is gone. |
| Remediation group | A set of findings fixed through one common action, normally one patch or one Change. |
| Risk acceptance | A separately approved, time-bounded exception that pauses remediation for a finding. It expires or can be revoked; it never closes the finding. |
| Verified closure | Closure because a later covering scan no longer observes the weakness. The only outcome reported as "verified". |
| Manual closure | An exceptional, permission-gated closure without scan proof. Always shown and reported separately from verified closure. |
Where to find it
| Area | Navigation |
|---|---|
| Findings workspace | Assets & Risk > Vulnerabilities (/vulnerabilities) |
| Finding detail | Click a finding in the list (/vulnerabilities/findings/<id>) |
| Patch catalogue | Assets & Risk > Patches (/patches) |
| CVEs on one asset | Assets & Risk > Configuration Items > open a CI > CVEs panel |
| Evidence reports | Reports > Reports, section History |
| Feature switches | Admin > Regulatory features |
For the CI-level view of CVEs, their status workflow and the co-signature rule, see CVEs and lifecycle risk in the CMDB section.
In this section
- How it works — how the module fits into TENSOR, tenant isolation, entities, integrations, jobs, feature flags, data protection and the audit trail.
- Roles and permissions — permission keys, default role grants, segregation of duties and granting access.
- Findings and triage — the findings workspace, manual findings, triage, the scanner integration, CMDB context and CVE exposures.
- Patches and remediation — the patch catalogue and adoption, patch sources, known-issue advisories, patch deployment as a Change and per-CI outcomes.
- Reporting and evidence — the critical-CVE and DORA RTS Art. 10 evidence reports, sealing and the audit trail.
- Lifecycle — finding states and dispositions, CVE exposure and patch states, notifications and the end-to-end process per persona.
- Compliance — the regulatory requirements the module supports and which flags you need.
- Guides for coordinators and operators — step-by-step tasks for daily vulnerability and patch work.
- Guides for administrators and compliance — switching the module on, access, the scanner integration, the known-issue feed, evidence and audit history.
- Troubleshooting — common symptoms and questions.
- Availability — what is available on the current release, and the target behaviour of planned capabilities.
Availability
The implementation status of every Discovery capability as of 24 September 2026 — available, partially available or planned.
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.