ウェブアプリケーションセキュリティ 第2版

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

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

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

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

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

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

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

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

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

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