アプリケーションセキュリティにおいて、脆弱性が発見されるタイミングが開発工程の後ろになればなるほど、脆弱性を改修するためのコストは膨らんでしまいます。できるだけ前の工程で脆弱性を改修するためには、脆弱性診断を内製化し、セキュリティノウハウを自社で持つことが非常に有効です。
とくに近年は、CI/CDパイプラインによるリリースサイクルの短縮やDevSecOpsの広まりを背景に、外部委託だけでは診断スピードが追いつかないケースが増えており、脆弱性診断の内製化を検討する企業が増えています。
今回は「セキュリティチェックを内製化し、効率的に行っていきたい」という方向けに、脆弱性診断を内製化する際のメリットとポイント、ツール選定の考え方やコスト試算までについて解説します。
▼おすすめ!お役立ち資料【無料DL】
「何から始めればいい?」がゼロになる!セキュリティ対策スタートガイド
セキュリティ診断の内製化で、早期にリスクコントロールができる
まずはじめに、セキュリティ対策で重要なことは「脆弱性をゼロにする」ことではありません。
見つかった脆弱性を修正する、セキュリティのリスクを低下させる、リスクを理解した上で受容する―、そのように「潜在リスクを把握してリスクコントロールをしていく」ことが大切です。
内製化したほうが良いケースとしては、「全てのシステムでリスクコントロールしたいけど、コスト都合で一部のシステムしか診断できない」や、「自社のシステムリリースの頻度が高いので、スピード感をもってセキュリティチェックしなければならない」などが挙げられます。
本来ならリリースのたびにセキュリティチェックを行う必要がありますが、外注ではスピード感をもって全てのシステムを診断するのが難しく、「一定期間分をまとめて発注したら、後日の診断で脆弱性が見つかった」ということも少なくありません。しかし、セキュリティ診断を内製化していれば、必要なタイミングで早期に脆弱性を発見しリスクコントロールを行うことができるようになります。
また、DevSecOpsの考え方が広く実践されるようになった現在では、SAST(静的解析)・DAST(動的解析)・IAST(対話型解析)といった複数の手法をCI/CDパイプラインに組み込み、開発工程のなかで継続的に脆弱性を検出することが一般的になりつつあります。こうした継続的な診断運用を回すうえでも、社内に診断機能を持つ内製化は有効な選択肢になります。
外部委託診断、内製診断、それぞれのコスト構造
ここでお伝えしたいポイントは「内製化してコストを下げよう」ではなく、(もちろんコストが下がるケースも多数ありますが、各社の状況によって異なります)「外部診断サービスと内製診断のコスト構造を理解し、正しく比較しよう」ということです。

外部委託時にかかるコスト
一般的に、外部委託する際のコストは、掛け算になっているのが特徴です。外部ベンダーへの発注かかる「外部委託コスト」と、発注するベンダーを選定するために内部でかかる「調整コスト」から構成されます。
「外部委託コスト」は、〔WEBステム数〕×〔診断回数〕×〔外部ベンダーの診断費用〕という計算で大まかに算出することができます。「調整コスト」については、ベンダー選定にかかる見積もりの取得、提案が診断項目を満たしているかのチェックなどの作業も含まれます。WEBシステム数については、今診断できているシステムではなく、「本来診断すべきシステム数」で試算することをお勧めします。
内製診断にかかるコスト
内製診断は、主に診断ツールのライセンス費となる「診断環境コスト」と、実際にツールを使って運用される人件費の「運営コスト」で構成されます。
「運営コスト」には、新しいセキュリティ業務に取り組むことになる社員の方のトレーニングや、診断の実施・準備などの稼働、診断データを適切に保管するなどといった診断環境の運用なども含まれます。外部委託コストが掛け算だったのに対し、足し算で算出することができます。
コストと時間の関係

