CVE hygiene

(Or why vulnerability scanners cannot be trusted to be the final arbiter of security patching)¶

AI usage¶

This document adheres to the AI contribution policy found here. If you find any errors in the instructions, please let us know.

Introduction¶

Vulnerability scanners frequently flag packages on Rocky Linux systems as unpatched or outdated. In many cases, these are false positives caused by how scanners interpret package version strings. This guide teaches you how to independently verify whether a CVE has been patched in your Rocky Linux packages, understand advisory numbering, address scanner false positives, and apply security updates.

Prerequisites and assumptions¶

A Rocky Linux 8, 9, or 10 system.
Root or sudo access.

Methods for verifying CVE patches¶

There are several ways to determine whether a specific CVE has been fixed on your Rocky Linux system:

RPM changelogs: Query the package changelog for CVE identifiers.
dnf updateinfo: Check security advisories from Rocky Linux repositories.
Rocky Linux Errata: Search the advisory database at errata.rockylinux.org.¹
Upstream security advisories: Search the upstream vendor advisory database at access.redhat.com/security/security-updates/security-advisories.²
Upstream CVE pages: Check platform applicability and severity at access.redhat.com/security/cve/.³
Build systems: Check Koji⁴ or Peridot⁵ for pending package builds.
OVAL scanning: Use OpenSCAP¹¹ with Rocky Linux OVAL data⁷ for automated vulnerability assessment.

Each method has strengths. RPM changelogs confirm what is installed locally. The dnf updateinfo commands show what advisories are available or already applied. The upstream security advisories page and Rocky Linux Errata provide the broadest view of all published fixes. The following sections cover each method in detail.

Checking RPM changelogs for CVE patches¶

One way to determine whether a specific CVE has been fixed in an installed package is to inspect its RPM changelog. Upstream and Rocky Linux package maintainers include CVE identifiers in changelog entries when backporting security fixes¹⁰.

Basic changelog query¶

To check whether a specific CVE has been patched in a package:

rpm -q --changelog openssl | grep CVE-2024-6119

If the CVE has been addressed, you will see a changelog entry similar to:

- Fix CVE-2024-6119: Possible denial of service in X.509 name checks
  Resolves: CVE-2024-6119

If the command produces no output, the CVE fix is not present in the currently installed version of the package.

Querying a specific package version¶

To check the changelog of a package file that is not yet installed:

rpm -qp --changelog ./openssl-3.0.7-28.el9_4.x86_64.rpm | grep CVE-2024-6119

Querying the repository without installing¶

To check changelogs for a package available in a repository:

dnf repoquery --changelog openssl | grep CVE-2024-6119

Changelog truncation

RPM binary packages may have truncated changelogs. The build system trims old entries based on age. If you are searching for an older CVE and the changelog search returns no results, the entry may have been trimmed. Check the source RPM or use the Koji build system web interface, which displays the full changelog at the bottom of each build page.

Using dnf updateinfo for security advisories¶

The dnf updateinfo subsystem provides a structured view of security advisories affecting your system.

View a summary of available advisories¶

dnf updateinfo

Example output:

Updates Information Summary: available
    3 Security notice(s)
        1 Critical Security notice(s)
        2 Important Security notice(s)
    2 Bugfix notice(s)
    1 Enhancement notice(s)

List available security advisories¶

dnf updateinfo list security

List already-installed security advisories¶

dnf updateinfo list security --installed

Check a specific CVE¶

To see whether an advisory exists for a specific CVE:

dnf updateinfo info --cve CVE-2024-6119

To check whether the fix is already installed:

dnf updateinfo list --cve CVE-2024-6119 --installed

Check available security updates without installing¶

dnf check-update --security

Quick reference

Command	Purpose
`dnf updateinfo`	Summary of available advisories
`dnf updateinfo list security`	List available security advisories
`dnf updateinfo list security --installed`	List installed security advisories
`dnf updateinfo info --cve CVE-XXXX-XXXXX`	Details for a specific CVE
`dnf check-update --security`	Check for available security updates

Understanding RHSA and RLSA advisory numbering¶

Rocky Linux security advisories (RLSA) directly mirror upstream security advisories RHSA¹³. The advisory numbers are shared, with only the prefix differing.

For example:

RHSA-2024:2551 is the upstream advisory.
RLSA-2024:2551 is the corresponding Rocky Linux advisory.

Advisory type prefixes¶

Upstream	Rocky Linux	Meaning
RHSA	RLSA	Security Advisory
RHBA	RLBA	Bug Fix Advisory
RHEA	RLEA	Enhancement Advisory

