第2章 脆弱性回避策とソフトウェア開発工程
ソースコードレビュー

ソースコードレビュー

ソースコードレビューは、開発者担当者が書いたソースコードを閲読してセキュリティ脆弱性あるいはそのきざしを読み取る作業である。
ソースコードレビューで見いだされた脆弱性の情報を開発作業にフィードバックし、ソースコード修正を行う。

(1) ソースコードレビューを行う理由

プログラマが書き下ろしたソースコードは、そのままでは多くのバグといくつかのセキュリティ脆弱性を内に秘めているおそれがある。

ソースコードの正しさを検証するためにテストを行うのであるが、その前にソースコードをレビューしてブラシュアップすることにより、問題の何割かを事前に除去しておくことができる。

(2) 誰が行うか

ソースコードレビューを行う人物には次が考えられる。

開発者本人がソースコードを見直すことと、別の人物の眼によるチェックを行うことの両方が行われるのが望ましい。
前者の利点は、開発者がより脆弱性の少ないコードを書く能力の向上がはかれること、後者の利点は、思い込みによって開発者が見落としがちな問題についても見つけ出す機会が得られることである。

(3) いつ行うか

ソースコードが新たに書きおこされるか、既存のプログラムが改修されて、ソフトウェアの中のひとまとまりの機能のソースコードが揃った時点でレビューを行う。

(4) 何を記録するか

ソースコ−ドレビューの成果物としては、次の記録が残されていることが望ましい。

レビューにおいては、「このように直す」といった脆弱性の対策方法までは述べず、問題をなるべく多く指摘することに注力するのがよい。

レビューの4つの段階

ソースコードレビューは次の4つの段階に分けて行う。

(1) 下読み

ソースコードを書いた本人以外がレビューする場合、詳しく内容を吟味する前に下読みを行う。ここでは、次のような情報の把握につとめる。可能なら設計ドキュメントを入手して参照する。

(2) 成熟度点検

ソースコードを下読みし、そのコードが雑に書かれたものであるか十分な考慮と注意の下に書かれたものであるかを判断する。
著しく水準を下回る場合はソースコードを差し戻し、プログラマに改善を求める。

また、所定のコーディング規約、命名規約に従っているかどうかを点検し、違反箇所を指摘する。
点検項目の例として、例えば、次のような項目が考えられる。

(3) 機能点検

書かれたコードが所期の機能を果たすものであるか否かを点検する。バグが著しく多く見いだされた場合はソースコードを差し戻し、プログラマに改善を求める。

(4) 脆弱性点検

脆弱性検出のためには、例えば、「セキュリティテスト」の記事にある「チェックリスト2」に示すような観点でソースコードを点検することが望ましい。ただし、これらの項目の中には実際にプログラムを動かしてみないと確認しづらいものも含まれる。慣れないうちは次のような観点から始めるのもひとつの手段である。

ツールの利用

上記の脆弱性観点からのレビューをすべて行うことが出来れば脆弱性対策に大いに寄与するが、いきなりすべてを行うことは必ずしも容易ではない。

より手軽に始める方法としては、まず最初はソースコードの静的検査ツールを使い、ツールが自動で検出してくれる問題から手を付けるという方法がある。

図2-3: ソースコードレビュー

ソースコードを静的に検査し、セキュリティ脆弱性を指摘してくれる有償のツール製品が存在する。例えば、下記のものがある。

また、機能は限定されるが、領域あふれ、フォーマット文字列問題、外部からの問題のある入力の受け入れ箇所等、注意を要するランタイム関数の使用箇所を指摘してくれる無償ツールも存在する。
例えば、次のものである。