SAST（静的アプリケーションセキュリティテスト）とは？コードの脆弱性を開発段階で発見する仕組みと主要ツール解説

「セキュリティレビューは本番リリース直前にしか実施していない」「脆弱性が見つかるたびにリリーススケジュールが押して困っている」——そんな悩みを抱える開発チームや情シス担当者は少なくありません。

脆弱性を修正するコストは、開発フェーズで発見した場合と比べ、本番環境で発見した後に対応すると最大30倍以上に跳ね上がるとも指摘されています。この差を埋めるのが、コードを実行しないまま静的に解析するセキュリティ手法「SAST」です。

この記事では、SASTの仕組み・代表的なツール・CI/CDパイプラインへの組み込み方・DASTとの使い分けまで、現場で使えるレベルで解説します。

SAST（静的アプリケーションセキュリティテスト）とは？

SAST（Static Application Security Testing）は、アプリケーションのソースコード・バイトコード・バイナリを実行せずに解析し、セキュリティ上の問題を検出する手法です。日本語では「静的アプリケーションセキュリティテスト」と呼ばれます。

アプリケーションを実際に動かして脆弱性を探すDAST（動的アプリケーションセキュリティテスト）と対をなす存在で、開発の早い段階から脆弱性を検出できる「シフトレフト」アプローチの中核を担います。

「内側から」コードを見るためホワイトボックステストとも呼ばれ、開発者がコードをコミットしたタイミングで自動スキャンをかけることが理想的な運用です。

DASTとの違いをひとことで表すと

SASTが検出できる脆弱性の種類

SASTは主にコーディングレベルの脆弱性を検出します。代表的なものを見てみましょう。

・インジェクション系（SQLインジェクション・OSコマンドインジェクション）: ユーザー入力をサニタイズせずにクエリや命令に組み込んでいるコードパターンを検出します。
・XSS（クロスサイトスクリプティング）: ユーザー入力をエスケープせずにHTMLへ出力している箇所を静的に特定できます。
・ハードコードされた認証情報: ソースコード中に埋め込まれたパスワードやAPIキーを発見します。
・安全でない乱数生成: セキュリティ用途に弱いRNG（JavaScript の Math.random() など）を使っているコードを検出します。
・安全でないデシリアライゼーション: 信頼できない入力をデシリアライズしている危険なパターンを特定します。
・バッファオーバーフロー（C/C++）: 境界チェックなしのメモリ操作を静的解析で洗い出します。

ただし、SASTはコードの「構造」を見るため、実行時にしか現れない脆弱性（認証ロジックの論理的欠陥・Webサーバーの設定ミスなど）は検出が苦手です。DASTや手動診断と組み合わせることが重要です。

SASTの仕組み——コードをどう解析するか

SASTツールは大まかに次のステップで解析を進めます。

1. 字句解析・構文解析（パース）

ソースコードをトークン化し、AST（抽象構文木）と呼ばれるデータ構造に変換します。人間が読むコードを、ツールが解析しやすい木構造に変換するステップです。

2. データフロー解析・テイント解析

「ユーザー入力がどこから来て、どこへ流れるか」を追跡します。入力（Source）が危険な処理（Sink）に渡る経路を特定するテイント解析が、インジェクション系脆弱性を検出する核心です。たとえば「HTTPリクエストのパラメータがSQLクエリにそのまま渡っている」といった経路を自動でトレースします。

3. ルールマッチング

既知の脆弱なコードパターンとのマッチングを行います。「このAPIの使い方は安全でない」「この関数は廃止されており代替手段がある」といったルールに照らして問題箇所をフラグします。

主要なSASTツールと特徴

現在利用できるSASTツールを、無料・商用・クラウドサービス別に整理します。

予算に制約のある中小企業や個人開発者であれば、SonarQube Community版、またはGitHub連携が前提であればCodeQLから始めるのが現実的です。

CI/CDパイプラインへの組み込み方

SASTの効果を最大化するには、開発者がコードをプッシュするたびに自動でスキャンが走る仕組みが必要です。

1. GitHub ActionsでCodeQLを使う例

# .github/workflows/codeql.yml（抜粋）
name: CodeQL Security Analysis
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

このワークフローをリポジトリに追加するだけで、プルリクエストごとにSASTスキャンが実行され、脆弱性がある場合はPRにコメントで通知されます。

2. Semgrepをローカルで試す

# インストール（pip経由）
pip install semgrep

# Pythonコードをルールセット「p/python」でスキャン
semgrep --config p/python ./src/

# OWASP Top 10向けルールでスキャン
semgrep --config p/owasp-top-ten ./src/

Semgrepはコミュニティがルールを公開しており、言語・フレームワーク・コンプライアンス基準別にルールセットを選べます。自社のコーディング規約に合わせたカスタムルールも数行のYAMLで作成できます。

中小企業でも今日からできること

「SASTは大企業向け」というのは誤解です。無料ツールを使えば、エンジニア1人の会社でも翌日から導入できます。

・まずSemgrepをローカルに入れてスキャンしてみる: 既存のコードベースに潜む問題を即座に可視化できます。まずは実態を把握することが第一歩です。
・GitHubを使っているならCodeQLを有効化する: パブリックリポジトリは無料。プライベートリポジトリも一定の無料枠があり、設定は数分で完了します。
・SonarQube Community版をDockerで立ち上げる: docker run -d --name sonarqube -p 9000:9000 sonarqube:community と実行するだけで手元に解析サーバーを構築できます。
・検出結果は全件対応しようとしない: 最初は「High/Critical のみ対応」と割り切ることで挫折を防げます。CVSS 7.0以上を優先するルールを設けましょう。

よくある誤解と注意点

【誤解1】SASTだけで脆弱性は網羅できる

SASTは強力ですが、実行時にしか現れない問題（認証の論理的な欠陥・Webサーバーの設定ミスなど）は検出できません。DASTや手動ペネトレーションテストと組み合わせて初めて「深い」セキュリティテストになります。

【誤解2】誤検知（False Positive）が多すぎて使い物にならない

SASTの弱点として誤検知率の高さがよく挙げられます。ただし、SemgrepやCodeQLのようにルールをカスタマイズできるツールであれば、自社コードに合わせたチューニングで誤検知を大幅に削減できます。「全アラートに対応するのでなく、まずチューニングする」という運用前提が重要です。

【誤解3】AIが生成したコードはSASTをすり抜ける

GitHub CopilotなどのAIが生成したコードにも、SQLインジェクションやXSSの脆弱なパターンが混入することが複数の研究で報告されています。AI生成コードも人間が書いたコードと同じようにSASTを通す運用が必要です。

本記事のまとめ

SASTは「開発者がセキュリティを自分ごとにする」文化を作る最初の一歩です。まずは無料ツールを一つ動かして、自社のコードベースの実態を把握するところから始めましょう。