DevSecOps

SAST

静的アプリケーションセキュリティテスト

Category: DevSecOps / Updated: 2026-05-26

📖

Overview

SAST(Static Application Security Testing:静的アプリケーションセキュリティテスト)とは、アプリケーションのソースコード、バイトコード、またはバイナリを実行せずに解析し、セキュリティ上の脆弱性を検出する手法です。「ホワイトボックステスト」とも呼ばれ、コードの内部構造を完全に可視化した状態で解析を行うことが特徴です。

SASTは開発ライフサイクルの早い段階で実施できるため、シフトレフトセキュリティの中核的な手法として広く採用されています。ソースコードが利用可能になった時点から解析が可能であり、アプリケーションの実行環境を用意する必要がないため、CI/CDパイプラインへの組み込みが容易です。SQLインジェクション、クロスサイトスクリプティング、バッファオーバーフローなどの一般的な脆弱性パターンを高速に検出できます。

一方で、SASTには偽陽性(False Positive)の多さという課題があります。コードの実行コンテキストを完全に把握できないため、実際にはセキュリティリスクとならない箇所を脆弱性として報告してしまうことがあります。偽陽性の管理と、検出結果のトリアージ(優先度付け)が、SASTを効果的に運用するための重要なポイントとなります。

🔬

Details

データフロー解析(Data Flow Analysis)

データフロー解析は、SASTの最も重要な解析技術のひとつです。プログラム内のデータが、入力(ソース)からどのような経路を辿って危険な操作(シンク)に到達するかを追跡します。例えば、ユーザーの入力値(ソース)がサニタイズされずにSQLクエリ(シンク)に渡されるパスを検出することで、SQLインジェクション脆弱性を発見します。

データフロー解析には、フォワード解析(ソースからシンクへの追跡)とバックワード解析(シンクからソースへの遡行)の2つのアプローチがあります。関数間・ファイル間をまたぐ解析(インタープロシージャル解析)は計算コストが高いですが、より正確な結果を提供します。

制御フロー解析(Control Flow Analysis)

制御フロー解析は、プログラムの実行パスを解析する技術です。条件分岐、ループ、例外処理などのプログラムの制御構造をグラフとして表現し、特定の実行パスにおけるセキュリティ上の問題を検出します。例えば、認証チェックが一部の実行パスでバイパスされるケースや、エラーハンドリングの不備によるリソースリークなどを発見できます。

制御フロー解析とデータフロー解析を組み合わせることで、「特定の条件が真の場合にのみ、未サニタイズのデータが危険な操作に到達する」といった複雑な脆弱性パターンも検出可能になります。

テイント解析(Taint Analysis)

テイント解析は、信頼できない外部入力(テイントされたデータ)がプログラム内でどのように伝搬するかを追跡する手法です。ユーザー入力、ファイルの読み取り、ネットワーク受信データなどを「テイントソース」としてマーキングし、これらのデータが適切なサニタイズ(テイント除去)を経ずにセキュリティ上重要な操作に到達するパスを検出します。

テイント解析の精度は、テイントソースとシンクの定義の網羅性、およびサニタイザー(テイントを除去する関数)の正確な特定に依存します。カスタムフレームワークやライブラリに対応するためには、ツールのルールセットをカスタマイズする必要があることも多いです。

パターンマッチング

パターンマッチングは、既知の脆弱なコードパターンをルールベースで検出する手法です。正規表現やAST(抽象構文木)ベースのマッチングにより、セキュリティアンチパターンを高速に検出します。例えば、ハードコードされたパスワード、安全でない暗号アルゴリズムの使用、非推奨API の呼び出しなどが代表的な検出対象です。

パターンマッチングはデータフロー解析と比較して計算コストが低く、高速に結果を得られる利点があります。一方で、コンテキストを考慮しないため偽陽性が多くなる傾向があります。SemgrepはAST ベースのパターンマッチングを採用し、開発者がカスタムルールを容易に記述できることで人気を集めています。

代表的なSASTツール

SonarQubeはオープンソースのコード品質・セキュリティ解析プラットフォームで、30以上のプログラミング言語をサポートしています。コード品質メトリクスとセキュリティ解析を統合的に提供し、Jenkins、GitLab CI、GitHub Actionsなどの主要なCI/CDツールとの連携が充実しています。

Checkmarxは商用の包括的なSASTプラットフォームで、高度なデータフロー解析とテイント解析を提供します。大規模なコードベースに対する高速スキャンと、低い偽陽性率が特徴です。Semgrepは、開発者フレンドリーなルール定義構文を持ち、カスタムルールの作成が容易なオープンソースの静的解析ツールで、特にCI/CDパイプラインでの利用に適しています。

偽陽性の管理と運用最適化

