Read a host

The page of a host tells you what the server runs, which TuxCare support covers it, and which vulnerabilities are open. KernelCare and the TuxCare Extended Lifecycle Support change what counts as open.

The Hosts page #

The Hosts page lists the servers of the workspace, one row each: the criticality of the server, the operating system and its release, the TuxCare support of the server, the kernel, the open vulnerabilities by severity, and the time of the last scan. The cards at the top count the hosts, the hosts under TuxCare support, the hosts past the end of the vendor's support, and the open and the known-exploited vulnerabilities. Type in the search field to find a host by name, or select a department. Select a host to open its page.

When TuxCare and the vendor publish no security advisories for the release of a host, the portal cannot check its packages. The row then shows Not evaluated and the release, for example centos-8 (no advisory data), and the Vulnerabilities card counts the host as not evaluated. Such a host is not clean, also with no open vulnerability, and it cannot get grade A. Its packages show not assessed, not covered. When advisories for the release arrive, the next check of the host evaluates it. If the mark stays on a release that TuxCare supports, contact TuxCare.

The agent can send tags for a server (tags). Each row shows the tags of its host. To show only some hosts, select a tag in the any tag list. Add more tags to keep the hosts that hold every tag. Select the of a tag to remove it from the filter. To show only the hosts of one criticality, select it in the any criticality list. The page address keeps the filters, so you can share a filtered list. Select the Criticality heading to sort the most critical hosts first. To group the hosts by operating system, select the OS heading: the hosts of one release come together. The page has no list of operating systems; the API keeps the hosts of one release with ?os=.

The facts of a host #

The top of the page shows the criticality of the host and the facts of the newest scan:

Criticality: How critical the server is, and where the value comes from (see Criticality). It shows also before the first scan is matched.
Operating system: The distribution, the release, and the platform, for example almalinux-9.2 on x86_64.
Support: The TuxCare support of the server: TuxCare ESU (Enterprise Support), TuxCare Essential Support, or TuxCare ELS (Extended Lifecycle Support). ESU and Essential Support servers have the same TuxCare release file, so the portal reads the packages too. On a release that ESU covers (AlmaLinux 9.2, 9.6, 9.8, or Rocky Linux 9.6), a server shows TuxCare ESU only when it runs at least one TuxCare build of a package (its release holds .tuxcare., for example expat-2.5.0-6.el9_8.7.tuxcare.els2); else it shows TuxCare Essential Support. A new ESU server therefore shows Essential Support until it installs its first ESU update, and ESU from the next scan after it. On each other release of AlmaLinux or Rocky Linux, a server that declares ESU shows Essential Support. A server with none, which has no TuxCare release file, shows Community and the end of the vendor's security support, also when that support has ended. A RHEL server with none shows no TuxCare licence: it can have a Red Hat subscription, and the portal cannot tell.
Kernel: The kernel that the server booted. With KernelCare, also the effective kernel: the kernel version that the live patches give. Without KernelCare, when a newer kernel that the server can boot is installed (a kernel image, not only its headers or modules), the Hosts list says reboot needed under the kernel and names the installed one.
Tags: The tags that the agent sent for the server, when it sent any.
IPv4, IPv6: The addresses of the network interfaces of the server, each once, when the agent sent them (send-addresses).
Sent from and agent: The address that the scan came from, and the version of the agent. Behind NAT or a proxy, this address is the address of the NAT or the proxy, not the address of the server. When the agent is older than the newest Radar release, the agent line says older than and names that release: update the agent.
Last scan: The time of the newest scan. The date turns amber after 14 days without a scan, and red after 30 days.

Criticality #

Each host has a criticality: Low, Normal, High, or Critical. Give your internet-facing database servers a high value, and your test machines a low one. The value comes from one of three places:

