# Machine-Readable Security Data (Errata, OVAL, CSAF)

TuxCare provides the following security updates for ELS for OS:

• Errata — qualified security and selected bug-fix errata advisories
• OVAL — Open Vulnerability and Assessment Language patch definitions for use with OpenSCAP and similar tools
• CSAF — Common Security Advisory Framework advisories in OASIS CSAF 2.0 format (VEX and Security Advisory)
• RSS — release feeds for tracking updates

Released fixes are available via tuxcare.com/cve-tracker and security.tuxcare.com.

# Security data feeds

| Oracle Linux 6 ELS | oval.xml | csaf | rss | | Oracle Linux 7 ELS | oval.xml | csaf | rss | | Red Hat Enterprise Linux 7 ELS | oval.xml | csaf | rss | | Red Hat Enterprise Linux 8 ELS | oval.xml | csaf | rss | | Ubuntu 16.04 ELS | oval.xml | csaf | rss | | Ubuntu 18.04 ELS | oval.xml | csaf | rss | | Ubuntu 20.04 ELS | oval.xml | csaf | rss |

# Errata advisories

TuxCare Endless Lifecycle Support provides qualified security and selected bug-fix errata advisories across all architectures. They can help users track which CVEs are resolved and which bugs have been addressed.

You can view the full list of released fixes on tuxcare.com/cve-tracker.

# OVAL patch definitions

Leveraging the Open Vulnerability and Assessment Language (OVAL) patch definitions with OVAL-compatible tools, e.g. OpenSCAP, users can accurately check their systems for the presence of vulnerabilities.

Identifying the vulnerabilities that apply to your systems is an important task for IT and InfoSec teams, and at TuxCare we make it easy. We provide OVAL data that contain instructions to the vulnerability scanner to determine the addressed vulnerabilities from the ELS updates. OVAL streams for each OS are listed in the Security data feeds table above.

# How to use OpenSCAP with TuxCare ELS

OpenSCAP is an open source vulnerability scanner and compliance tool and it can be used to scan a system protected by TuxCare ELS. The following steps show how to produce a vulnerability report for the system:

1. Install the ELS release package and OpenSCAP:

   RPMDEBAPK

   

   yum install els-define openscap openscap-utils scap-security-guide -y

2. Before running a scan, make sure the system is up to date and running the latest kernel:

   RPMDEBAPK

   

   yum update -y

3. Reboot the system.

4. RPM-based system only: after reboot, remove older kernel versions:

   EL 6, EL 7EL 8, EL 9

   

   package-cleanup --oldkernels --count=1 -y

5. Download the OVAL stream. For example, Ubuntu 18.04:

   wget https://security.tuxcare.com/oval/els_os/ubuntu18.04els/oval.xml
   

6. Run the scan:

   oscap oval eval --results results.xml --report report.html oval.xml
   

7. Examine the scan results report.

   Following the example above, the scan results report will be saved to the report.html file in the current directory. This file can then be downloaded for analysis or published directly with a local web server, for example:

   python3 -m http.server 8000
   

   or for python2

   python -m SimpleHTTPServer 8000
   

   Assuming the above command is run from the directory with the report.html file, the webpage with the report can then be accessed on http://<server-ip-address>:8000/report.html through a web browser.

   Note: the OpenSCAP report below is provided as an example. The results will vary depending on the OS and version you are scanning.

   

   The report includes a table with vulnerabilities and their status on the examined system. A line such as the one below reports that the system is vulnerable to CVE-2023-2828:

   update oval:com.tuxcare.clsa:def:1688677755 true patch [CLSA-2023:1688677755], [CVE-2023-2828] Fix CVE(s): CVE-2023-2828
   

   The table also includes corresponding hyperlinks to advisory pages where the package and the version containing the fix can be found as well as the command to run on the target system in order to install the update.

   Lines like the one below designate that the fix for the corresponding CVE is already installed on the system, and no further action is needed:

   oval:com.tuxcare.clsa:def:1694538670 false patch [CLSA-2023:1694538670], [CVE-2022-40433] Fix CVE(s): CVE-2022-40433
   

# How to integrate the OVAL data with a new vulnerability scanner

Identifying the vulnerabilities that apply to your systems is an important task for IT and InfoSec teams, and at TuxCare we make it easy.

To detect whether a system has TuxCare ELS installed, check for the following file being present: /etc/els-release.

Once that is validated, you can use the OVAL files corresponding to your operating system from above to scan for vulnerabilities.

