Patches and remediation

Patch Management is the part of remediation that is available today. The patch catalogue tells you which vendor fix closes a CVE and how widely it is installed; Deploy patch turns it into a governed Change; and the implementer records the outcome per CI on that Change.

Patch catalogue and adoption

Assets & Risk > Patches lists all known patches with Vendor, Product, Severity, Adoption %, Missing CIs, CVE IDs and KB Article. You can filter by severity, vendor and CVE, search by vendor or product, and sort by release date or severity. Sorting and search run on the server across the whole catalogue, not only across the rows already loaded. Patch severities are Critical, Important, Moderate and Low.

If an old filter value no longer exists, TENSOR ignores it and tells you which values were ignored. Use Clear filters to start over.

Adoption is the share of applicable CIs on which a patch is installed, and it is shown honestly:

• If no CI has been assessed against a patch, the column shows Not assessed instead of a misleading 0 %.
• A measured 0 % stays red.

Below the list, the Service Patch Rollup shows adoption and critical missing patches per service, and the Patch Compliance Trend dashboard widget shows the 90-day trend.

The Patch details page shows the CVE references, the KB article and the CI deployment status for every tracked CI. Show missing CIs lists the CIs that still need the patch.

Patch status per CI

Each patch has one status row per CI: Not applicable (N/A), Missing, In progress, Installed, Failed or Deferred. A failed row keeps its failure reason, and a row that is being deployed records the deploying Change. People with patch.status.write record status per CI; deployment outcomes on a patch Change update it automatically.

Suggested patches on a CI

The catalogue also appears in the CMDB. On each CI, the CVEs panel shows Suggested patches from the catalogue that close the open CVEs, so you can go from an exposed asset straight to the fix. See CVEs and lifecycle risk for the CI-level view.

Patch sources and advisory ingestion

Patches can be recorded manually or ingested from vendor advisory feeds. Source kinds are Microsoft Update Catalog (MSRC), Ubuntu USN, Red Hat RHSA, NIST NVD and manual entry. The Microsoft Update Catalog is the canonical source with a working parser. Each tenant subscribes only to the sources relevant to its estate.

Ingestion runs daily at 06:00, is idempotent per source and KB article, and maintains the supersession chain. The outcome is recorded per source; a failing source is listed with its last error in a maintenance queue, and the next run retries. Feed descriptions and CVE lists are bounded to the same limits as manual entry.

Partially available. Daily ingestion with the Microsoft Update Catalog parser is available; the subscription settings page (patch.source.configure) is not yet built.

Known-issue advisories

Vendors sometimes report that a patch itself causes problems. With patch_known_issues switched on, TENSOR checks your known-issue feed daily. The feed can use the documented JSON format or the Microsoft Windows release-health list. It is fetched through TENSOR's outbound request guard, so only https URLs to public hosts are accepted.

• An exact KB or CVE match marks a patch Known issue.
• A match on the product name alone marks it Caution.

The patch list shows how many patches are blocked, and the patch detail page shows the advisories under Known issues. The feed settings show Last checked, or Last check failed with the error.

Pending Changes that deploy an affected patch are handled automatically, and the change managers of those Changes are informed:

• 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.
• Every other pending Change shows the banner Known issue on a patch this change deploys.
• Optionally, Standard Changes are also sent back for a decision on a Caution match (Also send Standard changes back for a decision on "Caution").

Withdrawing an advisory clears the mark but re-approves nothing. Setup is in Set up the known-issue feed; the CAB side is in Decide on a Change flagged with a known issue.

Patch deployment as a Change

Patching is a change to production, so TENSOR routes it through the regular Change process. Deploy patch on a patch detail page creates a Change request that:

• links every CI where the patch is missing;
• carries a description from the patch metadata and a predefined rollback plan;
• is a Normal Change and goes through the regular approval process, so CAB approval, freeze windows and segregation of duties apply. The requester cannot approve their own Change.

An Emergency Change is only created when it is explicitly requested. Patch deployments are created as Normal Changes so that they are approved before the work starts.

The confirmation Deploy patch as a Change request? is followed by the message Change request created. with the Change number and the number of affected CIs. The patch status of each CI records the deploying Change. If no CI has the status Missing, TENSOR shows No missing CIs to deploy this patch to.

Per-CI deployment outcomes

On a Change created from a patch, the panel Patch deployment outcomes lets the implementer mark each CI as Installed, Failed (with a Failure reason) or Deferred. The result flows back into the patch status of each CI, and adoption figures change accordingly. Failed CIs keep the patch as Failed with the reason. Recording outcomes needs patch.deploy.

An installed patch is not proof that the weakness is gone. In the target design, findings close as verified only after a later covering scan no longer observes the weakness. Scan-verified closure is Planned — not yet available; today, recording Installed does not close any finding.

Remediation groups

Planned — not yet available. Remediation groups bundle findings that one action fixes — normally one patch or one Change — with an owner or team, a due date, a recommended patch and a linked Change. TENSOR will propose groups deterministically, first by the same recommended patch and then by the same source solution, with no automatic clustering and no automatic Change submission. Until groups are available, you deploy fixes per patch from the catalogue. The target behaviour is described on Availability.