外部委託診断については、時間が経過してもコストが大きく変動することはありません。一方、内製診断の場合は時間の経過と共にノウハウが蓄積され、担当者の熟練度も上がっていきます。診断開始から終了までのスピードも速くなり、全体運営コストの低下が期待できます。
内製化の導入事例を見る
コスト構造の違いは前述のとおりですが、実際の削減効果や運用の立ち上がり方は企業の規模・対象システム数・既存の外注体制によって大きく異なります。具体的なイメージをつかむには、すでに内製化に取り組んでいる企業の事例が参考になります。
▼脆弱性診断の内製化に取り組んだ事例
Vex導入事例|QTnet様
Vex導入事例|NTTPCコミュニケーションズ様
診断内製化によって得られるメリット
内製化できていると、様々なケースにスピード感をもって柔軟に対応することができます。
例えば、社内から突然「1週間後にシステムリリースがあるのでセキュリティ診断してほしい」と依頼があったとします。1週間という限られた時間で対応可能なベンダーを選定・検討・発注するのは難しいですが、もし社内に診断チームがあれば社内調整だけで対応することができます。
また、外的要因として多いのが同業他社でセキュリティインシデントが発生した時の対応です。経営陣から「うちのシステムは大丈夫?」と確認されても社内にセキュリティチームがいるとすぐに回答できますし、必要があれば調査などを迅速に行うことができます。
さらに診断結果の分析観点でも大きなメリットがあります。調査の結果、脆弱性が見つかったら「どのような対応をするのか」判断をすることになりますが、その検討においても「世の中的には…」という一般論ではなく、独自の環境やセキュリティポリシーを踏まえたうえでリスク判断をすることができます。
加えて、診断を繰り返すなかで「自社システムでよく出る脆弱性のパターン」「効果的だった対応策」といった知見が組織内に蓄積されていく点も見逃せません。この知見は、開発者へのフィードバックやセキュアコーディングガイドラインの改善など、診断以外の場面でも活用できる資産になります。
内製化に向けた診断ツールの選び方
内製化の成否を大きく左右するのが診断ツールの選定です。高機能であれば良いというものではなく、自社の状況に合っているかが判断軸になります。選定時には、大きく以下の4つの観点から比較するとよいでしょう。
機能:何をどこまで検査できるか
OWASP Top 10をはじめとする主要な脆弱性カテゴリへの対応状況はもちろん、認証付き画面やAPI診断への対応、シナリオベースの診断ができるかどうかを確認します。
自社の診断対象(Webアプリ・API・SPAなど)と照らし合わせて過不足を見極めましょう。誤検知の多さも実務上の負荷に直結するため、PoC(概念実証)で実機確認するのが確実です。
コスト:ライセンス体系と総保有コスト
ライセンスの課金単位(サイト数課金、ユーザー数課金、スキャン回数課金など)はツールによって異なります。
前章のコスト構造を踏まえ、自社の対象システム数・診断頻度で3年程度の総保有コスト(TCO)を試算して比較することをお勧めします。初期費用だけでなく、トレーニング費や保守費も含めて見ることが大切です。
運用負荷:導入・運用のしやすさ
オンプレミス型かSaaS型か、CI/CDパイプラインとの連携APIがあるか、UIの言語対応(日本語・英語)はどうかといった点は、日常の運用負荷に直結します。
とくにセキュリティ専任者が少ない組織では、導入・設定の手間が小さいツールを選ぶほうが立ち上がりがスムーズです。
サポート:導入後に頼れる体制があるか
問い合わせ窓口の対応言語・対応時間、トレーニングプログラムの有無、ユーザーコミュニティの活発さなどを確認します。
内製化チームは立ち上げ期に最もサポートを必要とするため、「導入して終わり」ではなく運用定着までのフォロー体制があるかどうかは重要な判断材料です。
これらの観点を満たすツール:純国産DAST「Vex」
ここまで挙げた4つの観点を国内での内製化という視点で満たすツールのひとつが、当社が提供する純国産のWebアプリケーション脆弱性検査ツール「Vex」です。
日本国内のWebサービス特有の実装パターンを踏まえた診断ロジックを持ち、国内利用実績に基づくシナリオ診断に対応しています(機能)。また、開発段階から日本語UIで設計されているため、診断結果の読み解きや報告書作成における社内の学習コストを抑えられます(運用負荷)。さらに、国内サポート窓口による日本語対応に加え、認定制度「Vex Certification」を通じたトレーニングプログラムも提供されており、内製化チームの立ち上げから定着までをフォローできます(サポート)。
はじめて診断を内製化する組織でも立ち上げやすいよう、トレーニングや運用相談といった伴走支援も整えているため、ツール選定を検討する際の候補のひとつとして挙げられます。実際の導入イメージは、事例もあわせてご覧ください。
▼内製化の第一歩に【無料相談】
Vex 無料トライアル・内製化支援の無料相談はこちら
▼【導入事例】
Vex導入で脆弱性診断内製化とセキュリティ診断事業のサービス化に成功したQTnet。
内製診断の推進体制
実際に内製診断を推進するための体制として、次の2パターンが考えられます。

