Exploitの実現性 #

脆弱性が存在しても、攻撃を実行できる人の数やスキルによって、その危険度は変わることがあります。

対象システムへのアクセス #

CVSSの攻撃元区分（AV: Attack Vector）は、脆弱性がどのような経路で攻撃可能かを評価しており、「ネットワーク」「隣接」「ローカル」「物理」といった選択肢があります。
物理アクセスが必要な脆弱性でも、自動販売機のように誰でもアクセス可能な場所にあるシステムと、防犯ゲートで厳重に守られたデータセンターの奥に設置されたシステムでは、攻撃の実現性が大きく異なります。
正当な権限を持った人による内部犯行を脅威として想定するかによっても異なります。

複数の脆弱性の組み合わせ #

Webアプリケーションでログイン時にセッションIDを変更しない場合、セッションフィクセイション脆弱性が報告されることがあります。しかし、この挙動だけで即座に被害が発生するわけではありません。攻撃者が指定したセッションIDを、何らかの手段で被害者に強制的に使用させる別の脆弱性が必要です。
例えば、セッションアダプション、クッキーモンスター、クロスサイトスクリプティングなどが該当します。これらの脆弱性が適切に対応されている場合、危険度は低くなるでしょう。

Exploitの開発難易度 #

例えばSQLインジェクション脆弱性で、'and'A'='Aといったチートシートに載っている簡単なパターンや、脆弱性診断ツールで使用される典型的な攻撃パターンが成功する脆弱性が報告された場合、技術レベルの低い攻撃者でも攻撃可能である可能性が高いといえます。
一方で、使える文字が限られていたり、WAFが設置されているなどで、それらの制限を回避する必要がある場合、それを行える高度な技術を持った攻撃者のみが脅威となります。対象となるサーバーソフトウェアやブラウザOSなどに対する深い知識が必要な場合も同様です。

攻撃の難易度の判断 #

攻撃難易度を判断するためには、脆弱性や攻撃手法に対する専門的な知識が必要です。
まずは脆弱性診断の報告書などを確認し、実害につながることが実証されているか、PoC(Proof of Concept: 概念実証)が記載されているかどうかを確認してください。
PoCが示されていない場合や、脆弱性の可能性のみが示唆されていて現実的な被害に結びつくか不明な場合には、自身でExploitを作成してみる必要があるかもしれません。
診断ベンダーによっては、実際の攻撃の可否までは検証せず、不正な挙動を見つけたという段階で報告してくる場合があります（被害につながるかわからないけれどもとりあえずすべて修正するつもりであれば、この報告方針の方が有用です）。

なお、脅威が小さいと判断した場合でも油断は禁物です。Exploitの流通状況で述べたように、ExploitやPoC、前提情報が公開されてしまった瞬間に状況は一変します。
Exploitの難易度は、脆弱性が発覚し、Exploitが公開されないことを祈っている初期段階での判断基準として利用するにとどめ、長期的な判断基準として利用することは避けた方が良いでしょう。