Availability

This page shows what is available on the current release, as of 24 September 2026. Capabilities marked Planned are specified target behaviour and are not yet available; the rest of this section describes them only as clearly labelled notes.

Implementation status

Target behaviour of planned capabilities

Everything below is Planned — not yet available. It is described so that you can plan your processes and role design; none of it works on the current release.

Nessus import with review

Scan results are to enter TENSOR by uploading a Nessus export (.nessus), alongside the scanner integration. An upload is never committed immediately. TENSOR first stages it and shows a review page with:

• scan timing and scanner version, and whether the exact file was already imported;
• asset coverage: completed, failed, credential failure, cancelled or unknown;
• asset matching to CIs: matched, unmatched, ambiguous or excluded;
• accepted and rejected observations, with reasons;
• the proposed effect: new, updated and reopened findings and closure candidates;
• proposed remediation groups by patch or common solution;
• explicit warnings where coverage cannot support closure.

You resolve ambiguous assets (vulnerability.import.resolve_match), decide for each unmatched asset whether to keep it unmatched — its findings appear in an Unmatched queue — or exclude it with a reason, and then commit once (vulnerability.import.run). Commit stays disabled while ambiguous assets remain. The commit is a single transaction; staging on its own creates no findings, starts no clocks and fires no events. The uploaded file is discarded after parsing; only normalized data and its SHA-256 hash are kept. Corrections after commit are a separate, explicit reconciliation, never a hidden change of history.

Assets are to be matched strictly from strongest to weakest identifier, never guessing between several CIs: an existing source binding first, then exact FQDN, then MAC address, then DNS or host name only if unique. An IP address is recorded for provenance only, because DHCP and NAT make it unreliable. A manual match decision can create a durable binding through the CMDB, so the next import matches automatically.

Covering-scan rule and governed outcomes

A later scan may close a finding only if all of the following hold: the scan is committed; it comes from the same scanner source and instance; the exact source asset is part of the scan; that asset's coverage state is completed; the scan is later than the finding's last observation; and the finding is absent from the results. Failed, credential-failed, cancelled, ambiguous, excluded or absent assets never close anything.

Every way a finding can leave active work is a distinct outcome:

A successfully implemented Patch or Change is to move a finding to Awaiting verification, not to closed. If a later covering scan still sees the weakness, verification fails and the finding stays active. If a closed finding is observed again, it reopens and its reopen counter increases. There is no bulk interface for false positive or manual closure.

Remediation groups and the group-first queue

A remediation group bundles findings that one action fixes. TENSOR is to propose groups deterministically, first by the same recommended patch and then by the same source solution, and you confirm the membership; there is no automatic clustering and no automatic Change submission. A group has an owner or team, a due date, a recommended patch and a linked Change, and moves through Open, Planned, In change, Awaiting verification and Closed. A finding belongs to at most one active group; membership history is kept, and once a Change is linked the member set is snapshotted and can only be revised explicitly.

The workspace is then to open on remediation groups, sorted by overdue, severity, critical-service impact and age, with the findings list as a secondary view and saved views for overdue, reopened, stale or unscanned, unmatched or ambiguous, expiring exceptions, manual closures and failed verification.

Vulnerability risk acceptance

A request is to name the finding or group, a rationale, a mandatory compensating control and an expiry date within the tenant's limit. Another person with approval authority approves (optionally with a shorter expiry) or rejects it. People who shaped the finding, derived from the audit trail, are not offered as approvers. States are Requested, Approved, Rejected, Revoked and Expired. An acceptance counts only while it is approved and its expiry date lies in the future; on expiry or revocation the finding returns to the active queue and an audit event is written. Risk above the platform's hard residual ceiling cannot be accepted by anyone. Accepting a general risk in the risk register never changes the state, SLA or due date of a linked vulnerability. Requests need vulnerability.exception.request and compliance_module; decisions need vulnerability.exception.approve.

Evidence preflight and program rollups

Before generating vulnerability evidence, a preflight is to list unverified or manual closures, expired acceptances, Changes without outcome, groups without owner, stale or unknown coverage and unmatched critical assets, so you can fix them and run it again until only accepted, labelled gaps remain. The report distinguishes scan-verified closure from manual closure, false positive, decommissioned and risk accepted. Program rollups are to show open by severity and service, overdue, median age, reopened, coverage freshness, verified versus manual closure, expiring exceptions and unmatched assets, with every rate showing its denominator and unknown coverage shown separately, including pseudonymized Works Council views.