The sequential number after the year is shared across all advisory types¹³. RHSA numbers may appear to skip because the intervening numbers belong to RHBA and RHEA advisories.

Where to find Rocky Linux advisories¶

Rocky Linux advisories are published at Rocky Linux Errata¹. You can search by advisory ID, package name, or CVE identifier.

Publication timing

Rocky Linux advisories may appear later than the corresponding upstream advisory. The time lag depends on the Rocky Linux release engineering pipeline. A missing RLSA does not necessarily mean the fix is unavailable. Always check the RPM changelog and the build systems described in the "Monitoring Rocky Linux build systems" section below.

Module stream version naming¶

Rocky Linux 8 uses modular repositories (AppStream) where package releases include a module stream identifier in the release string. This identifier is a frequent source of false positives in vulnerability scanners.

Anatomy of a modular release string¶

A typical modular package release string looks like:

pcs-0.10.12-6.el8.6.0+7105+f31cb332.x86_64

Breaking this down:

Component	Meaning
`pcs`	Package name
`0.10.12`	Upstream version
`6`	RPM release number
`el8`	Enterprise Linux 8
`.6.0`	Module stream built for the 8.6 minor release
`+7105`	Module build sequence number
`+f31cb332`	Context hash identifying the module build

Why scanners flag these incorrectly¶

Vulnerability scanners compare the full NVR (Name-Version-Release) string against their vulnerability databases. When a scanner encounters el8.6.0 in the release string, it may interpret this as "built for Rocky 8.6" and flag it as outdated compared to a package with el8.10.0 in its release string.

This is a false positive. The module stream suffix (el8.6.0 versus el8.10.0) indicates when the module was built, not the security content of the package. A package with el8.6.0 in its release string can contain identical security patches to one with el8.10.0.

How to verify¶

Compare the actual package version and RPM release number (the parts before the module stream suffix), not the full NVR string:

rpm -q pcs

If two systems show:

pcs-0.10.12-6.el8.6.0+7105+f31cb332
pcs-0.10.12-6.el8.10.0+1234+abcdef01

The package version (0.10.12) and RPM release (6) are identical. These packages contain the same security patches regardless of the module stream suffix.

Scanner configuration

If your vulnerability scanner repeatedly flags module stream version differences as vulnerabilities, work with your scanner vendor to add proper Rocky Linux package mapping. Scanners that rely on generic NVD feeds without understanding enterprise Linux backporting will produce inaccurate results.

Monitoring Rocky Linux build systems¶

When a CVE fix has been announced upstream but is not yet available in Rocky Linux repositories, you can track the build and publication pipeline.

Build system URLs¶

System	URL	Purpose
Koji	koji.rockylinux.org⁴	Build system for Rocky Linux 8
Peridot	peridot.build.resf.org⁵	Build system for Rocky Linux 9
Errata	errata.rockylinux.org¹	Advisory database
Git	git.rockylinux.org⁶	Source package repositories

Checking build status in Koji¶

For Rocky Linux 8 packages:

Navigate to koji.rockylinux.org
Search for the package name
Click on the latest build to view the full changelog
Check whether the CVE fix appears in the changelog

Build completion versus repository availability

A package appearing in the Koji or Peridot build system does not mean it is available in the official repositories. After a package is built, it goes through testing and staging before publication. Check the official repositories with dnf check-update to confirm availability.

Applying security updates¶

Update all security packages¶

sudo dnf update --security

Apply a fix for a specific CVE¶

sudo dnf update --cve CVE-2024-6119

Apply a specific advisory¶

sudo dnf update --advisory RLSA-2024:2551

Minimal security update¶

To apply the smallest version change that addresses security issues:

sudo dnf upgrade-minimal --security

Configure automatic security updates¶

Install the dnf-automatic package:

sudo dnf install dnf-automatic

Edit /etc/dnf/automatic.conf to enable security-only updates:¹²

[commands]
upgrade_type = security
apply_updates = yes

Enable and start the timer:

sudo systemctl enable --now dnf-automatic.timer

Automatic updates in production

Automatic security updates can cause unexpected service restarts or compatibility issues. In production environments, consider using apply_updates = no and reviewing available updates manually before applying them.

End-of-life operating systems¶

Operating systems that have reached end of life (EOL) no longer receive security patches. If your vulnerability scanner flags CVEs on an EOL system, no upstream fix will be published.

Key EOL dates¶

Distribution	EOL Date
CentOS 7	June 30, 2024¹⁴
Rocky Linux 8	May 31, 2029¹⁴
Rocky Linux 9	May 31, 2032¹⁴

EOL systems receive no patches

Running an EOL operating system in a production environment means accepting all future security vulnerabilities without remediation. The recommended action is migrating to a supported operating system version.