By hand. On the page of the host, select a value in Hand value, next to Criticality. You need the member role or the admin role on the host. A value set by hand wins over every tag rule. Select Not set: use the tag rules to remove it.
A tag rule. An admin adds the rules under Settings › Host criticality rules: a tag and a value, for example env=prod is High. Every host with the tag gets the value. When a host has the tags of two rules, the higher value applies. Select Change to change the tag or the value of a rule, and Remove to remove it. A workspace can have one rule for each tag, and at most 200 rules.
The default. A host with no hand value and no rule is Normal.

The page of a host names the source: Set by hand, the tag of the rule, or the default. The Hosts list shows By hand or Tag rule under the value; a host with the default shows the value alone.

The criticality orders the lists of Vulnerabilities, Remediation, and the Overview: of two findings with the same rating, the finding on the more critical host comes first. The criticality never lifts a finding above a worse rating or above a known-exploited finding of the same rating.

The rating comes first in each of these lists: critical, high, medium, low, then no rating. A known-exploited finding comes first inside its rating, but never above a worse rating: a known-exploited medium comes after every critical and high.

The vulnerabilities of a host #

The Vulnerabilities tab shows one row for each vulnerability. A row lists the source packages and kernel builds that it affects; a count opens the binary packages of each. One kernel CVE on seven kernel packages is one row. The severity buttons above the table count the open rows: a row that is fixed, that TuxCare will not fix, that is on a kernel that does not run, or that your team ignored in triage, is not open. The Fix column says what to do:

A version: install that version or a later one. The badge names the TuxCare line that ships the fix, when TuxCare ships it.
no fix yet: no build fixes the vulnerability yet.
TuxCare will not fix: TuxCare decided not to fix it on this release. The row quotes the reason. It is not open and sends no alert.
live-patched by KernelCare or live-patched by LibCare: see KernelCare.
fixed in the installed kernel or restart: the fix is installed, but the server does not run it yet. See Restart and reboot.

The table lists the worst rating first: critical, high, medium, low, then no rating. Inside one rating, the known-exploited rows come first, then the higher score, and a row with no score comes last. The rating is the rating for the release of the host, and the score is the CVSS score of the advisory, so a critical row can have a low score. To sort the table by another column, select its heading. The export always has its rows in this order, not in the order of the column that you selected.

To save the vulnerabilities of the host, use Export above the table. With no filter set, the file has every vulnerability of the host; with filters, it has the rows that the filters show, every row and not only the page. The file has more columns than the table: the score, the known-exploited sources, the fixed version of each package, the triage, the first sighting, and the other names of the advisory. XLSX has a filter on each column, and a second sheet, About, that names the host and its facts as the PDF cover does (its operating system, support, kernel, addresses, tags, agent, and the customer case or import of a host imported from a file), the scan, the filters, and the time of the export. CSV has the rows only. PDF opens the report as a page to print: a cover page with the host (its operating system, support, kernel, addresses, tags, and agent) and the counts of each severity, then the list of the open vulnerabilities. A vulnerability that is fixed, by a TuxCare build, by KernelCare, or by LibCare in every package it affects, that TuxCare will not fix, or that your team ignored in triage, is counted on the cover but not listed. When LibCare patched only some of its packages, the list shows the packages that are still vulnerable. Select Cover page only to print the cover alone. Select Print or save as PDF, then Save as PDF as the printer. At the top of the page, SBOM downloads the package list that the agent sent, as CycloneDX, and an admin selects Rename or Delete host, or Departments to set the departments of the host when the workspace has departments. Delete host asks first, then removes the host with all its scans, findings, and triage, and the tokens scoped to it. You cannot undo it. When the agent of the host sends a scan again with a workspace token, the host comes back as a new host with no history. An agent that used a token scoped to this host needs a new token. The API gives the same files.

Select a row to open the finding: the advisory, the severity, the packages, and the statements of TuxCare about the CVE. Triage a finding that does not apply to the server. To ignore a CVE on every host, an admin adds a suppression rule.

