Linux - Software - Report Available Package Updates

What the Linux package update auditor does

This Automox Worklet™ enumerates every package on a Linux endpoint that has an available update and writes the inventory to both the Automox Activity Log and a CSV file at /var/log/amagent/available_package_updates.csv. The Worklet detects the installed package manager, queries the active repository metadata for upgrade candidates, and captures the package name, the new version, and the originating repository for each pending update.

On Debian and Ubuntu endpoints, the Worklet runs apt list --upgradable against the package index cached under /var/lib/apt/lists. On RHEL, CentOS, Rocky, and Alma endpoints, it runs yum check-update against the repositories configured in /etc/yum.repos.d/. On RHEL 8+ where yum is a wrapper around dnf, the same yum invocation resolves through dnf transparently. The report is generated as long as the local cache is current, even when the endpoint has no internet path to the upstream mirror.

By default the Worklet does not modify any package. The remediation phase is a read-only audit pass that produces evidence of the patch backlog. Set the complete_upgrade variable to 1 inside remediation.sh to chain an apt upgrade -y or yum update -y after the report is written, turning the same policy into a combined audit-and-patch run.

Why audit the Linux patch backlog

A single CVE advisory against glibc, openssl, sudo, or the kernel maps to a different package version on every distribution under management, and the authoritative answer to whether an endpoint is exposed lives in the package manager's own upgrade list. Without a fleet-wide audit, the patch team has to choose between trusting a stale scanner inventory or SSH-ing into hundreds of hosts to run apt list --upgradable by hand. The CSV this Worklet drops at /var/log/amagent/available_package_updates.csv is the same evidence an auditor would want for SOC 2 CC7.1, PCI-DSS 6.3.3, or the patch-management section of a CIS Benchmark review.

Running this audit across the Linux estate through a single Automox policy collects the upgrade inventory from every RHEL server, Ubuntu workstation, and Debian container host in the same evaluation cycle. The CSV on each endpoint is identical in format, which makes it easy to ingest into a SIEM, a vulnerability dashboard, or a spreadsheet for the next patch review. The Worklet turns an ad-hoc apt list --upgradable run buried in an SSH session into structured data the patch team can act on.

How the package update audit works

1. Evaluation phase: The Worklet detects the package manager with command -v yum and command -v apt-get, then queries for upgrade candidates with apt list --upgradable or yum check-update against whichever manager responds. If at least one package is upgradeable, the endpoint is flagged non-compliant and remediation is scheduled. If the upgrade list is empty, the Worklet exits 0 and the endpoint is recorded as compliant. If neither manager is found, the Worklet exits 0 and remediation is not scheduled.

2. Remediation phase: The Worklet re-queries the package manager and parses the output into a three-column CSV (Package, New-Version, Repository) at /var/log/amagent/available_package_updates.csv. The same rows are echoed to stdout so they appear in the Automox Activity Log for the policy run. If complete_upgrade is set to 1, the Worklet then invokes apt upgrade -y or yum update -y to apply every available update; otherwise the remediation finishes after the CSV is written and no package state changes.

Package update audit requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Debian, or Ubuntu with apt or yum available on the default PATH

• Current package index: /var/lib/apt/lists populated on apt systems, or repository metadata fresh in /var/cache/yum (or /var/cache/dnf on RHEL 8+) on RPM systems

• Root or sudo privileges (the default Automox agent context already meets this)

• Write access to /var/log/amagent/ for the CSV report

• Optional: set complete_upgrade=1 inside remediation.sh to chain the upgrade onto the audit pass

• Network reachability from the endpoint to its configured repositories if the local cache is stale

Expected output from the audit run

After a successful policy run, /var/log/amagent/available_package_updates.csv exists on every flagged endpoint with one row per upgradeable package. The Automox Activity Log shows the same rows under the policy run identifier, so a centralized search across the Automox console returns the same backlog the CSV captures. On endpoints with no pending updates, the Worklet exits 0 at evaluation and never reaches remediation, so the CSV is not regenerated and no Activity Log noise is produced.

Validate the run by reading the CSV directly with cat /var/log/amagent/available_package_updates.csv, which prints the header row plus every upgradeable package in the format Package, New-Version, Repository. Re-run apt list --upgradable or yum check-update on the endpoint and confirm the row counts match. If complete_upgrade was set to 1, the post-run apt list --upgradable or yum check-update should return an empty list, the Automox Activity Log should show the upgrade transcript, and a follow-up evaluation should flag the endpoint compliant. Capture the CSV with the policy run identifier as audit evidence for SOC 2 CC7.1, PCI-DSS 6.3.3, or the CIS Benchmark patch-management section before rotating logs out of /var/log/amagent/.