CT-Ops
Host Inventory
How to use installed package inventory and vulnerability findings for a CT-Ops host.
The Inventory area answers what software is installed on the host and what risk that software carries. Use it for vulnerability triage, package drift reviews, patch verification, and evidence gathering during maintenance.
The host detail Inventory parent tab contains two child tabs:
| Tab | Use it for |
|---|---|
| Packages | Current and removed package inventory, scan status, manual rescans, CSV export, and package comparison. |
| Vulnerabilities | Open package or container-image findings for the host, severity breakdowns, filters, sorting, pagination, and finding detail. |
The Compare control opens a separate package-comparison page for the same host. It is part of the inventory workflow even though it is not a child tab.
Packages tab
The Packages tab shows software inventory collected from the host. It reports the last scan time, package count, package source, added package count, and removed package count when that data is available. Use it when you need to confirm exactly what is installed before a change, after a patch, or during an incident investigation.
The header row shows:
| Field or control | What it does |
|---|---|
| Last scan | Completion time of the latest successful inventory scan. |
| Package count | Number of packages recorded by the latest scan. |
| Source badge | Package source for the scan, such as dpkg, rpm, pacman, apk, winreg, macapps, or other. |
| Added count | Number of package rows newly observed in the latest scan. It appears as a green +N value only when the count is greater than zero. |
| Removed count | Number of package rows that disappeared in the latest scan. It appears as a red -N value only when the count is greater than zero. |
| Rescan now | Queues a fresh software_inventory task for this host. The button is disabled while the request is being submitted. |
| Export CSV | Opens /api/reports/software/export?format=csv&hostId=<host id> in a new browser tab for this host’s software inventory. |
| Compare | Opens /hosts/<host id>/compare, where the operator can compare this host with another host. |
Package sources can include package managers and platform-specific sources such as:
| Source | Meaning |
|---|---|
dpkg | Debian or Ubuntu packages collected with dpkg-query. |
rpm | RPM packages collected with rpm -qa, including epoch and release where available. |
pacman | Arch-style packages collected with pacman -Q. |
apk | Alpine packages collected with apk info -v. |
winreg | Windows applications collected from 32-bit and 64-bit uninstall registry hives. |
macapps | macOS applications from system_profiler, with Homebrew packages included when brew is available. |
snap or flatpak | Optional Linux application sources when inventory settings and agent support collect them. |
homebrew | Homebrew package source when reported independently by the collector. |
other | Unsupported or fallback source. Treat this as a signal to check the agent and platform support. |
If there is no completed scan yet, the header shows No scan data yet. If software inventory is disabled and the host has no scan history, the tab shows a disabled state with a link to Administration -> Agents -> Software inventory. See Software Inventory Settings for the global controls that affect this state.
Searching packages
Use the package search field to filter by package name, version, or publisher. This filtering happens in the browser against the packages already loaded for the host. It is useful when checking whether a specific dependency is present, whether a vendor package is installed, or whether the host is running a version that differs from the expected baseline.
Use Show removed when you need to see packages that were present before but are no longer reported. This helps during change review and post-patch verification. The button changes to Hide removed while removed rows are visible.
The package count beneath the filters shows how many rows are visible. When a search is active, it also repeats the search text so operators can capture the filtered state in screenshots or tickets.
The package table contains:
| Column | Meaning |
|---|---|
| Name | Package name reported by the collector. Names are shown in monospace to make exact package matching easier. |
| Version | Installed version reported by the package source. RPM versions include release and epoch where available. |
| Architecture | Package architecture when reported, such as amd64, x86_64, or noarch; otherwise -. |
| Publisher | Package maintainer, vendor, or Windows publisher when available; otherwise -. Long values are truncated in the table. |
| Source | Source badge for the collector that reported the package. |
| First seen | First time CT-Ops observed this exact host, name, version, and architecture combination. |
| Last seen | Most recent scan time that reported this package row. |
| Removed | Shown only when Show removed is enabled; indicates when the package disappeared from later scans, or - if it is still present. |
Removed packages appear faded and struck through so they remain available for change review without looking like current inventory.
CT-Ops stores one row per instance, host, package name, version, and architecture. A later scan updates the row when the same package is still present. Rows that are not reported by a later successful scan are stamped with Removed instead of being deleted, which preserves evidence for drift and change review.
If the table is empty, CT-Ops shows either No packages found or No packages match your filter.
Rescan and scan state
Use Rescan now to queue a fresh software scan. CT-Ops shows whether a scan is pending, running, completed, stale, or failed.
Manual rescans are operator actions with backend controls:
| Behavior | Detail |
|---|---|
| Permission | The server action requires instance administrator access. Read-only users can view inventory but cannot trigger a scan. |
| Rate limit | Manual scan requests are limited to 5 per minute per instance. If the limit is hit, CT-Ops asks the operator to wait before triggering another scan. |
| Task created | CT-Ops creates a software_inventory task run for the host with maxParallel set to 1. |
| Agent work | The agent collects packages and streams them to ingest in chunks of 500 packages. |
| Failure safety | If package collection fails, the agent fails the task instead of submitting an empty inventory. This prevents a failed scan from marking every existing package as removed. |
When a scan is queued, CT-Ops shows Scan queued - waiting for the agent to pick it up and polls every 5 seconds. When the scan is running, it shows Scan in progress - collecting packages. After completion, the header and table refresh.
A stale scan warning means the host has not been scanned within the expected window. Common causes include an offline host, disabled scanning, or an outdated agent. A failed scan includes failure output when available so operators can investigate the host-side cause.
The stale warning appears when the last completed scan is older than twice the configured software-inventory interval. The default interval is 24 hours when no custom setting exists. The software-inventory settings form accepts an integer interval from 1 to 720 hours and can enable or disable collection for the instance. See Software Inventory Settings for the full settings reference.
Use a manual rescan when:
- a patch or uninstall has just completed and you need fresh evidence;
- a vulnerability finding depends on inventory that may be stale;
- a host has come back online after missing scheduled scans;
- a package-drift investigation needs the latest package state.
Export and compare
Use Export CSV when you need package evidence outside CT-Ops, such as for a change ticket, audit pack, or offline review. The export is host-scoped by the current host id and opens in a new tab, so it does not disturb the current investigation.
Use Compare to compare package inventory for the host. This is useful for
drift checks when similar hosts should have the same software set or when a
change has affected only part of a group. The comparison route is
/hosts/<host id>/compare; when a comparison target is supplied it uses
/hosts/<host id>/compare?with=<other host id>.
The comparison page contains:
| Section or control | What it does |
|---|---|
| Back | Returns to the source host detail page. |
| Package comparison | Page heading for the comparison result. |
| Different versions | Lists packages present on both hosts where the version strings differ. Columns are Package, Host A, and Host B. |
| Only in host A | Lists current packages present only on the source host. Columns are Package and Version. |
| Only in host B | Lists current packages present only on the comparison host. Columns are Package and Version. |
| Identical package message | Shows These hosts have identical package sets when there are no differences. |
The comparison uses current package rows only; removed package rows are not part of the compare result. It compares by package name first, then reports different versions when the same name appears on both hosts with a different version.
Vulnerabilities tab
The Vulnerabilities tab shows vulnerability findings associated with the host’s installed packages. Use it to move from “this host has risk” to the exact package and vulnerability records that require action.
Use this tab to review package, installed version, CVE or advisory identifier, severity, finding source, available remediation details, and other affected hosts. The Overview vulnerability card links here so operators can move from summary risk to package-level evidence without leaving the host context.
This tab is most useful after opening a host from a vulnerability report, investigating a risk card on the Overview page, or checking the blast radius of a known CVE.
Vulnerability summary cards
The top cards summarize the currently selected finding source and filters:
| Card | Meaning |
|---|---|
| Unique CVEs | Distinct open CVE identifiers on this host. Multiple affected packages with the same CVE are counted once. |
| Critical | Number of distinct open CVEs with critical severity. |
| High | Number of distinct open CVEs with high severity. |
| Known Exploited | Number of distinct open CVEs marked as known exploited. |
| Last Scan | Last successful software inventory scan for host package findings, or last successful or partial Docker image scan for container image findings. If no scan exists, it shows No scan recorded. |
For host package findings, the tab shows open confirmed findings only. For container image findings, it shows open Docker image vulnerability findings.
Severity breakdown chart
The Severity Breakdown chart is a donut chart of the current summary. It groups distinct open CVEs by severity: Critical, High, Medium, Low, None, and Unknown. The legend uses the same color categories as the severity badges, and the tooltip shows the count plus the percentage of the current chart total.
If there are no findings for the current view, the chart area shows No severity data for the current view.
Vulnerability filters and controls
The vulnerabilities card contains the table controls:
| Control | What it does |
|---|---|
| Host packages | Shows open confirmed package findings from installed software inventory. This is the default source. |
| Container images | Shows open Docker image findings from local image scans for the host. |
| Search CVE, package, version or source | Searches the server-side result set. For host packages it searches CVE id, package name, installed version, fixed version, and source. For container images it also searches image and image id. Input is trimmed and capped at 120 characters. The UI waits about 400 ms after typing before applying the search and resets to page 1 when the search changes. |
| Severity | Filters to All severities, Critical, High, Medium, Low, None, or Unknown. Changing the filter resets to page 1. |
| Known exploited | Toggles findings whose CVE is marked known exploited. The button appears active while enabled. |
| Fix available | Toggles findings with a recorded fixed version. The button appears active while enabled. |
| Ellipsis menu | Opens two default-off switches: Ignore vulnerabilities with no fix and Ignore vulnerabilities that require Ubuntu Pro. When enabled, matching CVEs are removed from the summary cards, severity chart, pagination, and findings table. |
| Clear | Resets search, severity, known-exploited, fix-available, remediation-scope, source, and page state. It is disabled when no filters are active or while data is fetching. |
The API accepts pages from 1 to 10,000 and page sizes from 5 to 100. The host detail UI uses 10 findings per page.
Vulnerability table
The table lists the selected source’s open findings. Each row is clickable and also opens with Enter or Space when focused.
| Column | Meaning |
|---|---|
| CVE | CVE or vulnerability identifier. A bug icon marks normal findings; a lightning icon marks known-exploited findings. |
| Package | Affected package name. The smaller line below it shows the finding source. For container findings this source comes from the image scanner result. |
| Severity | Severity badge: Critical, High, Medium, Low, None, or Unknown. |
| Installed | Installed package version or image package version associated with the finding. |
| Fixed | Fixed version when CT-Ops has one; otherwise -. |
| AI | Ask AI opens a remediation-assistance side panel for that finding when at least one global AI model is enabled. |
Each column heading is a sort button. Clicking a heading sorts by that field; clicking the active heading again toggles ascending and descending order. The default sort is severity ascending, which puts the highest severities first, then known-exploited findings, then most recently seen findings.
Ask AI remediation help
Use Ask AI from an individual vulnerability row when an operator wants draft remediation steps for that exact host and finding. The side panel opens with the globally configured default AI model selected. Operators can choose another enabled model before selecting Send request.
CT-Ops builds the request on the server from trusted inventory data. The prompt includes the host display name, hostname, operating system and version, CVE or vulnerability identifier, severity, CVSS score, known-exploited flag, description, package name, installed version, fixed version when known, finding source, distribution or image context, and match reason.
The AI response is shown in a scrollable side panel so operators can keep a host terminal open while reviewing the remediation guidance. The whole answer can be copied, and if the response includes fenced code blocks, CT-Ops also shows each block separately with its own copy button for command-by-command use.
The side panel also includes Troubleshooting chat. Use it when an operator tries a generated command or step and it does not work. The follow-up request is sent with the original trusted CVE context, the current solution, and the visible back-and-forth chat so the AI can correct the next step without losing the host and finding details.
After the AI answers a follow-up, CT-Ops shows Update Solution. Selecting it opens a confirmation dialog explaining that the existing solution and all existing AI chat history will be deleted and replaced. Confirming asks the AI to produce one clean working solution from the original context and troubleshooting exchange, stores that replacement against the CVE cache, clears the chat history, and shows the updated solution in the panel.
Where supported by the selected provider, CT-Ops marks the stable system and CVE-context prompt segments for provider prompt caching. The changing operator feedback stays outside those cacheable segments so each follow-up reflects the latest troubleshooting details. Operators should still review AI-generated instructions before applying them to production systems.
Pagination controls appear below the table:
| Control | What it does |
|---|---|
| Page N of M | Current page and total pages for the active filters. |
| Previous | Moves back one page; disabled on the first page or while fetching. |
| Numbered pages | Jumps to visible page numbers. The list includes the first page, last page, current page, neighbors, and ellipses for gaps. |
| Next | Moves forward one page; disabled on the last page or while fetching. |
If no findings match, the tab shows one of three empty states:
| Empty state | When it appears |
|---|---|
| No vulnerabilities match the current filters. | Filters or search are active and produce no rows. |
| No open Linux package CVE findings for this host. | Host package source is selected and no unfiltered package findings exist. |
| No open Docker image vulnerability findings for this host. | Container image source is selected and no unfiltered image findings exist. |
AI remediation cache
The AI column contains Ask AI for each vulnerability row. CT-Ops sends the selected host and finding context to the configured AI model and stores the remediation answer against the CVE for the current CT-Ops instance. A confirmed Update Solution from the troubleshooting chat overwrites this same cached answer with the revised working solution.
When another row with the same CVE is opened later, on the same host or a different host, the side panel checks the CVE cache first. If cached remediation is available, CT-Ops loads it into the panel automatically and labels it as cached so the operator does not need to ask the model again. The operator can still choose Regenerate to replace the cached answer with a fresh model response.
Cached remediation stays available while the CVE is still present on any host package finding or Docker image finding. CT-Ops runs a daily cleanup rule. If a CVE no longer appears on any host, the cache entry starts a 30-day expiry window. If the CVE reappears during that window, CT-Ops clears the expiry and keeps the cached answer. If it does not reappear, CT-Ops deletes the cached answer after the 30-day window.
Vulnerability detail dialog
Opening a row shows the finding detail dialog. It includes:
| Field or area | Meaning |
|---|---|
| Title | CVE or vulnerability identifier. |
| Description line | Affected package name and host display name or hostname. |
| Severity badge | Severity classification for the selected finding. |
| Known Exploited badge | Appears when the finding is marked known exploited. |
| CVSS badge | Appears when a CVSS score is available. |
| Description | CVE description when available; otherwise CT-Ops states that no description is available. |
| Installed version | Version found on the host or in the image scan. |
| Fixed version | Fixed version when known; otherwise No fix recorded. |
| Source | Finding source, such as package advisory source or image scanner source. |
| Confidence | Confidence classification. Host package findings shown in this tab are confirmed; container image findings are displayed as confirmed. |
| CVE published | Published date when available; otherwise Not recorded. |
| First seen | First time CT-Ops saw this finding for the host. |
| Last seen | Most recent time CT-Ops saw this finding for the host. |
| Match reason | Optional explanation of why the package or image matched the finding. Container findings state they were found by a local Grype image scan. |
The Other affected hosts section loads up to 50 other hosts with an open confirmed finding for the same CVE, excluding the current host. It is designed for blast-radius checks before patching or containment.
| Column | Meaning |
|---|---|
| Host | Link to the affected host. The first line uses the display name when available; the smaller line shows the hostname. |
| OS | Operating system and version, or Unknown. |
| Packages | Number of distinct affected package names for the CVE on that host. |
| Fix | Available when any affected package has a recorded fixed version; otherwise Not recorded. |
| Last seen | Most recent time the CVE was seen on that host. |
If no other hosts are affected, the dialog shows No other hosts currently have an open confirmed finding for this CVE.
How inventory helps infrastructure management
Package inventory gives operators a factual software baseline for each host. That baseline supports patch planning, vulnerability prioritisation, drift detection, incident scoping, and audit evidence.
When combined with host groups and networks, package inventory helps answer “which machines have this package?” and “which part of the estate is exposed?” without manually logging into every server.