Binary Vulnerability Scanning: Catch Backported Patches, Cut False Positives

Binary vulnerability scanning is the practice of verifying a CVE fix directly in the compiled machine code of a running process, instead of matching against package version strings. It is what lets a scanner see through backported patches — the single largest source of false positives in Linux vulnerability reports — and report only vulnerabilities that are actually still exploitable.

Every version-matching scan hands security teams the same artifact: a red-alert checklist most engineers can guess is mostly false positives — but proving it, alert by alert, buries the real risks under manual triage. OpenResty XRay closes that gap by inspecting the running binary directly.

Why Version-Matching Vulnerability Scanning Fails: Three Compounding Costs

Mainstream Linux distributions — RHEL, Rocky Linux, Debian, Ubuntu LTS — routinely backport upstream security patches into their supported versions without bumping the package version number, preserving ABI compatibility. As a result, a package labeled openssl-3.5.1 might already carry patches for dozens of CVEs, yet look identical to an unpatched openssl-3.5.1 to any version-matching scanner. That single-signal reliance imposes three compounding costs on engineering teams:

• Accumulating False Positive Noise. Throughout a distribution’s LTS cycle, a large number of backported patches are applied. Every CVE that is patched without a version number change will reappear in subsequent scan reports. Over time, the volume of false positives only grows.

• Manual Verification Drains Core Engineering Effort. For each alert, engineers must consult distribution changelogs, cross-reference CVE databases, and determine if a patch has been applied. This work is essentially a manual effort to bridge the scanner’s capability gap, rather than performing true security analysis.

• Real Risks Are Diluted and Prioritization Fails. When 90% of the alerts in a report are false positives, the 10% that represent real vulnerabilities are easily overlooked. The core value of vulnerability management—helping teams focus on the highest-impact risks—is lost in the noise.

The fundamental problem with traditional version-matching scans lies not in the quality of the tools themselves, but in their reliance on a signal that is inherently untrustworthy in the backporting ecosystem: the version number.

How OpenResty XRay’s Binary Vulnerability Scanning Works: The Evidence-First Model

OpenResty XRay fundamentally moves beyond the unreliable indicator of version numbers. Instead of scanning package manager metadata, it targets the running process itself.

When OpenResty XRay evaluates a system’s exposure to a CVE, it doesn’t check component version strings. Instead, it directly inspects the libraries loaded into running processes to verify whether the binary signature of the corresponding patch is actually present.

In other words: We don’t rely on what the version number claims; we verify if the vulnerability patch is actually present in the binary code.

This approach inherently handles backporting scenarios. Regardless of how a distribution applies a patch—with or without changing the version number or updating the changelog—if the patch is present in the binary, OpenResty XRay will mark the CVE as resolved. Otherwise, it will accurately report that the vulnerability still exists.

Runtime Binary Scanning vs. Static File System Scanning

OpenResty XRay’s use of runtime dynamic tracing is what fundamentally distinguishes its scan coverage from that of static scanning tools:

It’s important to note that runtime scanning means OpenResty XRay’s scope is strictly limited to currently running processes and their loaded dependencies. Inactive services and unloaded library files are not covered. This is a key consideration for practical use: to get a complete scan result, you must ensure the target service is running during the scan.

Which Libraries XRay Scans for CVEs

OpenResty XRay currently supports vulnerability scanning for the following key dependencies:

Our coverage is continuously expanding. To inquire about support for a specific library, please contact the OpenResty Inc. team.

Case Study: Binary Vulnerability Scanning on Rocky Linux with Dual OpenSSL Versions

The following demonstration takes place in a Rocky Linux production environment running two different versions of OpenSSL simultaneously: the system’s native OpenSSL 3.5.1 (which includes backported patches from the distribution) and a custom-compiled OpenSSL 1.1.1w bundled with OpenResty Plus. This setup is very common in production and represents a classic case where traditional scanning tools often generate conflicting or inaccurate results.

Environment Setup

