rpm

How FOSSA detects, licenses, and reports RPM packages (RHEL, Fedora, CentOS, Oracle Linux) during container scanning, plus RPM SPEC file analysis.

3 min readUpdated Jul 9, 2026

Overview

The RPM Package Manager (rpm) installs system packages on RHEL, Fedora, CentOS, and Oracle Linux. FOSSA detects RPM packages when it scans a container image, and can additionally analyze RPM SPEC files found in a source repository.

Note

RPM database detection runs during container scanning. RPM SPEC file analysis runs during a normal fossa analyze of a source repository. See Analyzing RPM SPEC files below.

Container scanning

How FOSSA identifies RPM packages

A detected RPM package is identified by its name, the distribution and version, its architecture, and its version (including the epoch and release where present). Red Hat Enterprise Linux (RHEL), CentOS, and Oracle Linux are supported; Fedora is in beta. RHEL-family versions are normalized to the major version (for example, 9). The package release is preserved, which matters for vulnerability matching, since security fixes are backported into new releases of the same version.

Discovery

An RPM installation may use one of several database backends. FOSSA looks for each:

BerkeleyDB: a file named Packages under var/lib/rpm.
NDB: a file named Packages.db under **/rpm/**.
SQLite: a file named Packages.sqlite or rpmdb.sqlite under var/lib/rpm.

Each backend shares a common record format; only the method of listing packages differs.

Analysis

FOSSA parses the database and reports each package's name, version, architecture, and (optionally) epoch.

License identification on RHEL and Oracle Linux

Warning

FOSSA resolves licenses for system packages from its Knowledge service rather than reading them out of the package database at scan time. For RHEL and Oracle Linux RPM packages this license data is often incomplete, so packages such as bash, perl, or coreutils may be reported as unlicensed even though license metadata exists in the RPM database.

Alpine (apk) and Debian/Ubuntu (dpkg) packages, by contrast, include complete license information.

Workaround: license affected packages manually in the FOSSA web app. Broader RHEL/Oracle Linux license coverage is on the roadmap, contact support@fossa.com if this is important to you.

Analyzing RPM SPEC files

Outside of container scanning, FOSSA can analyze RPM SPEC files in a source repository to determine runtime dependencies (the rpm-spec strategy). RPM packages managed by dnf and yum are built from SPEC files.

Strategy	Direct Deps	Transitive Deps	Edges	Tags	Container Scanning
rpm-spec	✅	❌	❌	Environment	✅

Discovery: FOSSA scans any file with a .spec extension (SPEC files follow the strict <package-name>.spec naming convention, e.g. binutils.spec).

Analysis: FOSSA reads lines beginning with Requires: followed by whitespace and extracts exactly one package per line, with an optional single version constraint. Each is treated as a direct, runtime dependency.

Warning

The rpm-spec strategy does not yet support:

Combinatoric version constraints such as (>= 1.2 and != 1.4) or = 0.9 (parentheses and and/or constructs).
Build-time requirements (BuildRequires:). These are parsed but not reported, since many are toolchain dependencies like gcc.
Macros such as xxxxxx-%{?_isa} or xxxxx = %{version}-%{release}.

FAQ

How do I only analyze RPM targets?

Specify the relevant RPM analysis targets in a .fossa.yml file to exclude all others:

YAML

# .fossa.ymlversion: 3targets:  only:    - type: ndb    - type: berkeleydb    - type: sqlitedb