When the VEX of TuxCare lists the package as under investigation on the release of the host, the finding shows TuxCare is investigating. TuxCare has not decided yet whether the build is affected. The finding stays open until TuxCare publishes its decision: a TuxCare advisory that fixes the CVE in the installed build, or in an earlier build of the package, closes it.

Containers and local images #

The Containers tab of a host lists the containers on the server and the images that its container runtimes hold, as the agent saw them in the newest scan. The list needs an agent that sends it. A server with no list says so.

The running containers come first, then the stopped ones. Each row names the container, its state, its runtime, and its image.

The Scan column connects an image to a scan that the portal already has, from your CI or from the registry scan. The portal compares the digest of the image, not its tag, because a tag can move. When a scan of that digest exists in the workspace and you can see the image, the column links to the image at that scan and shows its open findings. Else the column says Not scanned. This does not mean that the image is safe: the portal has no data about it. A TuxCare Radar workspace holds hosts only, so each of its images says Not scanned.

A container uses the kernel of the host, so the kernel packages inside an image do not apply. The counts of this tab leave out a finding that reaches only such packages, and a line under the counts says how many it left out. The page of the image still lists them.

When the portal cannot read the list of a scan, the tab shows the reason. The packages of the scan are not affected.

KernelCare #

KernelCare patches the running kernel with no reboot. When KernelCare runs on the server, the agent sends its state: the effective kernel, and the CVEs that the loaded patches fix.

