On Debian and Ubuntu, run dpkg -S with the file path. On RPM systems such as Fedora and RHEL, run rpm -qf with the file path. Either command names the installed package that owns the file, which is the package whose advisory and fixed version you need to check.
The problem this solves
A scanner, a log line or a colleague points at a file: a shared library, a binary in a container. Advisories are published against packages, not files. You need the bridge from path to package before you can ask whether a fix exists.
Debian and Ubuntu
The Debian Reference describes dpkg -S as listing installed packages with a matching file name. It warns that this misses files created by maintainer scripts. The related command dpkg -L lists the contents of a package.
dpkg -S /usr/lib/x86_64-linux-gnu/libexample.so.1
dpkg -L package-name
apt-cache policy package-name
The third command shows the available version, priority and archive information of the package, so you can compare installed with candidate.
Fedora and RHEL style systems
The rpm manual defines the file option as querying the package that owns an installed file, and the list option as listing files in a package:
rpm -qf /usr/lib64/libexample.so.1
rpm -ql package-name
rpm -qi package-name
rpm -q --changelog package-name
The info query shows name, version and description, and the changelog query shows change information for the package, which is where distributions often list the CVE identifiers they fixed.
From package to answer
| Step | Debian and Ubuntu | RPM systems |
|---|---|---|
| Who owns the file | dpkg -S | rpm -qf |
| What version is installed | apt-cache policy | rpm -qi |
| What changed | apt-get changelog | rpm -q with the changelog option |
| Is there a fix | Distribution security tracker or advisory | Vendor errata and updateinfo |
Debian's security FAQ suggests looking up the CVE in the Debian Security Tracker, comparing your installed version with the fixed version, and reading the changelog for the fix entry. That last step matters because distributions often backport fixes without changing the upstream version number, as covered in fixed version or backported fix: how to judge a patch.
Watch for these traps
- The file may be a copy, not a package file. Software installed outside the package manager, or copied into an image by a build step, has no owner. dpkg -S returns an error. Treat that as a finding, because nothing will patch it for you.
- Files in a statically linked binary do not exist as separate libraries. See why statically linked binaries ignore apt upgrades.
- One source package produces several binary packages. Debian notes that an advisory names a source package, so you should upgrade every binary package built from it.
A short routine
- Find the owner.
- Read the installed version.
- Look up the CVE in your distribution's tracker or errata.
- Update, restart, and confirm the new version is running.
Quick check
What if dpkg -S finds nothing?
The file may come from a maintainer script or be installed outside the package manager. Search the image build steps and the application tree.
Does the installed version number tell me if I am fixed?
Not always. Distributions backport fixes, so compare against the distribution's fixed version, not the upstream one.
Safeguard's SBOM and dependency scanning records the packages in your images and repositories, so the owner lookup is already done when a finding appears. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