パターン1は、全社管理部門等が一元的に診断を実施するケースです。
企業によって異なりますが、情報セキュリティ部門や品質管理部門、場合によっては新たに設置された診断チームがその任にあたります。ノウハウが集約され、展開も楽にできるため、内製化当初はこちらの方法をお勧めしています。
パターン1で実績を積んだ後は、蓄えられたノウハウを使って各部署に展開し、各部門で診断を行うパターン2の体制へと移行していきます。各部門で診断を行った結果だけを、全社管理部門に報告してもらいます。
内製診断体制の構築ステップ
次に、実際に内製診断の体制を構築するためのステップを説明します。
1.組織としてのコミットメント(役割を決める)
「セキュリティ診断に関する運用ルールの策定」「どの組織がセキュリティ診断を実施するか」「見つかった脆弱性へのセキュリティコントロール施策の妥当性を判断する組織はどこか」といったことを最初に決めます。
どの組織がセキュリティ診断を実施するかについては、「あの人ならできそう」と個人で選定せず、組織で回せるようにチームを選定しましょう。また、「診断の結果、脆弱性が確認されたが対応の必要なし」と所轄部門が判断した際に、その妥当性を判断し最終承認をする部門も決めておきます。
2.内製診断のスコープを決める
最初からすべてのシステムを内部で対応するのは難しいので、「個人情報を保有していないシステムだけを社内で対応する」「新規に構築したシステムは従来通り外部に委託する」など決めてスタートしましょう。
その後、社内チームの成熟度や体制に合わせて、対応範囲を広げていくことを推奨します。
3.運用ルールを決める
これまで診断ベンダーに依頼していた一部を内製で診断することになるので、どんなシステムをいつ、どうやって診断していくかという運用ルールを決めてドキュメント化し、定常的に運用が回るようにしていきます。

4.トレーニング
診断する人のバックグラウンドごとに必要な学習ポイントを整理し、トレーニングを行います。
| タイプ | 想定スキル | 初期学習ポイント |
|---|---|---|
| IT基礎は知っている (基本情報処理レベル) |
IPアドレスなどの基礎的用語は知っているが、サーバ、プログラムなどは、あまり触ったことがない。 | Webアプリとは HTML HTTPプロトコル |
| インフラ業務経験あり | ネットワークレイヤーの運用や、サーバのコンフィグ設定の経験がある。ただし、プログラムやアプリケーションについてはそれほど詳しくない。 | HTML Webプログラミング基礎 Webセキュリティ概要 |
| セキュリティ関連業務経験あり | 脆弱性情報を管理する業務をしたことがあり、Webの脆弱性も名前や概要程度ならわかる。ただし、プログラムやアプリケーションについてはそれほど詳しくない。 | HTML HTTPプロトコル Webプログラミング基礎 |
| Webプログラミング経験あり | Webプログラミングの経験(業務とは限らない)があるが、セキュリティについては経験がない。 | Webセキュリティ詳細 (HTTPプロトコル) |
5.チーム編成
トレーニングが終わったメンバーでチーム編成を行いますが、ポイントは2つです。
POINT1:診断担当者は2名以上でスタートする
診断担当者は必ず2名以上でチームを組みましょう。担当者の心理的不安要素を軽減するだけではなく、担当者の部署異動の際などにも、ノウハウを途切れさせずに運用を継続することができます。
POINT2:診断工程を複数名で分担する
トレーニングした方のスキルをうまくマッチングさせて複数名で診断を進めていきます。まだ経験が浅く「基礎を知っている」レベルの方には、テストシナリオの作成~検査ツールでスキャニングする工程を担当いただくのがよいでしょう。その結果を分析・報告するには専門知識が必要になるので、トレーニングを通じてセキュリティ知識を身に付けた方が担当するのが適しています。それぞれのスキルレベルに合わせてメンバーを配置することで内製化を早期に立ち上げられる診断チームを作ることができます。

6.外部ベンダーを上手に使う
診断チームを立ち上げた後も、「診断品質に自信が持てない」「アドバイスやレクチャーを受けたい」といった不安が出てくると思います。そのような場合には、外部ベンダーを期間限定でうまく活用してノウハウを吸収しながら進めていくことをオススメしています。
株式会社ユービーセキュアではWebアプリケーション脆弱性検査ツール「Vex」をうまく活用した内製化診断の構築をご提案しています。それ以外にも、ルール作成、セキュリティ人材支援など、セキュリティ診断に必要な支援を一貫して行っていますので、内製化を検討される際には、ぜひご相談いただけたら幸いです。
▼脆弱性診断の内製化をご検討の方へ
Vex/VexCloud 無料トライアル・内製化支援の無料相談
Vex導入事例集ダウンロード
▼あわせて読みたい関連記事
DevSecOpsとは|開発工程にセキュリティを組み込む実践ガイド
脆弱性診断ツールの選び方|無料・有料の比較と評価軸
