（4）テスト
アプリケーションの仕様が安定してきたら、動的解析ツールをマニュアルモードに切り替えましょう。マニュアルモードで動的解析ツールの設定を作り込むことで、自動巡回では見つけられない脆弱性を見つけることが可能になります。設定には工数もかかりますが、画面遷移があまり多くない、シンプルなアプリケーションであれば、設定を作り込む工数も少なくなり、検査時間も少なく済みます。
ここまで実行していれば、セキュアなアプリケーションが構築できていることでしょう。しかし、アプリケーション自体はセキュアに作られていても、本番環境のOSやミドルウェアの設定が不十分なままになっている可能性があります。そのため、初回リリースや、アプリケーションに大幅な変更が発生するタイミングでは、セキュリティの専門家に脆弱性診断を依頼し、脆弱性を見落としていないか確認するようにするとよいでしょう。
（5）リリース後
アプリケーションのリリース後は、アプリケーションで使われているフレームワークやライブラリに新しい脆弱性が報告されていないか、日々監視を行います。監視にはSCAを使用すると良いでしょう。フレームワークやライブラリに対して新しい脆弱性が公開された場合、脆弱性が悪用された結果、情報漏洩などの被害につながる恐れがあります。脆弱性情報が公開された場合は、悪用される前にフレームワークやライブラリを更新するなどの対策を行う必要があります。
アプリケーションのリリース後には、不具合修正や機能追加を行うことも多いと思います。実装フェーズと同じように、アプリケーションを修正した場合は、セキュリティ対策ツールによるチェックを自動で行うことができるように、ツールの設定を維持してしておきます。不具合修正ではなく、機能追加や機能変更を行った場合は、動的解析ツールの設定も更新し、正しい解析結果が得られる状態を維持していきます。設定が古いままだと、新しく開発した部分が正しく解析されなくなり、新しく埋め込んだ脆弱性を見落とす可能性があります。
開発が進んでいるプロジェクトに適用する場合
これまで紹介した内容を開発が進んでいるプロジェクトに導入しようとすると、膨大な脆弱性が報告され、どこから手を付けたらいいのか分からない状態に陥ってしまいます。そのような状況を避けるため、優先度を決めて少しずつ順に導入するとよいでしょう。
最初に導入を検討すべきは、SCAと動的解析ツールです。なぜなら、影響度が高い脆弱性をいち早く特定する必要があるからです。そのため、SCAを用いてフレームワークやライブラリの脆弱性をチェックし、動的解析ツールを用いてアプリケーション固有の脆弱性を見つけます。見つかった脆弱性は実際に悪用された場合を想定し、簡単に悪用でき、被害が大きいものから優先的に修正をします。アプリケーションに脆弱性があることが分かっていても、すぐにプログラムの修正を行えない場合は、WAF（Web Application Firewall）を導入することも併せて検討してください。
次に、静的解析ツールを導入し、今後開発するプログラムに脆弱性を埋め込まないような体制を整えましょう。最初は解析内容を最小限に絞り、開発者に負担にならないように導入し、少しずつ解析内容を増やしていくと良いでしょう。
まとめ
簡単にまとめると、今回のポイントは以下のとおりです。
- できる限り早い工程からセキュリティを意識した開発を行う。
- セキュリティ対策ツールは自動で実行されるようにしておく。
- セキュリティ対策ツールの実行結果はプルリクエストやIDEなど、普段使っているツール上で確認できるようにしておき、自然に修正できるようにしておく。
- 過剰検知を管理できるツールを導入する。
- SCAはライブラリの脆弱性を検出するので実装フェーズだけでなく、リリース後も定期的に実行する。
- 動的解析ツールは開発フェーズによって使い方を分ける。
次回は、今回紹介した内容を具体的にどのように設定していくのか、実際の設定例を交えて説明します。
