← 戻る

バイナリ証拠駆動の脆弱性スキャン：OpenResty XRay によるバージョン推論からの脱却

Yichun Zhang 投稿日 Mar 24, 2026 更新日 Mar 25, 2026

用時約13分

閲覧数

脆弱性スキャンが完了するたびに、セキュリティチームが手にするのは明確な答えではなく、膨大な確認待ちリストです。そこには、バージョン番号が「要件未達」とされたコンポーネントを指す、数十から数百ものアラートが並びます。Linux ディストリビューションの仕組みを理解しているエンジニアであれば、その大半が実際にはリスクではないと認識していますが、それを一つひとつ証明する作業には多大な時間が費やされます。これは運用上のミスではなく、従来のバージョン照合型スキャンが抱える構造的な欠陥です。つまり、バージョン番号をセキュリティ状態を示す絶対的な指標と見なしてしまう点に問題があります。しかし、パッチがバックポートされる環境において、バージョン番号は決して信頼できる情報ではありません。誤検知というノイズは増え続け、エンジニアは本来のリスク分析ではなく、誤検知の確認作業にリソースを奪われ、本当に危険な脆弱性が見過ごされてしまうのです。本稿では、OpenResty XRay が動的トレース技術を用い、バージョン番号という中間層を介さずに、プロセス空間内で実際に使用されているマシンコードを直接解析する方法を詳しく解説します。これにより、誤検知を構造的に解消し、脆弱性管理に本来求められる優先順位付けの能力をいかにして取り戻すのかをご紹介します。

OpenResty XRay の試用をすぐに申請する

RHEL、Rocky Linux、Debian、Ubuntu LTS といった主要な Linux ディストリビューションは、一般的に「バックポート」と呼ばれる戦略を採用しています。これは、アップストリームのコンポーネントでセキュリティ脆弱性が発見された際に、ディストリビューションのメンテナーが修正パッチを現在提供中のバージョンに適用し、バージョン番号は更新しないという手法です。これにより、ABI の互換性とシステムの安定性を維持したまま、セキュリティ修正を適用することができます。

その結果、openssl-3.5.1 というバージョンのパッケージに、実際には数十件もの CVE 修正パッチが含まれている可能性があるにもかかわらず、バージョン番号だけでは、パッチが一切適用されていない同バージョンのパッケージと全く見分けがつかない、という状況が生まれます。

従来スキャンの構造的欠陥：なぜバージョン番号は信頼できないのか

バージョン番号の照合に依存するスキャンツールは、バックポートの存在を検知できないため、開発・運用チームに以下のような3つの実務的なコストを強いることになります。

増え続ける誤検知ノイズ。 ディストリビューションは LTS のサポート期間中、大量のバックポートパッチを蓄積します。そのため、パッチで修正済みにもかかわらずバージョン番号が変わらない CVE が、スキャンを実行するたびに繰り返し報告されます。時間が経つにつれ、誤検知の数は増える一方です。
確認作業によるセキュリティチームの工数浪費。 エンジニアはアラート一つひとつに対し、ディストリビューションの変更履歴（changelog）を確認し、CVE データベースと照合して、パッチ適用の有無を判断しなければなりません。これは、本来ツールが担うべき役割を人手で補っているに過ぎず、本質的なセキュリティ分析作業ではありません。
本当のリスクの希薄化と優先順位付けの形骸化。 スキャンレポートに含まれるアラートの 9 割が誤検知であれば、残りの 1 割に潜む本当の脅威は見過ごされがちです。最もリスクの高い問題に集中する、という脆弱性管理が持つ本来の価値が、大量のノイズによって損なわれてしまいます。

従来のバージョン照合型スキャンにおける根本的な問題は、ツールの品質にあるのではありません。バックポートが常態であるエコシステムにおいて、全く信頼性のない指標、すなわち「バージョン番号」に依存しているという、その仕組み自体に問題があるのです。

OpenResty XRay のアプローチ：バイナリ内部から真実を読む

OpenResty XRay は、信頼性に欠けるバージョン番号に依存する方法を根本から覆します。スキャン対象はパッケージマネージャーのメタデータではなく、実行中のプロセスそのものです。

「バイナリ・エビデンス」は、OpenResty XRay の脆弱性スキャンにおける中核的な概念です。OpenResty XRay は、特定のCVEが現在のシステムに影響を及ぼすかどうかを評価する際、コンポーネントのバージョン情報を参照するわけではありません。その代わりに、実行中のプロセスによってロードされたライブラリファイルを直接検査し、当該CVEに対応するパッチのシグネチャがプロセス内に実際に存在するかどうかを検証します。

要するに、バージョン番号の記述内容ではなく、バイナリコード内に脆弱性パッチが実際に存在するかどうかのみを確認する、ということです。

