脆弱性診断で同じ指摘を繰り返すのはなぜ？診断結果を再発防止につなげる方法

脆弱性診断を実施し、指摘された脆弱性を修正したにもかかわらず、次回の診断で同じような指摘を受けてしまう――。

このような経験はないでしょうか。

例えば、以前の診断でクロスサイト・スクリプティング（XSS）を修正したものの、次回は別の画面でXSSが見つかったり、認可に関する問題を修正したにもかかわらず、新たに追加した機能で同様の問題が見つかったりするケースです。指摘された箇所そのものは修正できていても、脆弱性が生まれた原因まで改善できていなければ、別の場所で同じ問題が発生する可能性があります。

そこで重要になるのが、診断結果を「修正すべき脆弱性の一覧」として扱うのではなく、「自社の開発プロセスにどのような課題があるのかを知るための情報」として活用することです。

本記事では、脆弱性診断で同じような指摘を繰り返してしまう理由を整理したうえで、診断結果から原因を分析し、開発ルールやレビュー、教育へ反映することで、脆弱性の再発防止につなげる方法をご紹介します。

「同じ脆弱性が再発した」とはどういう状態か

「同じ指摘が繰り返されている」といっても、実際にはいくつかのパターンがあります。

例えば、前回指摘された箇所の修正が十分ではなく、同じ場所で再び脆弱性が見つかるケースがあります。一方で、前回指摘された箇所は正しく修正できているものの、別の画面や新しく追加された機能で同じ種類の脆弱性が見つかるケースもあります。

後者の場合、個別の修正というよりも、開発の仕組みに原因が残っている可能性があります。

例えば、ある入力フォームでXSSが見つかったため、その画面だけエスケープ処理を追加したとします。しかし、安全な出力方法が開発ルールとして共有されていなければ、別の開発者が新しい画面を作る際に、同じような実装をしてしまうかもしれません。

認証・認可についても同様です。あるAPIの権限チェック漏れを修正しても、「どこで、どのように認可を確認するか」という設計方針が共有されていなければ、新しいAPIで再び認可漏れが発生する可能性があります。

つまり、同じ種類の脆弱性が繰り返し見つかる場合には、「修正できていない」のではなく、修正内容が次の開発へ反映されていないことが問題になっているケースがあります。

脆弱性そのものではなく「発生原因」を見る

診断結果には通常、「XSS」「SQLインジェクション」「認可不備」など、見つかった脆弱性が記載されています。

しかし、再発防止を考える際には、脆弱性の名称だけを見るのでは十分ではありません。重要なのは、「なぜその脆弱性が発生したのか」を確認することです。

例えば、同じXSSでも原因はさまざまです。開発者が安全な出力方法を知らなかったのか、ルールはあったもののチームに浸透していなかったのか、共通部品に問題があったのか、レビューで見落としていたのかによって、必要な対策は変わります。

診断結果を確認する際には、例えば次のような観点で原因を整理します。

• 設計段階でセキュリティ要件を考慮できていたか
• 安全な実装方法がルール化されていたか
• ルールが開発チームに共有・定着していたか
• 共通部品やライブラリに問題がなかったか
• レビューで必要な観点を確認できていたか
• 開発者が脆弱性の仕組みや対策を理解していたか

例えば、複数の画面でXSSが見つかった場合は、個々の画面の実装ミスだけでなく、出力処理のルールが統一されているかを確認します。

一方、認証・認可の指摘が複数見つかった場合は、「誰が、どの情報や機能にアクセスできるのか」という権限設計そのものが整理されていない可能性もあります。

また、担当者が変わっても同じ種類の実装ミスが発生している場合は、個人の問題というより、チーム全体で必要な知識が共有されていない可能性があります。

このように、診断結果を脆弱性の種類だけでなく「発生原因」の視点から見ることで、次回の開発で何を変えるべきかが見えやすくなります。

診断結果を「修正リスト」から「改善リスト」へ変える

発生原因が整理できたら、次は診断結果の管理方法を見直します。

診断結果を、

「XSSを修正する」
「認可漏れを修正する」
「Cookieの設定を変更する」

といった修正作業だけで管理すると、対応が完了した時点で知見が失われてしまいます。

そこで、指摘事項ごとに「今回の修正」と「再発防止策」を分けて考えます。

