公開日:2007年9月26日
独立行政法人情報処理推進機構
セキュリティセンター
本ページの情報は2007年9月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。
ソースコードレビューは、開発者担当者が書いたソースコードを閲読してセキュリティ脆弱性あるいはそのきざしを読み取る作業である。
ソースコードレビューで見いだされた脆弱性の情報を開発作業にフィードバックし、ソースコード修正を行う。
プログラマが書き下ろしたソースコードは、そのままでは多くのバグといくつかのセキュリティ脆弱性を内に秘めているおそれがある。
ソースコードの正しさを検証するためにテストを行うのであるが、その前にソースコードをレビューしてブラシュアップすることにより、問題の何割かを事前に除去しておくことができる。
ソースコードレビューを行う人物には次が考えられる。
開発者本人がソースコードを見直すことと、別の人物の眼によるチェックを行うことの両方が行われるのが望ましい。
前者の利点は、開発者がより脆弱性の少ないコードを書く能力の向上がはかれること、後者の利点は、思い込みによって開発者が見落としがちな問題についても見つけ出す機会が得られることである。
ソースコードが新たに書きおこされるか、既存のプログラムが改修されて、ソフトウェアの中のひとまとまりの機能のソースコードが揃った時点でレビューを行う。
ソースコ-ドレビューの成果物としては、次の記録が残されていることが望ましい。
レビューにおいては、「このように直す」といった脆弱性の対策方法までは述べず、問題をなるべく多く指摘することに注力するのがよい。
ソースコードレビューは次の4つの段階に分けて行う。
ソースコードを書いた本人以外がレビューする場合、詳しく内容を吟味する前に下読みを行う。ここでは、次のような情報の把握につとめる。可能なら設計ドキュメントを入手して参照する。
ソースコードを下読みし、そのコードが雑に書かれたものであるか十分な考慮と注意の下に書かれたものであるかを判断する。
著しく水準を下回る場合はソースコードを差し戻し、プログラマに改善を求める。
また、所定のコーディング規約、命名規約に従っているかどうかを点検し、違反箇所を指摘する。
点検項目の例として、例えば、次のような項目が考えられる。
書かれたコードが所期の機能を果たすものであるか否かを点検する。バグが著しく多く見いだされた場合はソースコードを差し戻し、プログラマに改善を求める。
脆弱性検出のためには、例えば、「セキュリティテスト」の記事にある「チェックリスト2」に示すような観点でソースコードを点検することが望ましい。ただし、これらの項目の中には実際にプログラムを動かしてみないと確認しづらいものも含まれる。慣れないうちは次のような観点から始めるのもひとつの手段である。
上記の脆弱性観点からのレビューをすべて行うことが出来れば脆弱性対策に大いに寄与するが、いきなりすべてを行うことは必ずしも容易ではない。
より手軽に始める方法としては、まず最初はソースコードの静的検査ツールを使い、ツールが自動で検出してくれる問題から手を付けるという方法がある。
ソースコードを静的に検査し、セキュリティ脆弱性を指摘してくれる有償のツール製品が存在する。例えば、下記のものがある。
また、機能は限定されるが、領域あふれ、フォーマット文字列問題、外部からの問題のある入力の受け入れ箇所等、注意を要するランタイム関数の使用箇所を指摘してくれる無償ツールも存在する。
例えば、次のものである。