ソースコードレビューは、人がソースコードを確認し、設計・保守性・安全性の問題を見つける活動です。SG試験で迷いやすい静的解析やSASTとの違いを整理します。

sg sg-security-overview threat_vulnerability sg-security-measures unauthorized_access

まず結論

  • ソースコードレビューとは、人がソースコードを読み、実装ミス、設計上の問題、保守しにくい書き方、脆弱性につながる処理を確認する活動です。
  • SG試験では、「人がコードを確認する」のか「ツールで機械的に解析する」のかを切り分けることが重要です。

直感的な説明

ソースコードレビューは、プログラムの文章チェックのようなものです。

文章を書くとき、誤字だけでなく、意味が伝わるか、表現が分かりやすいか、読み手に誤解されないかを人が確認します。

ソースコードでも同じです。

プログラムが動くかどうかだけでなく、次のような点を確認します。

  • 意図した処理になっているか
  • 他の人が読んでも分かりやすいか
  • 危険な書き方をしていないか
  • 入力値チェックが不足していないか
  • 認証や権限確認の抜けがないか

つまり、ソースコードレビューは「コードを人の目で確認し、品質や安全性を高める活動」です。

静的解析やSASTもソースコードを実行せずに確認しますが、中心はツールによる機械的な検出です。

定義・仕組み

ソースコードレビューは、開発者やレビュー担当者がソースコードを確認し、問題点を指摘して修正につなげる活動です。

基本の流れは次のとおりです。

  1. レビュー対象のソースコードを用意する
  2. レビュー観点を決める
  3. 人がコードを確認する
  4. 問題点や改善点を指摘する
  5. 開発者が修正する
  6. 必要に応じて再確認する

レビュー観点には、次のようなものがあります。

  • 要件どおりに実装されているか
  • 処理の流れが分かりやすいか
  • 例外処理やエラー処理が適切か
  • 入力値チェックが行われているか
  • 認証・認可の処理に抜けがないか
  • 秘密情報をコード内に直接書いていないか
  • 保守しやすい構造になっているか

IPAのセキュア・プログラミング講座では、脆弱性を作り込まないための考え方や、ソースコードの検査に関する情報が整理されています。安全な実装や検査の考え方を確認する場合は、IPAのセキュア・プログラミング講座が参考になります。

ソースコードレビューの特徴は、ツールでは判断しにくい設計意図、業務ルール、可読性、保守性まで確認できることです。

ただし、人が確認するため、レビュー担当者の知識や経験に左右されることがあります。

そのため、実務では静的解析ツールやSASTで機械的に検出できる部分を先に確認し、人は設計や判断が必要な部分を見る、という組み合わせがよく使われます。

どんな場面で使う？

ソースコードレビューは、主に開発中やリリース前の品質確認で使われます。

たとえば、次のような場面です。

  • 新しい機能を追加したとき
  • 重要な処理を変更したとき
  • 認証や権限管理に関わるコードを変更したとき
  • セキュリティ上重要な入力処理を実装したとき
  • リリース前に品質を確認したいとき

特に、セキュリティに関わる処理では、単にプログラムが動くだけでは不十分です。

たとえば、ログイン処理が動いていても、権限確認が抜けていれば、本来見てはいけない情報にアクセスできる可能性があります。

このような問題は、ツールだけでは判断しにくい場合があります。

そのため、人が業務ルールや設計意図を踏まえて確認するソースコードレビューが重要になります。

一方で、ソースコードレビューは、実行中のアプリケーションの挙動を確認するものではありません。

実行中のアプリに外部からアクセスして応答を見るならDASTです。

多様な入力データを与えて異常動作を探すならファジングです。

SG試験では、人がコードを読む活動か、ツールで検査する活動か、実行して挙動を見る活動かを分けて考えると選択肢を切りやすくなります。

よくある誤解・混同

ソースコードレビューは、静的解析、SAST、DAST、ファジングと混同しやすいです。

混同しやすい用語 判断ポイント
ソースコードレビュー 人がコードを読み、設計・品質・安全性を確認する
静的解析 プログラムを実行せずにコードなどを確認する考え方全般
SAST ソースコードを実行せず、ツールで脆弱性につながる実装を検出する
DAST 実行中のアプリを外部から検査し、応答や挙動を見る
ファジング 問題を起こしそうなデータを大量に入力し、異常動作を探す

SG試験では、次のような表現に注意します。

  • 「人がソースコードを確認する」
    → ソースコードレビューを疑います。

  • 「設計意図や業務ルールも踏まえて確認する」
    → ソースコードレビューに近い説明です。

  • 「ソースコードを実行せずにツールで解析する」
    → SASTや静的解析です。

  • 「実行中のアプリへ外部からアクセスする」
    → DASTです。

  • 「大量の入力データを与えて異常終了を確認する」
    → ファジングです。

よくあるひっかけは、ソースコードレビューと静的解析を完全に同じものとして扱うことです。

どちらもプログラムを実行しない確認に含まれますが、中心が違います。

  • ソースコードレビュー：人の判断が中心
  • 静的解析・SAST：ツールによる機械的な解析が中心

また、ソースコードレビューはセキュリティだけでなく、可読性、保守性、設計の妥当性も確認できます。

一方、SASTは危険なパターンの検出に強いですが、業務ルールに合っているかまでは判断しにくい場合があります。

まとめ（試験直前用）

  • ソースコードレビューは、人がコードを読んで問題を見つける活動です。
  • 静的解析は、プログラムを実行せずに確認する考え方全般です。
  • SASTは、静的解析のうち、ツールで脆弱性につながる実装を検出する手法です。
  • DASTは、実行中のアプリを外部から検査する手法です。
  • SG試験では、人が見るのか、ツールで見るのか、実行して見るのかで判断します。

確認問題

ソースコードレビューと静的解析・SASTの違いとして、最も適切なものはどれか。

ア. ソースコードレビューは人がコードを読み、設計や安全性などを確認する活動であり、SASTはソースコードを実行せずにツールで脆弱性につながる実装を検出する手法である。
イ. ソースコードレビューは実行中のWebアプリに外部からアクセスする手法であり、SASTは攻撃者の視点で侵入できるか確認する手法である。
ウ. ソースコードレビューは端末を社内ネットワークへ接続してよいか判定する仕組みであり、静的解析はマルウェア感染端末を隔離する仕組みである。
エ. ソースコードレビューは大量の入力データを自動生成して異常動作を確認する手法であり、SASTは通信を暗号化する手法である。

回答と解説を表示 正解は **ア** です。 ソースコードレビューは、人がソースコードを読み、設計意図、品質、安全性、保守性などを確認する活動です。 SASTは、ソースコードを実行せずにツールで解析し、危険な書き方や脆弱性につながる実装を検出する手法です。 イはDASTやペネトレーションテストに近い説明です。 ウは検疫ネットワークに近い説明です。 エはファジングや暗号化の説明が混ざっており、ソースコードレビューやSASTの説明ではありません。

🔗 関連記事

🏠 情報セキュリティマネジメントトップに戻る