脆弱性管理の現場では「ツールを入れてスキャンを回す」だけでは、見逃し（false negative）と過検知（false positive）の両方が残り、修正優先度の判断や開発チームの工数を圧迫します。韓国メディアの報道によれば、セキュリティ企業Depthfirstは、Mythosが見逃した脆弱性を発見し、しかも検出に要するコストは従来の10分の1水準だと主張しています。これは単なる“性能自慢”ではなく、脆弱性発見のアプローチが転換期にあることを示唆します。
脆弱性スキャンが抱える「見逃し」の構造
一般的な脆弱性検出は、シグネチャ（既知パターン）やルール（静的解析の規則）をベースにしたものが多く、未知の組み合わせや複雑な条件分岐、環境依存の挙動に弱い傾向があります。さらに、近年のアプリケーションはマイクロサービス化、IaC（Infrastructure as Code）、サードパーティ依存の増大、CI/CD高速化により、攻撃面（attack surface）が継続的に変化します。結果として、ツールが「ある前提で安全」と判断した箇所が、実運用の設定・権限・データフローによっては脆弱になり得ます。
見逃しが起きやすい領域としては、たとえば以下が挙げられます。
- 認可（Authorization）の欠陥（IDOR、水平/垂直権限逸脱）
- ビジネスロジックの不備（手順や状態遷移の抜け）
- 設定不備とコードの相互作用（ヘッダ設定、CORS、クラウドIAM）
- 複数サービスを跨いだデータフロー（API連携、キュー、Webhook）
これらは“単体の脆弱性”としてシグネチャ化しづらく、検出には文脈理解が必要になります。
Depthfirstの「10分の1コスト」が意味するもの
報道が示す「コストが10分の1」という表現は、単純にスキャン費用が安いというより、同等以上の発見精度をより少ない計算資源・時間・人手で実現したことを示す可能性があります。脆弱性発見におけるコストは、大きく次の要素に分解できます。
- 計算コスト（スキャン時間、クラウド実行費）
- 運用コスト（設定・チューニング、継続運用）
- トリアージコスト（過検知の精査、再現確認）
- 修正コスト（開発対応、影響調査、リリース調整）
特に現場で効くのは、過検知を減らしてトリアージを短縮する、あるいは“実際に悪用可能な経路”に絞って提示し修正の意思決定を速める、といった方向です。もしDepthfirstがMythosの見逃しを拾えたのであれば、検出ロジックがより攻撃者視点に近い、もしくはアプリ/環境の文脈を加味した評価が可能であることが考えられます。
なぜ同じ対象でもツールで差が出るのか
同一システムに対しても、検出結果が異なるのは珍しくありません。主因は以下です。
- 観測点の違い：ソースコード中心（SAST）か、実行時中心（DAST）か、依存関係中心（SCA）か
- 文脈の取り込み：設定、権限、API仕様、認証フローなどをどこまでモデル化するか
- 探索戦略の差：入力生成（ファジング）、経路探索、状態遷移の扱い
- 判定の厳密さ：再現性・悪用可能性を証明してから出すか、疑い段階で出すか
特にクラウドネイティブ環境では、アプリのコードが安全でもIAMやネットワーク境界、シークレット管理、メタデータアクセスなど周辺条件で攻撃が成立します。検出の優劣は「どれだけ現実の攻撃経路を再現できるか」で決まりやすくなっています。
脆弱性管理のKPIを「件数」から「リスク削減」に変える
多くの組織でありがちな失敗は、脆弱性件数をKPI化してしまい、現場が“数を減らすゲーム”に追われることです。見逃しを防ぐには、件数よりも次の指標に寄せるべきです。
- インターネット露出資産に対する重大リスクの平均修正時間（MTTR）
- 悪用可能性（Exploitability）を加味した優先度での対応率
- リリース前にブロックできた重大欠陥の割合（Shift Leftの実効性）
- 過検知率とトリアージ時間（開発生産性への影響）
Depthfirstのように「安く速く、見逃しを減らす」方向は、ツール比較を“検出件数”ではなく“リスク削減効率”で評価する流れを後押しします。
実務で取るべき対策：単一ツール依存を避ける
今回のように、あるベンダーが見逃した脆弱性を別のプレイヤーが発見する事例は、単一の診断手段に依存する危うさを示しています。現実的な落としどころは「多層化」と「重点化」の両立です。
検出手段をレイヤーで分ける
- SAST：早期に混入を減らす（ただし見逃しと過検知の管理が必要）
- DAST：実挙動ベースで取りこぼしを拾う（認証/状態遷移が課題）
- SCA：依存関係リスクを継続監視（到達可能性評価が重要）
- 手動診断/レッドチーム：論理欠陥や複合経路を狙う
攻撃面が大きい領域を重点化する
- 公開API、認証・認可、決済・個人情報など高価値データ周辺
- 権限境界（管理画面、内部API、メタデータサービス）
- 設定変更が頻繁な領域（クラウドIAM、WAF/ヘッダ、CORS）
ツール選定のチェックポイント
「10分の1コスト」のような主張を評価するには、価格表よりもPoC（概念実証）の設計が重要です。次の観点で比較すると、実運用に近い判断ができます。
- 再現性：検出した脆弱性を具体的な手順で説明できるか
- 悪用可能性の提示：どの前提条件で成立するか（権限、到達性、設定）
- CI/CD統合：差分スキャン、ゲート設定、例外管理ができるか
- トリアージ支援：重複排除、原因箇所の特定、修正案の提示
- 運用負荷：チューニングの頻度、誤検知対応の工数、学習コスト
特に「見逃しの少なさ」を検証するには、既知の脆弱性セットだけでなく、実システムに近い状態遷移・権限差・設定差を含めたテストが欠かせません。
まとめ：脆弱性発見は“精度×運用”の勝負へ
DepthfirstがMythosの見逃しを突き、低コストを掲げたというニュースは、脆弱性管理が「スキャンを回す作業」から「攻撃者視点で実害に直結する欠陥を、継続的に安く潰す運用」へ移行していることを示します。組織としては、単一ツールへの過信を避け、検出手段の多層化と、リスク削減効率を軸にしたKPI・PoC設計へ舵を切るべきです。見逃しを前提にしたプロセス設計こそが、最終的にインシデント確率と対応コストを下げます。