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

第19章. セキュリティのためにコードをレビューする

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

コードレビューステージは、セキュリティに配慮したコードの組織化においては、常にアーキテ クチャステージの後に行われなければならない。

今日、一部の技術系企業は、「速く動いて、物事を壊す」ことを信条としているが、そのような信条はしばしば悪用され、適切なセキュリティプロセスを無視する手法として使用されている。動きの速い企業であっても、コードを出荷する前にアプリケーションアーキテクチャをレビューすることが不可欠である。セキュリティの観点からは、機能アーキテクチャ全体を前もってレビューするのが 理想的であるが、不確実な条件付きでは実行不可能かもしれない。そのため、最低限、主要でよく知られた機能についてはアーキテクトとレ ビューを実施し、新機能が登場した場合は、開発前にアーキテクトとセキュリティレ ビューの両方を実施する。

セキュリティギャップがないかどうかをコードレビューする適切なタイミングは、コードコミッ トの背後にあるアーキテクチャが適切にレビューされた後である。つまり、コードのレビューは、安全な開発のベストプラクティスに従っている組織化では、2 番目のステップであるべきである。

これには2つの利点がある。まず、最も明白な利点はセキュリティであるが、通常、開発チームの外部からコードレビューを行うレビュアーを追加することには、それなりのメリットもある。これは、開発者に公平な目を提供し、そうでなければ未知のバグやアーキテクチャの欠陥を発見する可能性がある。

このように、コードセキュリ ティ（ ）レビューの段階は、アプリケーションの機能性とアプリケーションセキュリティの両 方にとって不可欠である。コードセキュリティレビューは、機能レビューしか実施していない組織化において、追加的なステップ として実装されるべきである。そうすることで、本番環境にリリースされるような影響度の高いセキュリティバグの数を劇的に減らすことができる。

一般化すると、コードセキュリティ レビューは、マージリクエスト（伝統的に「プルリクエスト」とも呼ばれる。）全機能が開発され、接続を必要とするすべてのシステムが統合されているはずなので、コードセキュリ ティレビューをマージ時に実施することは理にかなっている。この時点で、コードの全範囲を一度にレビューすることができる。

コードセキュリティレビューを、コミットごと、あるいはペアプログラミング アプローチのような、よりきめ細かな方法で開発プロセスに関連付けることは可能かもしれない。いずれのメソッドにせよ、コードの全範囲をカバーしない時点からコードを見ることになるため、一貫した継続的な作業が必要になる。しかし、ミッションクリティカルなセキュリティ機能については、これは賢明なアプローチかもしれない。一人がその機能に集中し、もう一人がセキュ リティに集中することで、マージリクエスト時のレビューでは不可能な、極めてセキュリ ティに配慮した機能を書くことができるかもしれない。

どのようなタイミングでコードのセキュリティホールをレビューするかは、その組織 の自由であり、既存のプロセスに適合していなければならない。しかし、セキュリティコードレビューを開発プロセスに組み込むには、前述のメソッドが最も現実的で効果的であろう。

コードレビューの始め方

コードセキュリティレビューは、コード機能性レビューと非常によく似ている。機能性レビュー ...