Findings and triage

A finding is the unit of vulnerability work in TENSOR: one weakness observed by a source on one source asset, and where relevant one port and protocol. This page covers how findings reach TENSOR today, how you work with them in the workspace, and how they relate to the CVE exposures recorded on CIs in the CMDB.

Findings workspace

Assets & Risk > Vulnerabilities opens the list Vulnerability findings. Each row shows Finding, Severity, State, Source asset, References and Due. Severity uses five levels (Critical, High, Medium, Low, Informational); states are shown as coloured status pills. Use Load more to page through large lists — the list uses keyset pagination and is tested against 100,000 findings.

Partially available — list filters and search. Filtering by state and severity and text search exist in the API; the list page does not yet offer filter controls.

Opening a finding shows its Source identity (Source, Source asset, Port, Protocol), Recorded by and First seen, and the actions available in its current state. Back to findings returns you to the list.

The workspace needs the vulnerability_management flag and the vulnerability.finding.read permission. With the flag off, the navigation entry disappears and the page shows Vulnerability management is not configured. If nothing has been recorded yet, the list shows No vulnerability findings.

Planned — not yet available. A group-first queue, in which the workspace opens on remediation groups sorted by overdue, severity, critical-service impact and age, with saved views for overdue, reopened, stale or unscanned, unmatched or ambiguous, expiring exceptions, manual closures and failed verification. See Availability.

Where findings come from today

On the current release, findings enter the workspace in two ways:

• Manual findings recorded by people with the triage permission (see below).
• The legacy CVE backfill. CVE data that used to live directly on CIs is backfilled into findings with source kind legacy_cmdb.

The scanner integration with Tenable, Qualys and Rapid7 pulls into the CMDB CVE workflow, and discovery correlates software against vulnerability feeds; both are described further down. Importing a Nessus export file with review, coverage and asset matching is Planned — not yet available.

Manual findings

Not every weakness comes from a scanner: penetration test results, vendor notices or an administrator's own discovery can be recorded with Record manual finding. You enter:

• Finding — a short, descriptive title;
• Source asset key — a stable identifier of the affected asset, for example its host name or asset tag;
• Source finding key — a stable identifier of the weakness, for example the test report item number;
• References (comma-separated) — optional CVE IDs or other references;
• Severity.

Recording the same source asset key and source finding key twice returns the existing finding instead of creating a duplicate, because the source keys form the finding's identity; a title can be improved later. The new finding starts in state New, and one audit event is written.

Limitation. The CI link and the CVSS score of a manual finding can be set through the API only.

Triage

Triage confirms that a new finding is real work. Triage finding is shown on findings in state New to people with vulnerability.finding.triage; it moves the finding from New to Triaged and writes one audit event.

Partially available — due dates. The target design records a due date at triage together with a snapshot of the policy inputs that produced it, so that a later policy change never rewrites existing due dates and you can always explain why a finding was due when it was. Due-date entry and the remediation policy settings are planned — not yet available. Business calendars for due dates will come from the SLA module.

If someone else changed the finding while you were looking at it, TENSOR refuses the action with "The finding changed. Refresh and retry." Findings carry a version number, and a change submitted against an outdated version is refused. Reload the page and check the new state before trying again.

Scanner integration

A single adapter connects TENSOR to Tenable.io (primary), Qualys VMDR and Rapid7 InsightVM. It pulls assets and vulnerabilities on a schedule into the CMDB CVE workflow:

• Assets are reconciled to CIs by FQDN, DNS name or MAC address. For how the CMDB reconciles records from integrations in general, see Reconciliation.
• Open findings with a CVE are recorded on the matched CI.
• When the closing Change ships, a non-destructive "remediated" status can be pushed back to the scanner, so the next scan reconciles.
• An enabled scanner that is polled before it is fully wired reports a sync failure instead of a silent "nothing found".

API credentials are stored as integration secrets. The default configuration assumes a US-hosted SaaS console; confirm the data residency of your scanner console and pin an EU pod or on-premises console where available. The setup steps are in Connect a vulnerability scanner.

Planned — not yet available. A strict asset-matching order for imports (existing source binding, then exact FQDN, then MAC address, then DNS or host name only if unique, with IP addresses recorded for provenance only) and manual match decisions that create durable bindings belong to the planned Nessus import.

Discovery correlation

Software found by Discovery is correlated against the mirrored vulnerability feeds (CPE to CVE), with the matching evidence stored. The feeds are mirrored into EU storage and refreshed daily, so correlation needs no scan-time calls to US origins.

CMDB context and CVE exposures

On each CI, the CVEs panel lists the open CVEs with CVSS score and status and shows Suggested patches from the catalogue that close them. Impact and topology views show open-CVE counts, and CIs flagged as supporting a critical function are highlighted.

A CVE exposure is a CVE recorded directly on a CI, with status Open, Mitigated or Risk accepted. It is the predecessor of findings and is kept for compatibility: the old CVE tracker list (/cmdb/cves) now redirects to the findings view, while the per-CI CVEs panel and the CVE disposition page remain available. Recording exposures needs the cve_detection_ui flag and cmdb.cve.record.

The status workflow of a CVE exposure, the co-signature required to accept its risk and the DORA detection event it can raise are described in CVEs and lifecycle risk. Two points matter for vulnerability work:

• Accepting risk on the CMDB CVE disposition page needs a person other than the one who recorded the exposure, and the acceptance is final: it cannot be revoked. Time-bounded, revocable risk acceptance in the Vulnerabilities workspace is Planned — not yet available.
• If a CI supports a critical function and a CVE with a CVSS score at or above the tenant threshold (default 7.0) is recorded on it, a DORA detection event is raised when dora_detection_workflow is on.

Prioritisation signals

TENSOR prioritises with signals you can trace back: source severity and CVSS score, whether the CI supports a critical function, the services affected, the due date and overdue status, and age. Scoring inputs are frozen at the time they are used, so a later change in an external feed does not silently move a deadline. Threat-intelligence enrichment such as EPSS or the CISA KEV catalogue is not part of the product scope.

The queue that sorts work by these signals is part of the planned group-first queue; the frozen policy inputs arrive with due-date entry at triage. Both are Planned — not yet available.

Two scanners, one weakness

Findings are kept per source instance, so two scanners reporting the same weakness produce two findings. Cross-source merging requires a separate decision before a second overlapping source is enabled.