Operating System: Rocky Linux
System OpenSSL:
  /usr/lib64/libcrypto.so.3.5.1
  /usr/lib64/libssl.so.3.5.1
  (Source: System package manager, with backported patches from the distribution)

Custom-compiled OpenSSL:
  /usr/local/openresty-plus/openssl111/lib/libcrypto.so.1.1
  /usr/local/openresty-plus/openssl111/lib/libssl.so.1.1
  (Source: Compiled and bundled with OpenResty Plus, version 1.1.1w)

Other System Libraries:
  /usr/lib64/libpcre2-8.so.0.11.0
  (Source: System package manager)

Understanding the Scan Results Overview

Please refer to the OpenResty XRay product documentation for the specific commands to initiate a vulnerability scan. The output below is shown after a scan is triggered.

OpenResty XRay automatically discovers all running processes on the system, enumerates their loaded library dependencies, and performs binary evidence verification on each supported component. The entire process requires no manual specification of scan paths and does not rely on the package manager’s database.

Once the scan is complete, OpenResty XRay presents the results on a per-component basis. Each record includes the library file path, CVE identifier, and vulnerability status.

The status is indicated visually:

• 🟢 Green background: The CVE has been fixed by a patch (Patched)—binary evidence confirms the presence of the patch.
• 🔵 Blue background: The CVE is still present (Vulnerable)—binary evidence did not find the patch.

Here are representative results from this scan:

System OpenSSL 3.5.1 (from distribution package)

Library files: /usr/lib64/libcrypto.so.3.5.1
               /usr/lib64/libssl.so.3.5.1

CVE-2025-11187   ✅ Patched
CVE-2025-15467   ✅ Patched
CVE-2025-15468   ✅ Patched
CVE-2025-15469   ✅ Patched
CVE-2025-66199   ✅ Patched
CVE-2025-68160   ✅ Patched
CVE-2025-69418   ✅ Patched
CVE-2025-69419   ✅ Patched
CVE-2025-69420   ✅ Patched
CVE-2025-69421   ✅ Patched
CVE-2026-22795   ✅ Patched
CVE-2026-22796   ✅ Patched
CVE-2026-2673    🔵 Vulnerable

Cross-Verifying with the Distribution’s Changelog

To confirm the reliability of OpenResty XRay’s scan conclusions, we can verify them directly against the distribution’s own changelog.

Run the following command on the system’s OpenSSL package:

rpm -q --changelog openssl-libs | head -20

The output is as follows:

* Fri Jan 16 2026 Dmitry Belyavskiy <dbelyavs@redhat.com> - 1:3.5.1-7
- Fix CVE-2025-11187 CVE-2025-15467 CVE-2025-15468 CVE-2025-15469
  CVE-2025-66199 CVE-2025-68160 CVE-2025-69418 CVE-2025-69419 CVE-2025-69420
  CVE-2025-69421 CVE-2026-22795 CVE-2026-22796
  Resolves: RHEL-142068
  Resolves: RHEL-142002
  ...

Every CVE listed in the changelog is marked as Patched in the OpenResty XRay scan results, showing a perfect match between the two records.

Clicking on any vulnerability reveals its detailed description:

The only CVE marked as Vulnerable, CVE-2026-2673, is likewise absent from the changelog’s fix records — the distribution’s maintainers evaluated it as low severity and decided against a backport. OpenResty XRay accurately reflects this reality: it neither claims the CVE is fixed because the version string is current, nor hides it because the distribution has not addressed it.

This is the two-sided proof of binary evidence verification: no false positives on backported patches, and no false negatives when a distribution chose not to patch. Scan conclusions correspond precisely to the actual patch status in the shipping binary.

From Alert Fatigue to Precision: A Sustainable Vulnerability Scanning Practice

Unseen risks are the hardest to manage. OpenResty XRay brings these previously invisible dependencies into a unified vulnerability scanning view. This is its core value proposition beyond what traditional package managers offer.

