限られたセキュリティリソースで成果を最大化する「選択と集中」 — 出前館の脆弱性対応とAI活用

はじめに

こんにちは。株式会社出前館でセキュリティエンジニアをしている白取です。

2026年8月18日に開催されたFindy株式会社主催の「事例から学ぶ！少数精鋭チームのセキュリティ防衛術～組織フェーズでみる取捨選択～」にて、「現実的なセキュリティ体制の構築 — 限られたリソースで成果を最大化する『選択と集中』」というテーマで登壇しました。

本登壇では、少人数のセキュリティ体制において限られたリソースをどこに集中させるかを軸に、脅威インテリジェンスの設計・運用、リスクベースの脆弱性管理、CTEM（継続的脅威エクスポージャー管理）を活用した各運用の連携について紹介しました。

本記事では、登壇内容を簡単に振り返ったうえで、当日の質疑で特に関心が集まった脆弱性対応の優先順位付けとAI活用について、スライドで十分に説明できなかった内容を補足します。

登壇資料は以下からご覧いただけます。

現実的なセキュリティ体制の構築 — 限られたリソースで成果を最大化する「選択と集中」

出前館でのセキュリティ設計まとめ

登壇では、少人数でセキュリティ運用を継続するために重視している設計を以下の4点に整理して紹介しました。

スコープの明確化：Tacticalインテリジェンスの対象を深刻な脅威に限定し、リスク受容基準を明文化することで、リソースを最大限活用する基盤を整備
対応基準の標準化：閾値と例外条件を定義し、共通基準に基づいて判断することで、判断の高速化・属人化の排除
緊急対応対象の限定：CVSSだけでなく、実際の悪用状況、攻撃経路、資産の重要度を組み合わせ、緊急対応が必要な対象をリスクベースで管理
運用間の連携強化：CTEMを活用し、優先度の高い脅威・脆弱性をSOC・ASMなどの各運用や担当部署の対応・改善につなげ、限られたリソースで成果を最大化

これらに共通するのは、すべての脅威を一律に扱うのではなく、あらかじめ判断基準を定義し、優先度の高い対象へリソースを集中させるという考え方です。限られたリソースでも必要なセキュリティ対応を継続するため、この考え方を各運用に反映しています。

当日の質疑では、優先度をどのように決めているのか、AIをどこで活用しているのかという質問が寄せられました。次のセクションでは、この2点を掘り下げます。

質問の多かった内容を深掘り

優先順位を決める実務フロー

この方針に基づき、自社に影響のある脆弱性をすべて同じ優先度で扱うのではなく、脅威度、資産の重要度、攻撃経路などを組み合わせて緊急度を決めています。全体の流れは次のとおりです。

1. 脅威・脆弱性情報を収集・検知する

公開情報（OSINT）から脆弱性や脅威に関する情報を収集します。

また、手順5で継続監視している脆弱性について、EPSSの上昇やCISA KEVカタログへの追加を検知した場合にも再調査します。

2. 自社での利用有無と影響有無を確認する

対象のソフトウェアやパッケージを自社で利用しているかを確認します。資産台帳やSBOM、リポジトリ検索などを用いて利用状況を調べ、利用している場合は対象バージョンや構成を確認し、自社への影響有無を判断します。

3. 脅威度と資産の重要度から緊急度を決める

自社に影響がある場合は、AIを利用して脆弱性の概要や評価に必要な情報を整理したうえで、公式アドバイザリなどの一次情報を人が確認します。

評価では、CVSSとEPSSを用いて脅威度を確認し、KEVへの掲載有無やあらかじめ定めた例外条件を加味します。さらに、対象資産の重要度や攻撃経路を組み合わせ、緊急度を「緊急・高・中・低」に分類します。CVSS単独ではなく、実際の悪用状況と自社への影響を加味して判断する点がポイントです。

また、ネットワーク経由かつ認証不要で悪用でき、システムやデータに重大な影響を及ぼし、SSVCでImmediate（緊急）と判定される脆弱性は通常フローから切り分けています。該当する場合はプロダクト側と連携して影響範囲を特定し、修正・緩和を進める専用フローへ移行します。

