脆弱性診断は内製か委託か｜二択で決める前に整理すべき「6つの工程」

商談の途中で顧客からセキュリティチェックシートを渡され、「定期的に脆弱性診断を実施していますか」という一行で手が止まる。SaaSを提供する企業から、この場面をきっかけに社内体制を見直したい、という相談が届きます。

検討はたいてい「診断ツールを入れて自社でやるか、診断会社に外注するか」の二択で始まります。ただ、この立て方のまま進めると判断を誤りやすくなります。内製と委託は排他的な選択肢ではなく、工程ごとにどちらが担うかを決める配分の問題だからです。

脆弱性診断を一つの作業だと捉えていると、「ツールを入れれば内製できる」という結論になります。実際の運用は、少なくとも次の6つの工程に分かれます。

並べてみると、工程は二つの見方で分けられます。

一つは範囲です。工程1〜3は、1回の診断で完結するひとまとまりです。診断を単発で行う場合も、ここまでそろえば、診断を実施し、結果と対応方針を把握していることを顧客に説明できます。工程4の修正は、その結果を受けて進める作業です。工程5・6は、修正が効いたかを確かめ、説明できる状態を保ち続けるための繰り返しの部分です。チェックシートの「定期的に」に答えるには、この繰り返しをどう回すかまで決めておく必要があります。

もう一つは担い手です。棚卸しと修正は、原則として自社にしかできません。どのシステムが事業にとって重要かを知っているのも、コードを直せるのも自社だからです。反対に実施・評価・再診断は、専門知識と経験が結果を左右するため、外部の力が効きやすい部分です。証跡化（工程3・6）は、診断した側の記録と、社外に説明する自社の言葉の両方が必要になります。

ここで効いてくるのが、ツールを導入して内製できるのは「実施」だけだという事実です。「ツールを入れたのに運用が回らない」という状態は、担当者の意欲や体制の問題ではありません。ほかの5工程が手つかずのまま残っているために起きます。

相談の中で繰り返し挙がるのが、次の3つです。

1. 誤検知の切り分けに時間を取られる

自動診断ツールは、検出漏れを避けるために広めに拾う設計になっています。出力には、自社の構成では成立しない指摘も相当数まざります。これを一件ずつ潰すには、Webアプリケーションの攻撃手法をある程度知っている必要があります。知識がないまま向き合うと、「全部対応する」か「全部放置する」の両極端に振れます。

2. 深刻度をそのまま受け取ってしまう

ツールが出す深刻度は、一般的な指標にすぎません。同じ「中」でも、ログイン前の画面にあるか、社内管理画面にあるか、決済に関わるかで、実際のリスクは変わります。この読み替えができないと優先順位が付かず、対応は「手を付けやすいものから」になります。

3. 詳しい人が抜けると、何も残らない

最初の数回を回すうちに、運用は自然と「詳しい人」に寄ります。その人が異動・退職すると、ツールのライセンスだけが残り、誰も結果を評価できなくなります。一方、最初から全部を外部に預けていた場合も、社内に判断の根拠が残らず、次に何を診断すべきかを自社で決められなくなります。

3つ目は内製と委託のどちらでも起きます。属人化は内製に固有の欠点ではなく、判断の根拠を残す仕組みがないことから生まれる問題です。

内製と委託を比べるとき、多くの場合「ツールのライセンス費用」と「診断の委託費用」が並べられます。この比較では、内製が実際より安く見えます。次の3つが内製側に上乗せされるからです。

• 学習コスト：担当者が結果を評価できるようになるまでの時間。一度きりではなく、担当が変わるたびに発生します。
• 継続運用の工数：診断の実行、誤検知の切り分け、優先順位付け、再診断の管理。リリース頻度が高いほど積み上がります。
• 説明責任にかかる時間：顧客のチェックシート、社内稟議、監査への回答を書く時間。診断を「実施した」ことと、それを「説明できる」ことは別の作業です。

委託側にも、見落とされやすい費目があります。修正は自社で行うという点です。診断を外部に任せても、多くの場合、コードを直すのは自社の開発チームです。ここを見込まずに計画を立てると、報告書は受け取ったのに修正が進まない、という事態になります。

比べるべきは「ツール費用 対 診断費用」ではなく、6工程それぞれにかかる自社の時間まで含めた総額です。

ここまでの整理は、次の4つの問いに落ちます。

問い1：診断結果を評価できる人が、社内に2人以上いるか

1人しかいないなら、それは体制ではなく個人です。現時点で「評価」を内製するのは現実的ではありません。

問い2：リリース頻度に対して、診断の周期が追いつくか

毎週リリースしているのに年1回しか診断していない場合、手元の診断結果は常に過去の状態を指しています。頻度を上げるなら、「再診断」と「証跡の更新」を繰り返し回す体制が要ります。

問い3：直近3ヶ月、導入したツールを誰かが実際に動かしたか

動いていないなら、足りていないのはツールではなく運用の担い手です。乗り換えても結果は変わりません。

問い4：診断を「実施した」ことを、社外に説明できる形で残しているか

顧客や監査に提出する場面を思い浮かべられるかどうかが、「証跡化」まで設計できているかの確認になります。

「いいえ」が多いほど、実施・評価・再診断を外部に出し、棚卸し・修正を自社に残す配分が現実的になります。証跡化は、どちらを選んでも両者でつくる工程です。

委託を決めると、次に「どこまで任せられるのか」という問いが来ます。ここを曖昧にしたまま発注すると、報告書は届くのに社内で動けません。

発注前に、少なくとも次の4点は確認してください。

• 何を基準に診断するか：たとえばOWASP Top 10を基準とする場合、どの版を指しているか。OWASP Top 10には2021年版と2025年版があり、項目の構成が異なります。生成AIアプリケーション向けの「OWASP Top 10 for LLM Applications」は、さらに別の文書です。名前が似ているぶん、認識がずれやすい部分です。
• 評価まで含まれるか：検出結果の一覧を受け取るのか、自社への影響を踏まえた対応順の提案まで受け取るのか。
• 再診断の扱い：修正後の確認が契約に含まれるか、別メニューか。1回の診断（工程1〜3）で完結するプランもあるため、継続して回す部分（工程5・6）をどう手当てするかを先に決めておきます。
• 社内への引き継ぎ：結果の解説を受けられるか。ここが「証跡化」と、次回の判断材料に直結します。

この4点は、任せる範囲の確認であると同時に、自社に残る範囲の確認でもあります。両方を書き出した時点で、内製か委託かという二択は、配分の設計に変わります。

内製と委託は、どちらかが優れているという話ではありません。判断軸を持たないまま「とりあえず内製」「とりあえず委託」で始めると、後から運用が止まったり、社内に何も残らなかったりします。選び直すコストは、最初に軸を決めるより高くつきます。

まずは、6つの工程が自社でいまどうなっているかを書き出してみてください。手が止まった工程が、外に出す候補です。

• OWASP Top 10:2021（Open Worldwide Application Security Project） https://owasp.org/Top10/2021/
• OWASP Top 10:2025（同上） https://owasp.org/Top10/2025/
• サービス：Webアプリケーション脆弱性診断
• 関連記事：ECサイトリニューアルで発覚した脆弱性―開発チームと連携した診断・改修の全記録