このアプローチは、バックポートされたパッチが適用されているシナリオにも本質的に対応しています。ディストリビューションによるパッチの適用方法、つまりバージョン番号の変更や changelog の記述の有無に関わらず、バイナリコードに修正が含まれていさえすれば、OpenResty XRay は当該 CVE を「修正済み」として扱います。逆に、修正が含まれていない場合は、脆弱性が依然として存在することを正確に報告します。

ランタイムスキャンと静的ファイルシステムスキャンの比較

OpenResty XRay のスキャンはランタイムでの動的トレースを基盤としています。この点において、従来の静的スキャンツールとはスキャン対象範囲（カバレッジ）の点で本質的な違いが生まれます。

観点	従来の静的スキャン	OpenResty XRay ランタイムスキャン
スキャン対象	ファイルシステム上のパッケージとファイル	実行中のプロセスと、それがロードした依存ライブラリ
脆弱性判定基準	バージョン番号と CVE データベースとの照合	バイナリコード内のパッチシグネチャ検証
バックポート検知	不可、誤検知が発生	可能、実際の修正状態を正確に反映
自前コンパイル/サードパーティ製コンポーネント	パッケージマネージャーに依存するため、スキャン対象外となる死角が存在	ソースを問わず、実行中であればスキャン可能

特筆すべき点として、ランタイムスキャンは、OpenResty XRay のスキャン対象が、現在実行中のプロセスと、そのプロセスがロードした依存ライブラリに厳密に限定されることを意味します。起動していないサービスやロードされていないライブラリは、スキャンの対象外となります。この特性は実際の運用における重要な考慮事項です。すなわち、完全なスキャン結果を得るためには、スキャン実行時にターゲットサービスが稼働している状態を確保することが前提条件となります。

スキャン対象範囲

現在、OpenResty XRay は、以下の主要な依存ライブラリに対する脆弱性スキャンをサポートしています。

カテゴリ	コンポーネント
コア暗号化ライブラリ	OpenSSL、LibreSSL
圧縮ライブラリ	zlib、bzip2
システム基盤ライブラリ	glibc、musl
その他の主要な依存ライブラリ	libcurl、libxml2、pcre2

サポート対象は継続的に拡大しています。特定の依存ライブラリへの対応状況については、OpenResty.Inc チームまでお問い合わせください。

混在環境（Rocky Linux + OpenSSL 二重バージョン）での検証

以下のデモは、Rocky Linux の本番環境で実施します。この環境では、次の 2 系統の OpenSSL が同時に稼働しています。

OS 標準提供の OpenSSL 3.5.1（ディストリビューションによるバックポートパッチ適用済み）
OpenResty Plus が独自にコンパイルし同梱している OpenSSL 1.1.1w

このような構成は、実際の本番環境では極めて一般的ですが、同時に、従来のスキャンツールが最も判断を誤りやすい典型的なシナリオでもあります。

対象環境について

オペレーティングシステム：Rocky Linux
システムの OpenSSL：
  /usr/lib64/libcrypto.so.3.5.1
  /usr/lib64/libssl.so.3.5.1
  （提供元：システムのパッケージマネージャー、ディストリビューションによるバックポートパッチ適用済み）

独自にコンパイルした OpenSSL：
  /usr/local/openresty-plus/openssl111/lib/libcrypto.so.1.1
  /usr/local/openresty-plus/openssl111/lib/libssl.so.1.1
  （提供元：OpenResty Plus 同梱のビルド、バージョン 1.1.1w）

その他のシステムライブラリ：
  /usr/lib64/libpcre2-8.so.0.11.0
  （提供元：システムのパッケージマネージャー）

スキャン結果概要の解説

OpenResty XRay による脆弱性スキャンの具体的な実行コマンドについては、製品ドキュメントをご参照ください。以下に、スキャン実行後の出力結果を示します。

OpenResty XRay は、システムで実行中のすべてのプロセスを自動的に検出し、各プロセスがロードしている依存ライブラリを列挙した上で、サポート対象のコンポーネントごとにバイナリレベルでの検証を実行します。この一連のプロセスにおいて、手動によるスキャンパスの指定や、パッケージマネージャーのデータベースへの依存は一切不要です。

スキャンが完了すると、OpenResty XRay はコンポーネント単位で結果を出力します。各レコードには、ライブラリのファイルパス、CVE 番号、脆弱性のステータスが含まれます。

ステータスは、次のように色分けして表示されます。

🟢 緑の背景：当該 CVE はパッチにより修正済み（Patched）——バイナリレベルの検証で、パッチの特徴が確認された状態です。
🔵 青の背景：当該 CVE に脆弱性が存在（Vulnerable）——バイナリレベルの検証で、パッチの特徴が確認できなかった状態です。

以下に、今回のスキャンにおける代表的な結果を示します。

システムの OpenSSL 3.5.1（ディストリビューション提供パッケージ）

ライブラリファイル：/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

クロス検証：ディストリビューションの changelog との照合