例えばXSSであれば、今回の修正は「指摘された画面の出力処理を修正する」です。

一方、再発防止策としては、

• 同じ実装がほかの画面にないか確認する
• 安全な出力方法を開発ガイドラインへ反映する
• コードレビューのチェック項目へ追加する
• 必要に応じて開発チームへ仕組みと対策を共有する

といった対応が考えられます。

さらに、指摘されたシステムだけでなく、同じ開発言語やフレームワーク、共通ライブラリを利用しているほかのシステムにも同様の問題がないか確認します。

つまり、再発防止では「その指摘を直す」だけではなく、「同じ原因による問題がほかにないか」「次回の開発で繰り返さないために何を変えるか」まで考えることが重要です。

診断結果を単なる修正リストではなく、組織の改善リストとして扱うことで、一度の診断から得られる知見をより広く活かせるようになります。

改善内容を次の開発プロセスへ反映する

改善リストとして整理した内容は、実際の開発プロセスへ反映していきます。

例えば、認証・認可や権限管理など設計段階に原因がある問題については、次回以降の設計レビューで確認すべき事項として追加します。XSSやSQLインジェクションなど、安全な実装方法を標準化できるものについては、開発ガイドラインやコーディングルールへ反映します。必要に応じて、安全な共通部品やライブラリを用意することも有効です。

また、診断で見つかった問題はコードレビューや設計レビューのチェック項目にも反映します。「診断で見つけてもらう」のではなく、次回からは開発中に自分たちで問題に気づける状態へ近づけていくことが理想です。

こうした取り組みを、診断 → 修正 → 原因分析 → 改善策の整理 → 開発プロセスへ反映 → 次回開発という流れで繰り返すことで、診断結果を継続的な開発品質の改善へつなげることができます。

開発者自身が脆弱性に気づける状態を目指す

仕組みを整えるだけでなく、それを運用する開発者自身の知識や判断力を高めることも重要です。

例えば、「出力時には適切なエスケープを行う」というルールだけを覚えていても、XSSがどのような仕組みで発生するのかを理解していなければ、これまでとは異なる実装を行う際に適切な対策を判断できない可能性があります。

目指したいのは、診断で指摘されてから修正するだけではなく、開発者自身が設計や実装の段階でリスクに気づき、レビューの段階でも問題を発見できる状態です。

そのためには、開発ガイドラインやチェックリストの整備とあわせて、脆弱性が発生する仕組みや攻撃方法、安全な実装方法について、開発チーム内で共通の知識を持つことが重要になります。こうした知識や判断力を体系的に身につける方法の一つとして、セキュア開発トレーニングがあります。

Proactive Defenseのセキュア開発トレーニング

Proactive Defenseでは、開発者向けのセキュア開発トレーニングを提供しています。Webアプリケーションで発生する代表的な脆弱性について、その仕組みや安全な実装方法を学び、講義だけでなくハンズオンを通じて脆弱性と対策を体験できる内容をご用意しています。

例えば、

• 脆弱性診断で同じような指摘を繰り返している
• 診断結果を開発チーム全体へ展開したい
• 開発者によってセキュリティ知識にばらつきがある
• セキュアコーディングの考え方をチームで共有したい
• 脆弱性を作り込まない開発体制を目指したい

といった場合に、トレーニングをご活用いただけます。脆弱性診断で見つかった問題をその都度修正するだけでなく、診断から得られた知見を次の開発へ活かしていく。そのための取り組みの一つとして、セキュア開発トレーニングをご活用いただけます。

まとめ

脆弱性診断で同じ種類の指摘が繰り返される場合、指摘箇所の修正だけではなく、その脆弱性が発生した原因に目を向けることが重要です。

開発ルールに問題があったのか、レビューの観点が不足していたのか、共通部品に問題があったのか、開発者への知識共有が不足していたのか。原因によって、必要な改善策は異なります。

診断結果を「修正リスト」ではなく「改善リスト」として活用し、同様の実装への横展開、開発ガイドラインやレビュー項目への反映、開発者教育までつなげることで、一度の診断から得られた知見を組織全体の資産にすることができます。

脆弱性診断を「問題を見つけてもらう場」で終わらせず、「自分たちの開発方法を改善する機会」として活用することが、脆弱性を作り込みにくい開発体制につながります。