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.

Repository Scan

  • The Linux endpoint talks directly to its repositories:
    • those configured on the OS (/etc/yum.repos.d, /etc/apt/sources.list, etc.);
    • or a list of repositories pushed by Tanium.
  • Tanium only:
    • triggers the scan;
    • launches installation through the native package manager.

Tanium Linux Patching – Key idea: Repository Scan = the Linux server uses its usual repo configuration, Tanium only orchestrates.

Useful external reference: Tanium documentation.

Tanium Scan for Linux (TSL)

  • Only the Tanium Server talks to the repositories.
  • It downloads and caches repository metadata, then distributes a “client DB” to the endpoints.
  • Endpoints run local scans with their native package manager using that metadata.

Tanium Linux Patching – Advantages:

Useful external reference: Tanium documentation.

  • Repository snapshots possible (freeze state at a given date).
  • Uses the linear chain to optimize bandwidth (one leader downloads, peers fetch from the leader).

Tanium Linux Patching – Key idea: TSL = Tanium centralizes repo information, enables snapshots, and saves bandwidth.

Useful external reference: Tanium documentation.

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;
    • verify repository URLs are reachable from the endpoints.