OpenResty XRay のスキャン結果は信頼できるのでしょうか。本稿では、ディストリビューション自身の changelog と直接照合することで、その信頼性を検証します。

システムの OpenSSL パッケージで、以下のコマンドを実行します。

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

出力は次のようになります。

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

changelog に記載されている全ての CVE は、OpenResty XRay のスキャン結果においてすべて「パッチ適用済み（Patched）」として表示されており、両者の記録は完全に一致しています。

いずれかの脆弱性をクリックすると、その詳細情報を確認できます。

唯一「脆弱性あり（Vulnerable）」と表示された CVE-2026-2673 は、changelog においても対応する修正記録が見つかりません。これは、当該脆弱性の重要度が低いとディストリビューションの保守チームに判断され、バックポートが一時的に見送られたためです。OpenResty XRay はこの現状を忠実に反映しています。バージョン番号が最新であることを理由に「修正済み」と誤検知することはなく、ディストリビューション側が未対応であることを理由にこの脆弱性を見逃すこともありません。

これこそが、バイナリの証拠に基づく検証の価値です。スキャン結果がディストリビューションの実際のパッチ適用状況と厳密に一致し、誤検知（過剰な報告）も検知漏れ（過小な報告）も発生させません。

精度と運用コストのトレードオフ：導入判断のためのチェックリスト

不可視のリスクは、最も管理が困難なリスクです。OpenResty XRay は、こうした本来可視化されていなかった依存関係を脆弱性スキャンの一元的なビューに統合します。これこそが、パッケージマネージャーが提供する情報に加えた、中核的な付加価値なのです。

脆弱性管理の本質とは、レポートを生成することではなく、エンジニアリングチームが継続して信頼し、利用し続けられるシグナルの仕組みを構築することにあります。誤検知率の高いツールは、組織に「アラート疲れ」を常態化させてしまいます。すべてのアラートに対して人手による再確認が必要になると、対応速度は低下し、プロセスは形骸化します。そして、本当に危険度の高いリスクがノイズに埋もれ、かえって対処が遅れてしまうのです。

OpenResty XRay は、バイナリの証拠に基づく検証の仕組みにより、バックポートに起因する構造的な誤検知を根本から排除します。その結果、すべての脆弱性アラートがバイナリレベルで実際に存在するリスクと紐づくため、アラートの真偽を判断するための一次的な切り分け作業が不要になります。

同時に、OpenResty XRay が提供するのは、「システムに何がインストールされているか」を示すパッケージマネージャーのビューではなく、「システムで今何が実行されているか」を示すランタイムのビューです。例えば、既知の脆弱性を持つ EOL（サポート終了）コンポーネント（例：OpenSSL 1.1.1w）が本番トラフィックを処理しているにも関わらず、静的スキャンツールからは一切検知できないケースを考えます。このビューの違いが、実際のアタックサーフェスを保護対象に含められるかどうかを直接左右するのです。正確なスキャン結果は、脆弱性管理を一過性のタスクから、持続可能なセキュリティ運用体制へと進化させるための大前提となります。

OpenResty XRay の試用をすぐに申請する

OpenResty XRay について

OpenResty XRay は動的トレーシング製品であり、実行中のアプリケーションを自動的に分析して、パフォーマンスの問題、動作の問題、セキュリティの脆弱性を解決し、実行可能な提案を提供いたします。基盤となる実装において、OpenResty XRay は弊社の Y 言語によって駆動され、Stap+、eBPF+、GDB、ODB など、様々な環境下で複数の異なるランタイムをサポートしております。

著者について

章亦春（Zhang Yichun）は、オープンソースの OpenResty^® プロジェクトの創始者であり、OpenResty Inc. の CEO および創業者です。

章亦春（GitHub ID: agentzh）は中国江蘇省生まれで、現在は米国ベイエリアに在住しております。彼は中国における初期のオープンソース技術と文化の提唱者およびリーダーの一人であり、Cloudflare、Yahoo!、Alibaba など、国際的に有名なハイテク企業に勤務した経験があります。「エッジコンピューティング」、「動的トレーシング」、「機械プログラミング」の先駆者であり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を持っております。世界中で 4000 万以上のドメイン名を持つユーザーを抱えるオープンソースプロジェクトのリーダーとして、彼は OpenResty^® オープンソースプロジェクトをベースに、米国シリコンバレーの中心部にハイテク企業 OpenResty Inc. を設立いたしました。同社の主力製品である OpenResty XRay 動的トレーシング技術を利用した非侵襲的な障害分析および排除ツール）と OpenResty XRay（マイクロサービスおよび分散トラフィックに最適化された多機能ゲートウェイソフトウェア）は、世界中の多くの上場企業および大企業から高い評価を得ております。OpenResty 以外にも、章亦春は Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、複数のオープンソースプロジェクトに累計 100 万行以上のコードを寄与し、60 以上のオープンソースソフトウェアライブラリを執筆しております。