SASTとは？ソースコードを実行せずに検査する仕組み【SG試験】

まず結論

SASTとは、ソースコードを実行せずに解析し、脆弱性につながる危険な書き方や実装ミスを見つける検査手法です。
SG試験では、「動かして確認する」のではなく「ソースコードを見て確認する」点で判断します。

直感的な説明

SASTは、プログラムを動かす前に、ソースコードを読んで危ない部分を探す検査です。

たとえば、建物にたとえると、完成後に入って確認するのではなく、設計図を見て問題がないか確認するイメージです。

設計図を見て確認する → SAST
完成した建物に入って確認する → DAST

ソフトウェアでも同じです。

SASTでは、プログラムを実行せずに、ソースコードや設定ファイルなどを解析します。

そして、次のような問題がないかを確認します。

入力値チェックが不足していないか
危険な関数を使っていないか
認証や認可の処理に問題がないか
秘密情報をコード内に直接書いていないか
コーディング規約に反する書き方をしていないか

つまり、SASTは「動かす前に、コードの書き方から弱点を見つける」手法です。

定義・仕組み

SASTは、Static Application Security Testing の略です。

日本語では、静的アプリケーションセキュリティテストと説明されることがあります。

SASTでは、ソフトウェアを実行せずに、ソースコードや関連ファイルを解析します。

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

検査対象のソースコードを用意する
SASTツールでコードを解析する
危険な書き方や脆弱性につながるパターンを検出する
検出結果を確認する
必要に応じてコードを修正する

SASTで検出しやすいものには、次のような例があります。

SQLインジェクションにつながる可能性のある実装
クロスサイトスクリプティングにつながる可能性のある実装
バッファオーバーフローにつながる可能性のある処理
ハードコードされたパスワードや秘密情報
入力値検証やエラー処理の不足

IPAのセキュア・プログラミング講座でも、ソースコードの静的検査ツールを使って脆弱性を比較的手早く検出する方法が紹介されています。詳しくは、IPAのツールの利用が参考になります。

SASTの特徴は、ソフトウェアを実行できる状態になる前でも検査できることです。

そのため、開発の早い段階で問題を見つけやすく、修正コストを下げやすいという利点があります。

ただし、SASTだけですべての問題を見つけられるわけではありません。

実行時の挙動、画面操作、通信、環境依存の問題などは、DASTや動的解析で確認する必要があります。

どんな場面で使う？

SASTは、主に開発中やコードレビュー前後に使われます。

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

開発中に危険な実装を早めに見つけたい
コードレビューの前に機械的にチェックしたい
継続的インテグレーションで毎回コードを検査したい
セキュアコーディングのルール違反を検出したい
リリース前に基本的な脆弱性を確認したい

SASTは、ソースコードをもとに検査するため、開発者にとって修正箇所を把握しやすいのが特徴です。

一方で、実際に攻撃が成立するか、外部からどのように見えるかまでは分からない場合があります。

そのような場合は、DASTやペネトレーションテストと組み合わせて確認します。

整理すると、次のようになります。

コードの書き方を確認する → SAST
実行中のアプリの応答を見る → DAST
攻撃者視点で侵入可能性を見る → ペネトレーションテスト
多様な入力で異常動作を見る → ファジング

SG試験では、「ソースコードを実行せずに解析する」という表現があれば、SASTを疑います。

よくある誤解・混同

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

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

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

「ソースコードを実行せずに解析する」
→ SASTを疑います。
「危険な関数や実装パターンを検出する」
→ SASTに近い説明です。
「実行中のWebアプリに外部からアクセスする」
→ DASTです。
「大量の入力データを与えて異常終了を確認する」
→ ファジングです。
「攻撃シナリオに沿って侵入できるか確認する」
→ ペネトレーションテストです。

よくあるひっかけは、SASTをDASTと逆に覚えてしまうことです。

SASTの S は Static、つまり静的です。

静的ということは、プログラムを動かさずに確認するという意味です。

一方、DASTの D は Dynamic、つまり動的です。

動的ということは、プログラムを動かして確認するという意味です。

この違いを押さえると、選択肢をかなり切りやすくなります。

まとめ（試験直前用）

SASTは、ソースコードを実行せずに解析する検査手法です。
危険な書き方や脆弱性につながる実装を、開発の早い段階で見つけます。
DASTは、実行中のアプリを外部から検査する手法です。
ファジングは、大量の入力データで異常動作を探す方法です。
SG試験では、ソースコード・実行しない・静的の3点でSASTを判断します。

確認問題

SASTの説明として、最も適切なものはどれか。

ア. 実行中のWebアプリケーションに外部からアクセスし、応答や挙動を確認して脆弱性を検査する。
イ. ソースコードを実行せずに解析し、危険な書き方や脆弱性につながる実装を検出する。
ウ. 社内ネットワークへ接続する端末のセキュリティ状態を確認し、条件を満たす端末だけ接続を許可する。
エ. 問題を引き起こしそうな多様なデータを自動生成し、ソフトウェアに入力して異常動作を確認する。

回答と解説を表示

正解は **イ** です。 SASTは、ソースコードを実行せずに解析し、危険な書き方や脆弱性につながる実装を検出する検査手法です。アはDAST、ウは検疫ネットワーク、エはファジングに近い説明です。

🔗 関連記事

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