Lifecycle

This page describes the states each vulnerability object moves through, who moves it, and how the work fits together across personas. Where a state or transition depends on a planned capability, it is marked as such.

Finding lifecycle

On the current release you can record a finding and triage it from New to Triaged; each step writes one audit event. The transitions beyond Triaged are Planned — not yet available.

Dispositions

Alongside the state, each finding has a disposition: active, risk_accepted, false_positive, decommissioned, manual_closed or scan_verified. The database only allows closed states with a closing disposition and open states with active or risk_accepted, so an accepted risk can never look closed. This pairing is already enforced by the database, although the outcomes that set the closing dispositions are planned.

Concurrent changes

Findings carry a version number. If someone else changed the finding while you were looking at it, TENSOR refuses your action with "The finding changed. Refresh and retry." Reload and check the current state before you try again.

CVE exposure on a CI

A CVE exposure recorded on a CI has one of three statuses: Open, Mitigated or Risk accepted.

• Record an exposure stores it as Open.
• Mark mitigated records that a fix or compensating control is in place; Reopen returns a mitigated exposure to Open.
• Accept risk needs a person other than the one who recorded the exposure. On this page a risk acceptance is final and cannot be revoked.

Each disposition and its time are recorded per CI and audited. The full status workflow is in CVEs and lifecycle risk.

Patch status per CI

Each patch has one status row per CI, with one of six values: Not applicable (N/A), Missing, In progress, Installed, Failed or Deferred.

• Deploy patch includes every CI whose status is Missing, and the status row records the deploying Change.
• The per-CI outcomes recorded on the Change — Installed, Failed or Deferred — flow back into the status.
• A Failed status keeps the failure reason.
• People with patch.status.write can record status per CI directly.

If no CI has a status for a patch yet, its adoption shows Not assessed.

Patch Changes

A patch deployment follows the regular Change lifecycle — see Changes:

1. Deploy patch creates a Normal Change linking every CI with status Missing, with a description from the patch and a predefined rollback plan.
2. The Change goes through the regular approval process. The requester cannot approve their own Change, and freeze windows apply. An Emergency Change is only created when explicitly requested.
3. The implementer records per-CI outcomes (Installed, Failed, Deferred) under Patch deployment outcomes; they flow back into patch status.

If a known issue is reported for a patch that a pending Change deploys, a Standard Change based on a template that is Approved or Scheduled loses its pre-authorization and goes back for a decision as a Normal Change; other pending Changes show the banner Known issue on a patch this change deploys. Withdrawing the advisory clears the mark but re-approves nothing.

Due dates and escalation

Planned — not yet available. Due dates are to be set at triage from the tenant's remediation policy and stored with the policy inputs used. Overdue findings and groups rise to the top of the queue, and overdue counts appear in the program rollups and the evidence preflight. Because the scoring inputs are frozen, a later change in an external feed cannot silently move a deadline. Due-date entry, the remediation policy settings, the group queue, rollups and preflight are all planned.

Other planned lifecycles

The import lifecycle (Staging, Ready, Committing, Committed, Rejected, Cancelled), the remediation group states (Open, Planned, In change, Awaiting verification, Closed), the vulnerability risk acceptance states (Requested, Approved, Rejected, Revoked, Expired) and the covering-scan rule that decides closure all belong to planned capabilities. They are described on Availability.

Notifications

• Critical CVE on a critical-function CI — a detection event into the DORA reporting workflow, with dora_detection_workflow on. The threshold is a CVSS score of at least the tenant threshold (default 7.0).
• Known issue on a patch — the change managers of affected pending Changes are informed, and Standard patch Changes go back for a decision.
• No per-finding notification fan-out — large scans do not flood inboxes.

End-to-end process per persona

This is the rhythm the available capabilities support today.

In the target design the coordinator also imports each scan, reviews coverage and matching, works a group queue, and reviews overdue, reopened, unmatched, expiring exceptions, manual closures and failed verifications weekly; the compliance officer decides risk acceptances and runs the evidence preflight. These steps are Planned — not yet available.