SASTの運用における最大の課題は偽陽性(False Positive)の管理です。偽陽性率が高いと、開発者がアラートに対して「疲れ」を感じ、真の脆弱性まで無視してしまう「アラート疲れ」を引き起こします。効果的な偽陽性管理には、検出結果の重大度分類、既知の偽陽性のサプレッション、ルールのチューニングが不可欠です。

最新のSASTツールではAI/MLを活用した偽陽性フィルタリングや、DASTの結果との相関分析による確度向上(IAST:Interactive Application Security Testing)など、偽陽性削減のための技術が急速に進化しています。組織固有のコーディングパターンに合わせたルールのカスタマイズも、偽陽性削減に大きく寄与します。

🛡️

Security Measures

  • 01
    CI/CDパイプラインへのSASTの統合:コードがコミットまたはプルリクエストされるたびにSASTスキャンを自動実行してください。重大な脆弱性(Critical/High)が検出された場合にはマージやデプロイをブロックするセキュリティゲートを設定し、脆弱なコードが本番環境に到達することを防止しましょう。
  • 02
    偽陽性の体系的な管理とルールチューニング:SASTの検出結果を定期的にレビューし、偽陽性と判定されたものは適切にサプレッションしてください。組織のコーディング規約やフレームワークに合わせてルールをカスタマイズし、偽陽性率を継続的に低減させることで、開発者のアラート疲れを防止しましょう。
  • 03
    インクリメンタルスキャンの活用:フルスキャンはコードベース全体を対象とするため時間がかかりますが、変更されたファイルのみを対象とするインクリメンタルスキャンを活用することで、プルリクエスト時の待機時間を大幅に削減できます。フルスキャンは定期的(日次や週次)に実施する運用としましょう。
  • 04
    カスタムルールの整備とメンテナンス:組織固有のセキュリティポリシーやフレームワーク固有の脆弱性パターンに対応するカスタムルールを作成してください。Semgrepなどのツールでは、開発チーム自身がルールを定義・メンテナンスできるため、自社のコードベースに最適化された検出が可能です。
  • 05
    DASTやSCAとの組み合わせによる多層的な検出:SASTはソースコードレベルの脆弱性検出に特化していますが、実行時の脆弱性やサードパーティライブラリの脆弱性はカバーできません。DAST(動的解析)やSCA(ソフトウェア構成分析)と組み合わせることで、検出のカバレッジを最大化してください。
  • 06
    検出結果のトリアージプロセスの確立:SASTの検出結果を効率的にトリアージするプロセスを確立してください。脆弱性の重大度、攻撃可能性、ビジネスインパクトに基づいた優先度付けを行い、限られたリソースで最もリスクの高い脆弱性から対応する体制を構築しましょう。
⚠️

Incidents

📋 Heartbleed脆弱性とSASTによる検出可能性(2014年)

2014年に発見されたOpenSSLのHeartbleed脆弱性(CVE-2014-0160)は、バッファオーバーリードにより、サーバーのメモリ上の秘密鍵やパスワードなどの機密情報が漏洩する重大な脆弱性でした。この脆弱性はOpenSSLの数万行のコードの中で約2年間発見されずに潜伏していました。

事後の分析では、高度なデータフロー解析を備えたSASTツールを使用していれば、入力バッファの長さと実際のペイロード長の不整合を検出できた可能性が指摘されています。この事例は、オープンソースプロジェクトにおいてもSASTの自動実行を導入し、コードの変更ごとにセキュリティ解析を実施する重要性を示しています。

📋 SASTのアラート疲れによる重大脆弱性の見逃し

ある大手ソフトウェア企業において、SASTツールが月間数千件のアラートを出力していたにもかかわらず、偽陽性の多さから開発チームがアラートを体系的にレビューしていませんでした。その結果、SASTが正しく検出していたSQLインジェクション脆弱性が数ヶ月間放置され、攻撃者に悪用されてデータベース内の顧客情報が漏洩しました。

この事例は、SASTツールを導入するだけでは不十分であり、適切な偽陽性管理、ルールのチューニング、トリアージプロセスの確立が不可欠であることを示しています。事件後、同社はSASTのルールを大幅にチューニングし、アラート数を90%削減しつつ、重大な脆弱性の検出率を維持する運用改善を実施しました。

📋 カスタムフレームワーク未対応によるインジェクション脆弱性の検出漏れ

社内で開発された独自のWebフレームワークを使用していた金融機関において、SASTツールがフレームワーク固有のサニタイズ関数を認識できず、適切にサニタイズされたコードを脆弱として報告する一方、フレームワーク固有の入力パスからのインジェクション脆弱性を検出できないケースが発生しました。

この問題は、SASTツールのデフォルトルールセットがカスタムフレームワークに対応していなかったことが原因です。対策として、フレームワークのソース・シンク・サニタイザーを定義したカスタムルールの作成、およびDASTによる実行時検証の併用が導入されました。SASTツールの導入時には、使用するフレームワークへの対応状況を必ず確認することが重要です。

🔗

Related Terms