The portal judges the kernel packages at the effective kernel version, not at the booted version.
A kernel CVE that a loaded patch fixes shows live-patched by KernelCare. It is not open, sends no alert, and does not fail a gate.
The badge KernelCare on the host and on the Hosts page counts the CVEs that the patches fix.
When KernelCare has released a newer patch for the server's kernel to the server's patch source (its ePortal, or KernelCare's own server), the Kernel line says so: KernelCare level 43 is released for this kernel; this host runs level 42. Run kcarectl --update on the server; with an ePortal, sync the ePortal's feed first. A CVE that the newer patch fixes shows KernelCare level 43 live-patches it. A patch that is not released to the server's patch source is not shown. Radar 3.0.7 or later sends what this needs.
A package that is built from the kernel source but is not the running kernel, for example kernel-tools, is judged at its installed version.
The portal keeps one finding for each advisory and kernel build. The finding shows the state of the kernel image, and it lists the other packages of that build, such as kernel-modules.

LibCare patches shared libraries, for example openssl and glibc, in the running processes. A CVE that LibCare's patches fix, on a package built from a library that LibCare patches, shows live-patched by LibCare. It is not open, sends no alert, and does not fail a gate. When a CVE is on two libraries and LibCare patches one of them, for example openssl but not openssl11, the row stays open and names the patched library. The package on the disk still carries the CVE: update it when you can.

Update an OS package #

The page of a vulnerability on a host shows How to fix. When a fix exists for an OS package, the card gives the update command of the package manager of the server, with the binary packages of the finding:

sudo yum update nettle nettle-devel                                        # rpm, every Enterprise Linux release
sudo apt-get update && sudo apt-get install --only-upgrade libc6 libc-bin  # deb
sudo apk upgrade --update-cache musl                                       # apk

The deb and apk commands read the package index first. With an old index, the package manager can answer that the package is already the newest version and install nothing.

A fixed Debian or Ubuntu kernel is a new package with a new version in its name, so the update of the old name installs nothing. For a kernel, the card gives a command that updates the kernel meta package of the server, for example linux-image-amd64 or linux-image-generic:

sudo apt-get update && sudo apt-get install --only-upgrade 'linux-image-*'

A server that has no such meta package gets no new kernel from this command. Install the newer kernel package by its name.

Two lines can follow the command:

Install it from the TuxCare repository: the fix is a TuxCare build. See TuxCare ELS and ESU.
Reboot after the update: the package is a kernel, or a package of its modules. A package that is built from the kernel source but is not part of the kernel that runs, for example kernel-tools, needs no reboot. See Restart and reboot.

The card gives no command when the fix is already installed and only a reboot or a restart is left, and for an installed kernel that the server does not run. A package name with characters that are not safe in a command gets no command: the name comes from the scan, and you run the command with sudo.

Restart and reboot #

An update fixes the files on the disk. A program that started before the update still runs the old code until it restarts, and the old kernel runs until the server reboots. Until then the server can still be attacked through the vulnerability, so the row stays open: it counts in the totals and the grade, and it can fail a gate.

fixed in the installed kernel; a reboot closes it: the server runs an older kernel than the newest one installed, and the newest one fixes the vulnerability. On a server with KernelCare, the running kernel is newer than its live patches, so a later KernelCare patch can close it too, with no reboot.
restart followed by service names, for example restart sshd.service and crond.service: those services still use a library or a program that an update replaced. Restart them. Without a name, restart the programs that use the updated package, or reboot.

On a server without KernelCare, the facts of the host count the vulnerabilities that a reboot, and a restart of the services, would close, and name the installed versions that fix them. The line Restarting … would close N CVEs names only the services whose restart closes an open vulnerability: a service that runs an old copy of a package whose update fixed no open vulnerability is not named. The login sessions of a user (the unit user@<UID>.service) show as the login sessions of UID N (log out and in again), after the services: there is no service to restart, so the user logs out and logs in again. On a server with KernelCare, the Kernel line names the newest installed kernel when it is newer than the running one, and the rows say the rest. KernelCare applies kernel fixes to the running kernel, and LibCare applies glibc and OpenSSL fixes to running programs, with no reboot and no restart. A vulnerability that they patched shows live-patched. The portal never suggests a reboot into a kernel older than the one KernelCare runs, or a restart onto a library older than the one LibCare runs; when the live patches are ahead of the installed versions, the facts say that no reboot is needed.

The agent finds the services as root, before each scan, from the systemd service or the cron job. A run started by hand as another user sends what the last root step found.

TuxCare ELS and ESU #

A server under TuxCare Extended Lifecycle Support (ELS) or Enterprise Support (ESU) takes its security updates from TuxCare. For such a server the portal reads the advisories and the VEX statements of TuxCare first:

A CVE that TuxCare fixed shows the TuxCare build that fixes it. Install that build from the TuxCare repository.
A CVE that TuxCare says never affected the package of the release is not a finding.
A CVE that TuxCare still investigates is open with no fix yet.
The vendor's advisory answers only the CVEs that TuxCare did not publish. A vendor fix that shipped only for a later minor release is not shown as a fix for the server.
The severity is the word of TuxCare, for example High 7.5. A CVE with no word of TuxCare takes the severity of the vendor or of NVD.

A server with no TuxCare support is judged by the advisories of its vendor. When its release is past the end of the vendor's support, the Hosts page counts it under Past end of life: nothing patches it until it gets TuxCare support or a new release.

CIS compliance #

Each host checks itself against the CIS benchmark of its system. The agent runs OpenSCAP (oscap) on the host with the CIS Level 1 or Level 2 Server profile of ComplianceAsCode, and sends the result of each rule with each scan. OpenSCAP decides whether each rule passes; the portal stores and shows the results. The checks cover AlmaLinux 8, 9, and 10, Red Hat Enterprise Linux 8, 9, and 10, Oracle Linux 9, CentOS 7 ELS and CentOS 8 ELS, Amazon Linux 2 ELS, Debian 11, 12, and 13, and Ubuntu 20.04, 22.04, and 24.04. Ubuntu 20.04 checks with the last ComplianceAsCode rules of Ubuntu 20.04, which follow the CIS Ubuntu Linux 20.04 LTS Benchmark 1.0.0: CIS publishes version 3.0.0, and the result names 1.0.0. ComplianceAsCode has no CIS profile of Debian 11, so Debian 11 checks with the rules of Debian 12, and its result names the CIS Debian Linux 12 Benchmark. The checks of Debian 11 and Ubuntu 20.04 need tuxcare-radar3 3.0.10-3 or later. CentOS 7 ELS checks the CIS Red Hat Enterprise Linux 7 Benchmark 4.0.0 with the last ComplianceAsCode rules of Red Hat Enterprise Linux 7. ComplianceAsCode has no rules of Amazon Linux 2, so Amazon Linux 2 ELS checks the CIS Amazon Linux 2023 Benchmark 1.0.0, and its result names that benchmark: a recommendation that only the CIS Amazon Linux 2 Benchmark has is not checked.

The checks are off by default. To turn them on:
1. Set cis: true and cis-root: true in /etc/tuxcare-radar3/radar.conf. Optionally set cis-level: 1 to check Level 1 only; the default, 2, checks Level 2, which holds the Level 1 rules.
2. Run /usr/share/tuxcare-radar3/cis-setup as root. It installs oscap for you (tuxcare-radar3 3.0.10-5 or later; on Debian 11 and Ubuntu 20.04, 3.0.10-6 or later):
  - AlmaLinux, Red Hat Enterprise Linux, Oracle Linux, and CentOS 8 ELS: the package openscap-scanner of the vendor, with dnf.
  - Debian 11, 12, and 13, and Ubuntu 20.04, 22.04, and 24.04: the TuxCare package tuxcare-openscap-scanner, with apt-get. CentOS 7 ELS and Amazon Linux 2 ELS: the same package, with yum. It is the TuxCare build of OpenSCAP 1.4.6, at /opt/tuxcare/openscap/bin/oscap, next to the package of the system. It comes from the package repository of tuxcare-radar3, so a Debian or Ubuntu host needs the apt source of that repository.
The package of tuxcare-radar3 runs cis-setup after each install and upgrade. The unit tuxcare-radar3-cis-install.service then installs oscap before the next run, and checks it before each run. The agent runs the TuxCare oscap when it is there, else the oscap of the system. Until TuxCare publishes the package tuxcare-openscap-scanner in the package repository of tuxcare-radar3, its install fails, and the agent runs the oscap of the system, if the host has one: install openscap-scanner (yum install openscap-scanner, or apt install openscap-scanner), or libopenscap8 on Ubuntu 20.04 and 22.04, before you run cis-setup. Debian 11 has no package of oscap. When the install fails, or the oscap of the host is older than the oldest version of its system, the host's page gives the reason, and the agent tries the install again before the next run. For a host whose packages you manage, set cis-oscap-install: false in radar.conf, run cis-setup again, and install oscap yourself: dnf install openscap-scanner, yum install tuxcare-openscap-scanner, or apt-get install tuxcare-openscap-scanner. The OpenSCAP unit runs as root with one capability: it reads the files that only root reads, and it has no network. Only the result of each rule leaves the host, never a value that OpenSCAP reads.
CIS compliance in the top bar shows each host with its compliance, the lowest first, and the rules that fail on the most hosts. Choose Level 1 or Level 2.
CIS compliance on a host's page shows the host's rules: the compliance and the counts, the trend over the runs, and each rule with its CIS ids, its status, and the reason. Details shows why the rule matters and how to fix it.
A rule is Pass, Fail, or Manual: OpenSCAP did not pass or fail it. A manual rule shows the result of OpenSCAP: Not applicable (the rule does not apply to the host, for example a rule of a machine on a container), Not checked (the rule has no automated check), Error, Unknown, or Informational. A person checks a manual rule. The compliance is the passed rules of the passed and failed rules: a manual rule is not a failure.
A rule can show Known false result with a note: OpenSCAP gives a result that is known to be wrong for a reason that is not a fault of the host. The rule keeps the result that OpenSCAP decided, and counts with it. On CentOS 7 with SELinux in enforcing mode, selinux_confinement_of_daemons always fails: the OpenSCAP unit of the agent runs in the SELinux domain that the rule looks for. Check the other daemons with ps -eZ | grep unconfined_service_t. The oscap packages of Debian 12, Debian 13, Ubuntu 22.04, and Ubuntu 24.04 give some wrong results: a pass of package_telnet_removed on a host with inetutils-telnet, and an error of the rules with a script check, for example no_files_unowned_by_user, when /tmp is mounted noexec. With the TuxCare oscap (1.3.13 and later), package_rsh_removed fails on Ubuntu 20.04, Ubuntu 22.04, and Debian 11 when rsh-client is not installed: the package openssh-client of these systems provides rsh-client. Check the host with dpkg-query -s rsh-client. On Debian 11, package_pam_modules_installed and package_pam_runtime_installed always fail: the agent checks Debian 11 with the data stream of Debian 12, and these rules ask for a version of the package that only Debian 12 has. On Amazon Linux 2, five rules always give a wrong result, for example configure_crypto_policy fails because Amazon Linux 2 has no system crypto policy. The results of the faillock, pwhistory, and sshd rules can be wrong when a setting is in a file that Amazon Linux 2 does not read, for example /etc/ssh/sshd_config.d. The note of each rule says how to check the host.
A host can show Old OpenSCAP or Old content: its CIS check tools are out of date, and a result can be wrong or old. The CIS page of the host, the PDF report, and the list of CIS compliance show the flag with the reason and the fix; on the list, select Only the hosts with out-of-date check tools to see only these hosts.
- Old OpenSCAP: the oscap of the host is older than the minimum of its system. On Debian, Ubuntu, CentOS 7 ELS, and Amazon Linux 2 ELS the minimum is OpenSCAP 1.4.6, the TuxCare package tuxcare-openscap-scanner: the packages of these systems are old and give some wrong results. cis-setup installs the TuxCare package when cis-oscap-install is on. On AlmaLinux, Red Hat Enterprise Linux, Oracle Linux, and CentOS 8 ELS the minimum is the openscap-scanner package of the current minor release of the system (1.3.14 on version 8 and 9, 1.4.4 on version 10): run dnf update openscap-scanner.
- Old content: the host checked with a content of ComplianceAsCode that is not the current release of the portal, and that release has been current for more than 3 days. The agent gets the content from the portal at each scan, so a host that stays behind has a fault: an agent that does not get the content (update tuxcare-radar3), no connection to the portal, or a content that the OpenSCAP unit refused (its signature does not verify: see the log of tuxcare-radar3-cis-oscap.service).
The agent gets the CIS content from the portal before each scan, and checks its signature. When it cannot get or verify the newest content (no connection to the portal, or a content that the agent refused), the scan uses the last good content of the host, and the CIS page of the host, the details of each rule, and the PDF report say The scan used the last good content with the reason. The results are of that content, and the page names its content release.
When a rule that passed in the previous run of a host fails in the new run, the workspace gets a CIS drift alert: one message for the run, with each such rule, why it matters, how to fix it, and a link to the CIS page of the host. The alert compares only runs with the same content, level, and scanner version: the first run of a host, the first run after a new content, level, or scanner version, and a rule that was manual before send no alert. The CIS page and the PDF report of the host then say what changed and how many rules changed their result. The next run with the same content alerts as before. An admin turns the alert off under Notifications.
PDF report on either CIS page opens a report to print or to save as a PDF: in the print dialog of the browser, select Save as PDF as the printer. The report of a host has a cover with the host, its system, the benchmark and the level, the time of the run, the compliance, and the pass, fail, and manual counts; then each rule, failed rules first, with its result, why it matters (the rationale), and how to fix it. Select Passed rules with no text for a shorter report. The report of the hosts has the totals of the level, the compliance of each host, and the rules that fail on the most hosts with their rationale and fix. The report takes the level that you chose on the page. Cover page only prints the first page only.
When the host sent no OpenSCAP result (for example, oscap is not installed), or the portal cannot read it (for example, the agent is newer than the portal), the host's page says why and shows the results of the last run that had them. The scan of the packages is not affected.

OpenSCAP and the rules of ComplianceAsCode (BSD-3-Clause) judge the checks, and the text of each rule comes from ComplianceAsCode. The portal does not show the text of the CIS benchmark itself. The content of Debian 13 names no CIS id, so its rules show no CIS id.

Export and import scans #

A host's scan can move to another portal: to a colleague's test portal, or to TuxCare support. What moves is the document the agent sent. The other portal matches it again against its own data, so its rows can differ where its data differs. Triage, notes and history stay behind.

Export scan on a host's page exports its newest scan. Export scans on the Hosts page exports the newest scan of every host of the list: narrow the list with the search, the tags or the department first.
An export is always encrypted with a passphrase. The dialog makes one, for example 7fqk-2m9x-c4hd-r8wz-k1tb-6pne; you can type your own of 20 to 128 letters, digits and punctuation, with no space. Send the passphrase by another channel than the file: a chat message or a call, not the same email. The portal does not keep it.
The file opens with gpg -d scans-2026-11-01.zip.gpg > scans.zip, and another portal imports it as it is.
Import scans on the Hosts page takes an export with its passphrase, a file of tuxcare-radar3 run --dry-run --encrypt with its passphrase, a host's document written by tuxcare-radar3 run --dry-run > host.cdx.json, or a file that gpg -c encrypted. The dialog names the largest file this portal takes; a bigger file is refused before the upload, and the server answers the same message. A member or an admin imports. An imported host shows Imported; an imported scan sends no alert. No agent token sent an imported scan, so the line under the host name names no sender. When an agent of this portal later sends the same scan, the line adds last run with that agent's token and CLI version.

A customer whose host is not on a portal (it cannot open outbound HTTPS, or it is air-gapped) sends us its scan this way:

On the host, the customer runs sudo tuxcare-radar3 run --dry-run --encrypt (tuxcare-radar3 run --help lists --encrypt in the Radar releases after 3.0.7-2). Radar reads the packages, sends nothing, and writes the encrypted file tuxcare-radar-<host>-<date>.zip.gpg in the current directory. It prints the file name, the size and a generated passphrase.
The customer sends the file and the passphrase by different routes: the file by email or the ticket, the passphrase by phone or chat.
You import the file with its passphrase into a customer case (below). The file is the same encrypted zip as an export, so gpg -d opens it too.

Do not ask for the plain --dry-run output by email: it is plain text with the host's packages, kernel, addresses and tags.

Customer cases #

To look at a customer's problem, import the customer's scan into a customer case, not among your own hosts. The case's label names the customer's company and the ticket, for example Example Ltd / TKT-1234; do not put a person's name in it.

A case's hosts carry the badge Customer: Example Ltd / TKT-1234 and a banner on their page, with who made the case, when, and its purge date. The line under the host name gives who imported the scan shown, when, and from which file, in place of the agent's token. The Hosts page lists them under customer cases only.
They are left out of the dashboards and the other views of the workspace, they send no alerts, and a viewer does not see them.
A case is purged 30 days after it was made: every host, scan, finding and triage row of it is deleted. Settings › Customer cases lists the cases with their purge dates, keeps a case 30 more days, or purges it now. The audit log records the purge by the case's number, without the label or the hosts.
The portal cannot purge a copy outside it: delete the file once it is imported, and the ticket's attachment when the ticket closes. A database backup keeps a purged case until the backup is rotated out.

When you report wrong advisory data to TuxCare, TuxCare support may ask for the host's scan: export it as above.

Next: Troubleshooting