Addressing vulnerability scanner false positives¶

Vulnerability scanners such as Nessus (Tenable), Wazuh, and Nexpose can produce false positives on Rocky Linux for several reasons:

Common causes of false positives¶

Module stream version comparison: Scanners flag el8.6.0 as outdated compared to el8.10.0 (see the "Module stream version naming" section)
Upstream version comparison: Scanners compare against upstream (unpatched) version numbers without accounting for enterprise Linux backporting
Missing Rocky Linux OVAL data: Some scanners lack proper Rocky Linux vulnerability mappings and fall back to generic NVD feeds
Platform-inapplicable CVEs: Scanners flag all CVEs in an advisory regardless of operating system applicability

Verification workflow for scanner findings¶

When a vulnerability scanner reports a finding, follow this workflow:

Check the RPM changelog for the CVE:

rpm -q --changelog <package> | grep CVE-XXXX-XXXXX

Check dnf updateinfo for the advisory:

dnf updateinfo info --cve CVE-XXXX-XXXXX

Check the upstream CVE page for platform applicability:

https://access.redhat.com/security/cve/CVE-XXXX-XXXXX

If the CVE is patched, document the evidence (changelog entry, advisory number) and mark the scanner finding as a false positive.
If the CVE is not patched, check the build systems (Koji or Peridot) for a pending fix, or apply the available security update.

Documenting scanner exceptions

Maintain a record of verified false positives with their evidence. This documentation helps streamline future vulnerability scan reviews and supports audit compliance processes.

OVAL scanning with OpenSCAP¶

Rocky Linux publishes OVAL (Open Vulnerability and Assessment Language) data that can be used with OpenSCAP¹¹ to perform automated vulnerability assessments.

Downloading Rocky Linux OVAL data¶

OVAL definition files are available at dl.rockylinux.org/pub/oval/⁷:

Rocky Linux 8: org.rockylinux.rlsa-8.xml
Rocky Linux 9: org.rockylinux.rlsa-9.xml

Download the file for your version:

wget https://dl.rockylinux.org/pub/oval/org.rockylinux.rlsa-9.xml.bz2
bunzip2 org.rockylinux.rlsa-9.xml.bz2

Running an OVAL scan¶

Install OpenSCAP if not already present:

sudo dnf install openscap-scanner

Run the vulnerability scan:

oscap oval eval --results oval-results.xml org.rockylinux.rlsa-9.xml

Generate an HTML report:

oscap oval generate report oval-results.xml > oval-report.html

OVAL data limitations

OVAL scans may produce false positives on Rocky Linux, particularly for packages where the OVAL definitions have not been updated to reflect the latest advisory status. Always cross-reference OVAL results with RPM changelogs and dnf updateinfo for confirmation.

Conclusion¶

Effective CVE management on Rocky Linux requires understanding how backporting, advisory numbering, and module stream versioning work. Vulnerability scanners are valuable tools, but their findings must be validated against RPM changelogs, dnf updateinfo, and official advisory databases. By following the verification workflow in this guide, you can accurately distinguish between genuine vulnerabilities and false positives.

References¶

"Rocky Linux Errata" by the Rocky Enterprise Software Foundation https://errata.rockylinux.org/
"Security Updates and Advisories" by Upstream https://access.redhat.com/security/security-updates/security-advisories
"CVE Database" by Upstream https://access.redhat.com/security/cve/
"Rocky Linux Koji Build System" by the Rocky Enterprise Software Foundation https://koji.rockylinux.org/koji/
"Peridot Build System" by the Rocky Enterprise Software Foundation https://peridot.build.resf.org/
"Rocky Linux Git" by the Rocky Enterprise Software Foundation https://git.rockylinux.org/
"Rocky Linux OVAL Data" by the Rocky Enterprise Software Foundation https://dl.rockylinux.org/pub/oval/
"CIQ Security Advisories" by CIQ https://github.com/ctrliq/advisories/tree/main
"Severity Ratings" by Upstream https://access.redhat.com/security/updates/classification
"Enterprise Linux Life Cycle - Update Policies" by Upstream https://access.redhat.com/support/policy/updates/errata
"OpenSCAP Portal" by the OpenSCAP Project https://www.open-scap.org/
"DNF Automatic" by the DNF Development Team https://dnf.readthedocs.io/en/latest/automatic.html
"Explaining Errata" by Upstream https://access.redhat.com/articles/explaining_redhat_errata
"Rocky Linux Version Information" by the Rocky Enterprise Software Foundation https://wiki.rockylinux.org/rocky/version/

Author: Howard Van Der Wal

Contributors: Steven Spencer