Tanium Linux Patching: Repository Scan vs TSL

Tanium Linux Patching – This guide explains how to manage Linux patching with Tanium Patch. It compares Repository Scan and Tanium Scan for Linux (TSL), explains when to use repository snapshots, and shows how to organize Linux patch deployments with rings for pilot, pre-production, and production systems.

Useful external reference: Tanium documentation.

Specifics of Linux vs Windows Patching

Key differences

  • Patch sources
    Windows: a single logical source → Microsoft (WSUS / Windows Update / catalog).
    Linux: multiple distributions (Red Hat, Ubuntu, Debian, SUSE, Rocky, Alma, etc.), each with its own repositories and URLs.
  • Package managers
    RPM: yum / dnf (Red Hat, CentOS, Rocky, Alma, Oracle Linux), zypper (SLES/OpenSUSE).
    DEB: apt (Debian, Ubuntu).
    .rpm and .deb packages are not interchangeable; there is no generic exe concept.
  • Versioning & URLs
    Each version has its own repository path.
    Ubuntu example: bionic (18.04), focal (20.04), jammy (22.04), etc.
    To patch jammy (22.04), you must point to the jammy repositories, not to bionic or focal (otherwise you mix metadata and create inconsistencies).
    Same logic for RHEL 7/8/9, Debian 10/11/12, SLES 12/15, etc.
  • Release cadence
    Windows: monthly Patch Tuesday (plus out-of-band updates).
    Linux: no single patch day; updates are released when each distribution publishes them.
  • Recommended strategies
    Windows: patch lists to control exactly which KBs and classifications are installed.
    Linux: repository snapshots to freeze a consistent state (metadata + dependencies) at a given date.

Practical advice

  • Do not copy your Patch Tuesday logic 1:1 to Linux: build a strategy per distribution and per repository.
  • Document clearly:
    • which OS versions are associated with which repositories;
    • which branches (prod / pre-prod / test) consume which snapshots.

Choosing the Linux scan method

Tanium Linux Patching – Tanium Patch provides two scan methods for Linux:

Useful external reference: Tanium documentation.

  • Repository Scan
  • Tanium Scan for Linux (TSL)

Tanium Linux Patching – We do not create new repositories here; we only explain how to use repositories that already exist (on the OS or already configured in Tanium).

Useful external reference: Tanium documentation.

Tanium Scan for Linux (TSL) – Default mode

Tanium Scan for Linux (TSL) is the recommended mode and it is the default mode in most environments.

  • The Tanium Servers connect to the external repositories, for example cdn.redhat.com, Ubuntu repositories, Debian repositories, or other vendor repositories.
  • The Tanium infrastructure downloads repository metadata and required package content.
  • Packages are then distributed to Linux endpoints through the Tanium linear chain with Client API Downloads.
  • The Linux endpoints do not need direct Internet access for scan or patch deployment when TSL is used.

Important: endpoint logs can sometimes show repository URLs such as cdn.redhat.com. This can be confusing. In TSL mode, these URLs are related to the repository metadata and package source, but the real external network request is done by the Tanium Server, not by the endpoint itself.

Key idea: with TSL, Linux endpoints can stay isolated from the Internet. Repository access is centralized on the Tanium infrastructure, and package distribution is done by Tanium.

Repository Scan – Alternative mode

Repository Scan is different. In this mode, the Linux endpoint uses its own repository configuration and communicates directly with the configured repositories.

  • The endpoint talks directly to repositories configured on the OS, for example /etc/yum.repos.d, /etc/apt/sources.list, or repositories pushed by Tanium.
  • The endpoint needs network access to these repositories. This can be Internet access or access to an internal repository mirror.
  • Package metadata and packages are downloaded directly by the endpoint from the configured repository.
  • Tanium orchestrates the scan and the deployment, but the package manager still needs to reach the repository from the endpoint.

Key idea: Repository Scan = the Linux server uses its normal repository access. Tanium starts and controls the operation, but repository network access is required from the endpoint.

On-prem conclusion

  • With Tanium Scan for Linux, Linux endpoints do not need Internet access. Tanium Servers download the content, then Tanium distributes it through the linear chain.
  • With Repository Scan, Linux endpoints need access to the configured repositories, either on the Internet or on an internal mirror.
  • Most on-prem customers use Tanium Scan for Linux by default, because all patch content goes through the Tanium infrastructure.

Simple rule of thumb

  • Single or few servers directly on the Internet / in the cloud
    → Repository Scan, simple and close to the repos.
  • On-prem environment with many servers, rings, strong consistency requirements
    → Tanium Scan for Linux + snapshots.

Scenario 1 – Single Linux server directly on the Internet

Tanium Linux Patching – Goal: patch a single Linux server (Ubuntu, RHEL, etc.) that already has repositories configured and direct Internet access.

Useful external reference: Tanium documentation.

Prerequisites

Tanium Linux Patching – On the server:

Useful external reference: Tanium documentation.

  • apt update / yum repolist / dnf check-update run without error.
  • Repositories are already configured by the OS team.

Tanium Linux Patching – In Tanium:

