Web アプリケーションセキュリティ

第21章 脆弱性の管理 脆弱性管理

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

優れたセキュリティソフトウェア開発ライフサイクル（SSDL）プロセスでは、ウェブアプリケーションで発見された脆弱性を 取得し、トリアージし、解決するための、明確に定義されたパイプラインが必要です。前章では、脆弱性を発見するメソッドについて説明し、その前に、発見された未解決の脆弱性の数を減らすために、アーキテクチャと 開発フェーズに SSDL を統合する方法について説明しました。

大規模なアプリケーションの脆弱性は、アーキテクチャの段階から運用コードに至るまで、これらすべての段階で発見される。アーキテクチャフェーズで指摘された脆弱性は、防御的にコード化することができ、コードが書かれる前に対策を開発することができる。アーキテクチャ段階以降に発見された脆弱性は、最終的に修正され、影響を受ける環境に修正パッチを適用できるように、適切に管理する必要がある。

そこで、脆弱性管理パイプラインの出番となる。

脆弱性を再現する

脆弱性レポートの後、それを管理する最初のステップは、本番環境に近い環境で脆弱性を再現することである。これには複数の利点がある。まず第一に、脆弱性が本当に脆弱性であるかどうかを判断することができる。ユーザ定義の設定エラーが脆弱性のように見えることがある。例えば、ユーザが普段は写真を "非公開 "に設定しているのに、写真ホスティングアプリの画像を "誤って "公開にしてしまったとする。

脆弱性を効率的に再現するためには、本番環境をできるだけ模倣したステージング環境を構築する必要がある。ステージング環境をセットアップするのは難しいので、このプロセスは完全に自動化すべきである。

新機能をリリースする前に、内部ネットワーク経由でのみアクセス可能なアプリケーションのビルドで利用できるようにするか、ある種の暗号化されたログインによってセキュアにすべきである。

ステージング環境は、実際の本番環境を模倣しているが、実際のユーザや顧客は必要ない。しかし、本番モードでのアプリケーションの機能を視覚的かつ論理的に表現するために、ステージング環境はモックユーザとモックオブジェクトを含むべきである。

報告された各脆弱性を再現することで、誤検知によるエンジニアリング時間の浪費を安全に避けることができる。さらに、バグ報奨金プログラムのような有料のプログラムを通じて外部から報告された脆弱性は、偽陽性の脆弱性に対して報奨金が支払われないように、再現する必要がある。

最後に、脆弱性を再現することで、あなたのコードベースにおいて何が脆弱性を引き起こしたかについて、より深い洞察を得ることができ、脆弱性を解決するための不可欠な第一歩となる。すぐに再現し、再現結果をログに残すべきである。

脆弱性の深刻度ランキング

脆弱性を再現した後、エクスプロイトの機能に関する十分なコンテキストを獲得し、ペイロードが配信されるメカニズ ムと、その結果アプリケーションがどのような種類のリスク（データ、資産など）に対して脆弱であるかを理解する必要があ る。このコンテキストを念頭に置いて、深刻度に基づいて脆弱性のランク付けを始めるべきである。

脆弱性を適切にランク付けするためには、2つの脆弱性を正確に比較するのに十分堅牢でありながら、一般的でない形式の脆弱性にも適用できる柔軟性を備えた、明確に定義され、それに従った採点システムが必要である。脆弱性を採点する最も一般的なメソッドは、共通脆弱性採点システム（Common ...