4. 緊急度に応じて対応方針を分ける

「緊急」または「高」と判定した場合は、対応内容を決め、タスクを起票して担当部署へ修正または緩和策の実施を依頼します。必要に応じて、関係者へ情報を共有します。

※リスク受容と判断した場合も、評価結果を記録します。

5. リスク受容後も継続して監視する

出前館では、評価時点でリスク受容と判断した脆弱性についても悪用可能性の変化を継続的に監視しています。対象の脆弱性は一覧で管理し、EPSSの上昇やKEVへの追加を検知した場合は再評価し、必要に応じて修正対応のフローへ移行します。

この監視には再現性が必要なため、生成AIではなく、プログラムによる自動化処理を利用しています。

6. 月次で運用状況を振り返る

月次報告では、脆弱性の検知、情報加工・分析、対応完了の各工程を定めた期限内に実施できたかを確認しています。また、収集した情報がSOCの検知改善や脅威トレンドの把握などのプロアクティブな活動につながったかも記録します。

このように、優先順位付けを一度きりの判定で終わらせず、記録・監視・再評価までを一連の運用として設計することで、限られたリソースを優先度の高い脅威へ集中させています。

AI活用の具体例

登壇では、AI活用度が高いフェーズ（◎）として、Discovery（検出）とPrioritization（優先順位付け）を挙げました。大量の情報を収集・整理するDiscoveryと複数の判断材料を組み合わせるPrioritizationは、AIと特に相性が良いためです。

また、Validation（検証）は「○」とし、SOC検知ルールの作成に必要なPoC／IoC情報の収集に活用しています。

以下では、Discovery／Prioritization／Validationにおける具体的な活用例を1つずつ紹介します。

Discovery：ASMのOSINT調査プログラムを開発

ASMツールだけでは網羅しきれないOSINT情報をプロアクティブに収集するため、AIを利用し、Attack Surface（攻撃面）の探索、生存確認、露出リスクの一次判定を行うプログラムとテストケースを作成しました。

新たに発見した攻撃面は人が対象範囲、判定条件、誤判定の有無を確認したうえで、ASM運用による監視対象に組み込んでいます。

Prioritization：緊急度の初期評価を作成

脆弱性の優先順位付けではAIを利用し、CVSS・EPSS・KEV、資産管理台帳やアーキテクチャ図などの情報を基に緊急度の初期評価を作成します。リスク受容基準や閾値を明確に定義することで、AIが一貫した基準で初期評価を行いやすくなります。

ただし、AIが提示する緊急度は暫定として扱うため、参照した情報源と判断根拠を必ず提示させるようAIの設計をしています。AIの出力と公式アドバイザリの整合性、自社への影響などを人が確認し、最終的な緊急度、リスク受容の可否、対応期限を決定します。

Validation：PoCを評価し、IoCや悪用条件を収集

優先順位付けの結果、監視強化が必要と判断した脅威に対してAIを利用し、アドバイザリやPoCから悪用条件、IoC、ログで観測できる可能性のある情報を収集します。整理した情報をMobilizationへ引き継ぎ、リクエストの特徴、プロセスの挙動、通信先などを捉えるSOC検知ルールの作成につなげます。

ここでも、必要なログが取得できているか、クエリの構文が正しいか、正常な挙動を過剰に検知しないかを人が確認します。既存ログや検証環境で有効性を確かめたうえで実装します。

AIに任せる範囲と人が責任を持つ範囲

AIに任せること	人が確認・判断すること
公開情報の収集・要約、評価材料の構造化	一次情報によるファクトチェック
影響確認に使う検索条件やコマンドの作成	自社での利用・露出・影響の確定
緊急度の初期評価と判断根拠の整理	例外条件の適用、最終的な緊急度とリスク受容の決定
SOC検知ルール作成時に必要なIoC・悪用条件の整理	ログでの観測可否、クエリの構文確定、実環境での有効性の検証