Useful external reference: Tanium documentation.

  • The server shows up correctly in the console.
  • Patch module is enabled.
  • Non-Windows Patch process is running:
    • Question: Patch - Is Process Running [Non-Windows] = Yes.
    • If not, run the action Patch - Start Patch Process [Non-Windows] on this server.

Configure the scan (Repository Scan + OS repos)

  1. Go to Modules → Patch → Scan Management → Scan Configurations.
  2. Click New Scan Configuration.
  3. Settings:
    • Name: Linux RepoScan – <ServerName>.
    • Operating System: Linux.
    • Scan Method: Repository Scan.
    • Use repositories configured on endpoint: checked.
  4. Target:
    • Only this server (dedicated Computer Group or filter by computer name).
  5. Schedule:
    • Initial scan.
    • Then once per day or per week depending on requirements.

Deploy patches on this server

Option A – Deploy all missing patches

  1. Go to Modules → Patch → Deployments → New Deployment.
  2. OS = Linux.
  3. Select the option to deploy all missing patches (label depends on your Patch version).
  4. Target = this server.
  5. Schedule: immediate or within a defined window, with or without automatic reboot.

Option B – Targeted deployment via Patch List

  1. In the Linux Patch view, filter on this server and severity (High/Critical) or specific CVEs.
  2. Add these patches to a Patch List (for example Linux – Critical – SoloServer).
  3. Create a new Deployment based on this Patch List:
    • OS = Linux.
    • Patch List = Linux – Critical – SoloServer.
    • Target = this server.
    • Schedule + reboot according to your policy.

Scenario 2 – Linux fleet with rings and snapshots (on-prem)

Tanium Linux Patching – Goal: patch an on-prem Linux fleet with multiple servers using rings (pilot → pre-prod → prod) and snapshots to guarantee consistency.

Useful external reference: Tanium documentation.

Tanium Linux Patching – Assumptions:

Useful external reference: Tanium documentation.

  • Linux repositories are already configured and working in Tanium.
  • You can use Tanium Scan for Linux (TSL).

Define rings and Computer Groups

Tanium Linux Patching – Example:

Useful external reference: Tanium documentation.

  • Ring 0 – Pilot
    A few non-critical servers per distribution/version.
    Computer Group: Linux-Ring0-Pilot.
  • Ring 1 – Pre-prod
    Pre-production / UAT servers.
    Computer Group: Linux-Ring1-Preprod.
  • Ring 2 – Prod
    Production fleet.
    Computer Group: Linux-Ring2-Prod.

Configure a single TSL scan for Linux

  1. Ensure Enhanced Linux Support is enabled in Patch.
  2. Go to Scan Configurations → New Scan Configuration.
  3. Settings:
    • Name: Linux – TSL – Global.
    • Operating System: Linux.
    • Scan Method: Tanium Scan (Tanium Scan for Linux).
  4. Repositories:
    • Select only the existing Linux repositories (RHEL, Ubuntu, Debian, etc.).
  5. Target:
    • Linux-Ring0-Pilot, Linux-Ring1-Preprod, Linux-Ring2-Prod (or a global group like Linux-All).
  6. Schedule:
    • Initial scan.
    • Then regular scans (for example 1–2 times per day).

Use snapshots

Tanium Linux Patching – Goal: ensure Ring 0, Ring 1 and Ring 2 all apply exactly the same patch content.

Useful external reference: Tanium documentation.

  1. Verify that snapshots exist per distribution/version/date (for example RHEL8-2025-11, Ubuntu22-2025-11).
  2. In the TSL scan configuration, enable snapshot usage for deployments if available.

Tanium Linux Patching – Result: all deployments use the same snapshot and the same content.

Useful external reference: Tanium documentation.

Ring-based patching cycle

Ring 0 – Pilot

  1. Create a Deployment in Patch:
    • OS = Linux.
    • Source: all missing patches from a snapshot, or a Patch List + snapshot.
    • Snapshot = the monthly snapshot (e.g. RHEL8-2025-11).
    • Target = Linux-Ring0-Pilot.
    • Specific maintenance window for Ring 0.
  2. Deploy and verify results on pilot servers.

Ring 1 – Pre-prod

  1. Clone the Ring 0 deployment.
  2. Change:
    • Target = Linux-Ring1-Preprod.
    • Maintenance window = pre-prod window.
  3. Use the same snapshot.

Ring 2 – Prod

  1. Clone the Ring 1 deployment.
  2. Change:
    • Target = Linux-Ring2-Prod.
    • Maintenance window = production window (often night/weekend).
  3. Always use the same snapshot.

Production checks

  • Monitor Needs Attention endpoints in Patch before triggering a production ring.
  • Check compliance per Computer Group (Ring 0, 1, 2).
  • In case of errors:
    • check patch-process.log on an impacted endpoint;
    • run apt/yum/zypper commands locally to confirm OS-level behavior;
    • for TSL, verify that the Tanium Server can reach the repositories and that Client API Downloads work; for Repository Scan, verify that repository URLs are reachable from the endpoints.