After every vulnerability scan, security teams aren’t left with answers, but with a massive verification checklist: dozens, sometimes hundreds, of red alerts for components with “non-compliant” version numbers. Engineers who understand how Linux distributions work are well aware that most of these aren’t real risks. However, proving this for each alert is a time-consuming task in itself. This isn’t an operational mistake; it’s a structural flaw in traditional version-matching scanners. These tools treat the version number as the single source of truth for security, but in the backporting ecosystem, a version number is far from a reliable signal. As the noise from false positives accumulates, engineering effort is wasted on manual verification instead of genuine risk analysis, allowing real vulnerabilities to get buried. This article delves into how OpenResty XRay uses dynamic tracing to directly inspect the actual machine code running within a process. By bypassing the intermediate layer of version numbers, this method fundamentally eliminates false positives and restores the crucial ability to accurately prioritize vulnerabilities.

Mainstream Linux distributions—including RHEL, Rocky Linux, Debian, and Ubuntu LTS—widely use a backporting strategy. When a security vulnerability is found in an upstream component, distribution maintainers backport the patch to the version they currently support without changing the package’s version number. This approach allows them to apply critical security fixes while maintaining ABI compatibility and overall system stability.

As a result, a package labeled openssl-3.5.1 might already contain patches for dozens of CVEs. However, based on its version number alone, it is indistinguishable from an entirely unpatched openssl-3.5.1.

Why Version-Matching Scans Fail: Three Compounding Costs

Scanners that rely on version matching cannot detect backported patches, imposing three high 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 XRay Scans Binaries Directly: 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.

“Binary Evidence” is a core concept for vulnerability scanning in OpenResty XRay.

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 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.

Scan Coverage

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: Detecting Dual OpenSSL Versions on Rocky Linux

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. This is because the vulnerability has a low severity level, and the distribution’s maintainers evaluated and decided against backporting a patch for it. OpenResty XRay accurately reflects this reality. It neither misreports the CVE as “fixed” based on the latest version number, nor does it hide the vulnerability just because the distributor has not yet addressed it.

This demonstrates the core value of binary evidence verification: the scan conclusions correspond precisely to the actual patch status of the distribution, ensuring accurate reporting without false positives or false negatives.

Building a Sustainable Scanning Practice on Precision Evidence

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.

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.