Effective vulnerability management isn’t about generating reports; it’s about establishing a trusted system of signals that engineering teams consistently act on. Tools with high false-positive rates inevitably lead to “alert fatigue.” When every alert requires manual verification, response times slow down, the process becomes a mere formality, and critical vulnerabilities get lost in the noise, delaying their remediation.

OpenResty XRay’s verification mechanism uses binary-level evidence to eliminate systemic false positives caused by backporting. This ensures that every vulnerability alert corresponds to a real, existing risk at the binary level, removing the need for manual triage.

Moreover, OpenResty XRay provides a runtime view (“what is actually running”) rather than a package manager’s view (“what is installed”). This distinction is critical: when an EOL component with a known vulnerability (like OpenSSL 1.1.1w) is processing live production traffic while remaining invisible to all static scanners, it determines whether your true attack surface is actually protected. Accurate scan results are the prerequisite for evolving vulnerability management from an ad-hoc task into a sustainable SecOps practice.

Frequently Asked Questions

How does binary vulnerability scanning eliminate false positives?

Binary vulnerability scanning inspects the machine code loaded into a running process and looks for the binary signature of the CVE patch itself. When the patch is present in the binary, the CVE is marked resolved — regardless of what version string the package advertises. That removes the entire class of false positives caused by distribution backports silently patching without a version bump.

Does OpenResty XRay scan OpenResty itself, or its dependencies?

OpenResty XRay scans the shared libraries loaded into a running process — currently OpenSSL, LibreSSL, zlib, bzip2, glibc, musl, libcurl, libxml2, and pcre2. The case study in this article shows OpenResty Plus bundling an EOL OpenSSL 1.1.1w that a package-manager scan would miss entirely. Coverage is expanding; contact the OpenResty Inc. team about a specific library.

What’s the difference between runtime and static vulnerability scanning?

Static scanning reads packages and files on disk and matches version numbers against CVE databases. Runtime scanning attaches to the processes actually executing on the host and verifies patch presence directly in the binaries they loaded. The tradeoff: static scans see inactive files runtime cannot, while runtime scans see custom-compiled and bundled binaries that never went through the package manager — and correctly reflect backported patches.

Why do version-based scanners struggle with backported CVE patches?

Version-based scanners rely on a vulnerability database to know which package versions carry which patches. When that database is incomplete — missing distro-specific backport records, off-distribution builds, or newly disclosed CVEs — the scanner falls back to the version string and reports false positives. Binary scanning bypasses the database dependency by verifying the patch directly in the running machine code.

What is OpenResty XRay

OpenResty XRay is a dynamic-tracing product that automatically analyzes your running applications to troubleshoot performance problems, behavioral issues, and security vulnerabilities with actionable suggestions. Under the hood, OpenResty XRay is powered by our Y language targeting various runtimes like Stap+, eBPF+, GDB, and ODB, depending on the contexts.

If you like this tutorial, please subscribe to this blog site and/or our YouTube channel. Thank you!

About The Author

Yichun Zhang (Github handle: agentzh), is the original creator of the OpenResty^® open-source project and the CEO of OpenResty Inc..

Yichun is one of the earliest advocates and leaders of “open-source technology”. He worked at many internationally renowned tech companies, such as Cloudflare, Yahoo!. He is a pioneer of “edge computing”, “dynamic tracing” and “machine coding”, with over 22 years of programming and 16 years of open source experience. Yichun is well-known in the open-source space as the project leader of OpenResty^®, adopted by more than 40 million global website domains.

OpenResty Inc., the enterprise software start-up founded by Yichun in 2017, has customers from some of the biggest companies in the world. Its flagship product, OpenResty XRay, is a non-invasive profiling and troubleshooting tool that significantly enhances and utilizes dynamic tracing technology. And its OpenResty Edge product is a powerful distributed traffic management and private CDN software product.

As an avid open-source contributor, Yichun has contributed more than a million lines of code to numerous open-source projects, including Linux kernel, Nginx, LuaJIT, GDB, SystemTap, LLVM, Perl, etc. He has also authored more than 60 open-source software libraries.