# Common Security Advisory Framework

Common Security Advisory Framework (CSAF) is a machine-readable format, standardized by OASIS. It's designed to enable consistent and automated sharing of security advisory information. CSAF links for each OS are listed in the Security data feeds table above.

TuxCare publishes the following CSAF files at security.tuxcare.com:

• CSAF Vulnerability Exploitability eXchange (VEX) files – VEX documents, indexed by CVE, are available in CSAF 2.0 format, including past CVEs.
• CSAF Security Advisory files – advisories are published in CSAF 2.0 format and indexed by Security Advisory.

provider-metadata.json contains information for tools and users about where and how to retrieve CSAF advisories published by TuxCare. By OASIS requirements, it is available at two URLs (both serving the same file):

• csaf.data.security.tuxcare.com
• tuxcare.com/.well-known/csaf/provider-metadata.json

# RSS release feeds

TuxCare provides RSS feeds for tracking new ELS releases. RSS links for each OS are listed in the Security data feeds table above.

# Package Signature Verification (GPG)

Every package TuxCare builds for ELS for OS is cryptographically signed, so the package manager can confirm — before anything is installed or updated — that the package was produced by TuxCare and has not been altered in transit. Unlike a manual, per-file check, this verification is built into the native package manager (yum/dnf, apt, apk) and enabled by default: the ELS release package you install during setup imports TuxCare's signing key and turns signature checking on, so every subsequent transaction is verified automatically.

A successful verification proves two things about a package:

• Authenticity — it was signed by TuxCare's private key.
• Integrity — its bytes match exactly what was signed; no tampering or corruption occurred.

A failed verification is an integrity violation: the package manager refuses to install the package. Do not work around a failed check — for example by disabling GPG checking or downloading over an insecure channel — investigate the source instead.

# How Packages and Repository Metadata Are Signed

[centos7-els]
...
gpgcheck=1
repo_gpgcheck=1

# Confirm the TuxCare Signing Key Is Installed

The ELS release package installs the signing key for you during setup. To confirm it is present in the trust store your package manager uses, run:

RPMDEBAPK

rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep -i tuxcare

# Verify a Package

Because verification is automatic, the primary check is simply that a normal install or update succeeds. You can also verify a downloaded package explicitly.

yum install <package>

rpm -K <package>.rpm

# Integrity Violation Events

An integrity violation is any event where a package obtained from TuxCare — or the channel it was retrieved over — fails a verification check, indicating the package may not be authentic or may have been altered in transit. The package manager already blocks the operation (the install or update stops), but by default the only trace is the command's exit code and whatever scrolled past in the terminal. To align with the EU Cyber Resilience Act (CRA), these events should be treated as security-relevant and retained in a dedicated log so a system administrator can review them regardless of when or how the update was triggered.

# What Counts as an Integrity Violation

ELS for OS is delivered through the native OS package repositories — yum/dnf for RPM-based systems (CentOS, Oracle Linux, RHEL, AlmaLinux, and similar), apt for Debian and Ubuntu, and apk for Alpine — served exclusively over HTTPS, with GPG-signed packages and repository metadata. The following verification failures are integrity violations. Select your distribution:

# Capturing Integrity Violations in a Dedicated Log

Because these checks run inside the package manager, their outcome lives only in the command's exit code and console output. To retain violations for later review — as CRA expects — run the update or install inside a wrapper that writes the result to a dedicated log, separate from ordinary output. Running this from a scheduled job, a cron task, or a configuration-management run guarantees the event is captured no matter who triggered the update or whether anyone was watching the terminal.

#!/usr/bin/env bash
set -o pipefail
LOG=/var/log/tuxcare-integrity.log

if yum -y update; then
  logger -t tuxcare-integrity -p authpriv.info "OK: yum update"
else
  rc=$?
  msg="INTEGRITY VIOLATION: yum update (exit ${rc})"
  echo "$(date -u +%FT%TZ) ${msg}" | tee -a "$LOG"
  logger -t tuxcare-integrity -p authpriv.err "${msg}"
  exit 1
fi

logger hands the event to journald/rsyslog under the tuxcare-integrity tag. To route these events into their own file, add an rsyslog rule:

# /etc/rsyslog.d/30-tuxcare-integrity.conf
:programname, isequal, "tuxcare-integrity"   /var/log/tuxcare-integrity.log
& stop

Reload rsyslog afterwards (systemctl restart rsyslog). To review the captured events through journald instead of a file:

journalctl -t tuxcare-integrity