--- title: "SASTとは？ソースコードを実行せずに検査する仕組み【SG試験】" description: "SASTは、ソースコードを実行せずに解析し、危険な書き方や脆弱性につながる実装を見つける検査手法です。SG試験で迷いやすいDASTや動的解析との違いを整理します。 試験対策として重要語の定義・具体例・よくある誤解をまとめ、短時間で復習できるように整理しています。" last_modified_at: "2026-05-18" canonical_url: "https://stemtazoo.github.io/sg/sast/" section: "sg" --- ## まず結論 - **SAST**とは、ソースコードを実行せずに解析し、脆弱性につながる危険な書き方や実装ミスを見つける検査手法です。 - SG試験では、**「動かして確認する」のではなく「ソースコードを見て確認する」**点で判断します。 ## 直感的な説明 SASTは、プログラムを動かす前に、ソースコードを読んで危ない部分を探す検査です。 たとえば、建物にたとえると、完成後に入って確認するのではなく、設計図を見て問題がないか確認するイメージです。 - 設計図を見て確認する → SAST - 完成した建物に入って確認する → DAST ソフトウェアでも同じです。 SASTでは、プログラムを実行せずに、ソースコードや設定ファイルなどを解析します。 そして、次のような問題がないかを確認します。 - 入力値チェックが不足していないか - 危険な関数を使っていないか - 認証や認可の処理に問題がないか - 秘密情報をコード内に直接書いていないか - コーディング規約に反する書き方をしていないか つまり、SASTは**「動かす前に、コードの書き方から弱点を見つける」**手法です。 ## 定義・仕組み SASTは、Static Application Security Testing の略です。 日本語では、**静的アプリケーションセキュリティテスト**と説明されることがあります。 SASTでは、ソフトウェアを実行せずに、ソースコードや関連ファイルを解析します。 基本の流れは次のとおりです。 1. 検査対象のソースコードを用意する 2. SASTツールでコードを解析する 3. 危険な書き方や脆弱性につながるパターンを検出する 4. 検出結果を確認する 5. 必要に応じてコードを修正する SASTで検出しやすいものには、次のような例があります。 - SQLインジェクションにつながる可能性のある実装 - クロスサイトスクリプティングにつながる可能性のある実装 - バッファオーバーフローにつながる可能性のある処理 - ハードコードされたパスワードや秘密情報 - 入力値検証やエラー処理の不足 IPAのセキュア・プログラミング講座でも、ソースコードの静的検査ツールを使って脆弱性を比較的手早く検出する方法が紹介されています。詳しくは、IPAの[ツールの利用](https://www.ipa.go.jp/archive/security/vuln/programming/cc/chapter1/cc1-7.html)が参考になります。 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、ウは検疫ネットワーク、エはファジングに近い説明です。