リスクベースの脆弱性優先順位付けとは、セキュリティ上の発見事項を、それに付与された深刻度スコアではなく、アプリケーションに実際に及ぼすリスクに基づいてランク付けすることです。この区別が重要なのは、深刻度は抽象的な脆弱性の特性であるのに対し、リスクはコード内の脆弱性の特性、つまり脆弱な関数が実際に呼び出されるかどうか、実際に悪用されているかどうか、影響を受けるサービスがどの程度露出しているか、修正がどの程度困難かといった点に関わるからです。アプリケーションが一度も呼び出さない依存関係のCVSSスコア9.8は、インターネットに接続されたエンドポイントの6.1（公開されている脆弱性）よりも優先度が低くなります。深刻度だけでは、このようなことは分かりません。リスクベースの優先順位付けは、こうしたことを判断する指標となるものです。
リスクベースの脆弱性優先順位付けとは何か？ 作業定義 #
スキャナーを実行するたびに、チームが対応できる以上の問題が見つかる。これはツールの不具合ではなく、計算の問題だ。検査範囲は毎年拡大しているのに、人員は増えていない。もはや「何が見つかったか」という問いは時代遅れだ。今は「月曜日に何をすべきか」が問われている。
重症度に基づくトリアージは、この問題にうまく対処できません。システムに関する知識を一切持たずに計算された数値に基づいて分類するため、理論上の大惨事を実際の大惨事よりも上位にランク付けしてしまうのです。チームはすぐにこのことに気づき、リストを無視するようになりますが、これは最悪の結果です。なぜなら、本当に重要な3つの発見事項がそのリストに含まれていたからです。
つまり、作業上の定義は次のとおりです。 リスクベースの脆弱性優先順位付けとは、悪用可能性、到達可能性、露出度、修復コストに関する状況的シグナルを用いて発見事項を順序付ける手法であり、優先順位の上位には、評価機関が一般的に可能と判断したことではなく、攻撃者が実際にこのシステムに対して実行できることが反映されるようにする。
脆弱性の特性が変わることで、脆弱性の特性に加えてアプリケーションの特性も考慮されるようになります。同じCVEでも、それがどこに存在するかによって優先度が異なります。
リスクベースの脆弱性優先順位付けの意味、4つのシグナル #
リスクベースの脆弱性優先順位付けの意味を最も明確に理解するには、深刻度に何が追加されるかを見るのが良いでしょう。なぜなら、深刻度自体は消えるわけではなく、複数の入力項目のうちの1つになるからです。
- 到達可能性. 脆弱な関数は実際にあなたのコードから呼び出されていますか？脆弱なパッケージは脆弱なアプリケーションではありません。到達可能性分析は呼び出しパスを追跡して表示するため、「400件の重大な依存関係が見つかりました」という報告を、実際に実行される依存関係のより短いリストに変換できます。
- 悪用可能性. 現実世界でこれを悪用している人はいるのだろうか？ EPSS 今後30日間の搾取の確率を推定します。 CIS既知の悪用された脆弱性のカタログ は既に実環境で使用されているものを記録し、公開されているエクスプロイトの入手可能性は攻撃者がどれだけの作業を行う必要があるかを示します。これらは攻撃者の視点であり、日々変化します。 CVSS 点数は割り当てられた日から変更されません。
- ビジネス環境。 影響を受ける資産はどの程度リスクにさらされており、どのような機能を持っているのでしょうか？インターネットに接続された決済サービスと、同じ検出結果を示す社内報告ツールでは、リスクは異なります。どちらがどちらであるかは、貴社組織のみが把握しています。
- 修復費用。 修正はどれくらい難しいのか、そして適用すると何が壊れるのか？些細なパッチの更新とコンパイルを壊すようなメジャーバージョンのアップグレードでは、意味が異なる。cisイオン、そして努力を無視した優先順位は、誰もスプリントを計画できないキューを生み出す。
総合すると、リスクベースの脆弱性優先順位付けは、ほとんどのチームが以下の点に収束することを意味します。 事態がどれほど悪化する可能性があるかを問うのはやめて、現状がどれほど深刻なのか、そしてそれを終わらせるのにどれだけの費用がかかるのかを問い始めなさい。
重症度ベースとリスクベース：何が変わるのか #
リスクベースモデルにおいても、深刻度は消滅するわけではありません。深刻度は複数の入力要素の一つとなり、他の入力要素はアプリケーションに関する情報を提供するものとなります。
| 次元 | 重症度に基づく | リスクベース |
|---|---|---|
| プライマリーシグナル | CVSSスコア | 到達可能性、活用可能性、露出、固定コスト |
| 質問に答える | この脆弱性は全体的に見てどの程度深刻なのでしょうか？ | 攻撃者はこのシステムに対してどのようなことができるのか？ |
| 文脈が使用される | なし | あなたのコード、あなたのデプロイメント、あなたのビジネス |
| 典型的な出力 | 番号順に並べられた長いリスト | 結果順に並べた短いリスト |
| 開発者への影響 | アラート疲労、リストが無視される | チケット枚数は減ったが、それぞれに正当な理由がある |
| 欠けているもの | コードが実行されるかどうか | 信号が正しく配線されていれば、何も問題ありません。 |
実際の違いは、セキュリティ部門とエンジニアリング部門の間のやり取りに表れます。重要度順に並べられたチケットは「これは重大な問題なので修正してください」と伝えます。一方、リスク順に並べられたチケットは「これはチェックアウトコントローラーからアクセス可能で、公開されている脆弱性があり、修正方法はパッチの更新です」と伝えます。議論なしに実行されるのは、このうちの1つだけです。
これはもはや単なる良い慣行ではなく、公式見解である。 #
リスクに基づいた脆弱性の優先順位付けは、かつては深刻度によるパッチ適用に代わる高度な手法だった。しかし、今やそれが標準的な手法になりつつある。
SSVCカーネギーメロン大学ソフトウェアエンジニアリング研究所によって開発され、 CISAは、スコアをdeに置き換えますcis活用状況、自動化可能性、技術的影響、ミッション普及率に基づいて、数値ではなくアクションを出力するイオンツリー。そして2026年6月 CIS発行された 拘束力のある運用指令26-04これは、連邦機関に対し、深刻度だけでなく、資産への露出、KEVステータス、エクスプロイトの自動化、技術的影響に基づいて更新の優先順位付けを行うよう指示するBOD 22-01に取って代わるものです。
他の機関へのメッセージは明白です。悪用された脆弱性の公式カタログを管理する機関は、もはや傘下の機関に対し、CVSSスコアで分類するよう指示していません。もしあなたがまだそのように分類しているとしたら、それはその機関の管理者自身が既に廃止した方法を使っていることになります。
優先順位付けファネルはどのように機能するのでしょうか？ #
信号はそれ自体では何も優先順位付けしません。信号は連鎖して、それぞれの信号が次の信号が考慮すべき事項を絞り込む必要があります。その連鎖が ザイゲニ 優先順位付けファネルと呼ぶ。
ファネルは、最大 8 つの順序付けられたステージを通して検出結果を処理し、到達可能性、悪用可能性、修正可能性、AI トリアージ結果、および修復の緊急度といった事前設定済みのステージに加え、ビジネス上の重要度や露出度などの独自のプロパティを追加できます。すぐに使用できるファネルは、各リスクファミリーを網羅しており、ファネルのフェーズごとにテーブルをフィルタリングして、各ステージを通過した項目を確認できます。数百件の検出結果がキューに表示され、実際に発生し、到達可能で、悪用可能で、今回のスプリントで対処する価値のある少数の検出結果に絞り込まれます。
これらのステージのうち2つは AIトリアージ独自のコード内の検出結果については、AI Triage はコンテキスト内の検出結果、静的分析の場合はコード フロー、DAST の場合は HTTP 証拠を読み取り、真陽性、偽陽性、またはレビューが必要という判定、さらに即時からバックログまでの修正の緊急度、および簡単から難しいまでの修正の複雑さを返します。それぞれに根拠が示され、すべての出力には AI 生成とラベル付けされ、チームはどの判定結果も上書きできます。オープンソースの検出結果については、設計が意図的に異なります。AI 判定はありません。 到達可能性 AIは、その仕事をより効率的にこなします。AIトリアージは、むしろ緊急性と複雑さを増大させます。
既存のシステムスタックを使用しているチームにとって最も重要な点は、Xygeni独自のシステムだけでなく、他のスキャナーから取り込まれた検出結果にも同じファネルとトリアージが適用されることです。SARIF出力を含む40種類以上のツールとフォーマットからの検出結果は、重複排除され、同じキューでランク付けされます。現在使用しているツールは引き続き稼働します。優先順位付けはツールごとに行われることはなくなります。
測定可能な効果は、 それを行った顧客Banco Serfinanzaでは、継続的に分析されている100以上のリポジトリ全体で、セキュリティ上の発見事項の特定、優先順位付け、割り当てにかかる時間が約90%短縮され、Fintonicでは脆弱性の優先順位付けにかかる時間が90%短縮されました。
デモを予約する そして、各自の未処理の作業を持ち込んでください。
FAQ：リスクベースの脆弱性優先順位付けに関する簡単な回答 #
セキュリティ上の発見事項を、脆弱性に付与された深刻度スコアではなく、攻撃者が実際にシステムに対して何ができるかという基準で分類します。同じCVEでも、アプリケーションによっては緊急性の高いものもあれば、そうでないものもあり得ます。リスクに基づいた優先順位付けこそが、この2つの違いを明確にする鍵となります。
いいえ、それは不完全です。CVSSは脆弱性を記述するものであり、脆弱性への曝露度を記述するために設計されたものではありません。リスクベースの優先順位付けでは、深刻度を一つの指標として残しつつ、環境に応じて変化する指標（コードへのアクセス可能性、悪用の発生状況、資産の曝露度、修正コストなど）を追加します。
依存関係内の脆弱な関数が、実際にアプリケーションによって呼び出されているかどうかを確認します。呼び出されていない場合、脆弱性は存在しますが、コードを通じて悪用することはできないため、検出対象から除外され、消えることはありません。これは、オープンソースの脆弱性検出において最も影響力の大きいフィルターです。なぜなら、ほとんどの依存関係の脆弱性は、決して呼び出されないコード内に存在するからです。
そうあるべきであり、これはこの機能を謳うプラットフォームに適用する価値のあるテストです。独自の検出結果のみをランク付けする優先順位付けでは、ランク付けされたキューが1つと、ランク付けされていないキューが複数残るだけで、これは優先順位付けとは言えません。Xygeniは、他のツールから取り込まれた検出結果に対しても、同じファネルとAIトリアージを適用します。
未解決の重大な問題の数ではなく、問題が報告されてから対応可能な開発者に届くまでの時間、割り当てられた問題のうち修正される割合（延期されるのではなく）、そして開発者が対応を拒むチケットの数を測定してください。リスクベースの優先順位付けが機能しているかどうかは、対応の拒絶がなくなったときに判断できます。
