SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説

SAST（Static Application Security Testing／静的アプリケーションセキュリティテスト）は、プログラムを実行せずにソースコードやバイトコードを解析し、脆弱性につながる書き方を検出する手法です。テスト環境を立ち上げる必要がないため、コードを書いた直後、あるいはプルリクエストの時点で指摘を返せます。一方で検出できる範囲には原理的な限界があり、アクセス制御の不備や業務ロジックの穴は静的解析だけでは捕まえられません。

この記事では、SASTの検査原理と検出範囲、DAST・SCA・IASTとの役割分担、Semgrep・SonarQube・CodeQLの選び分け、CI/CDへ差分スキャンとして組み込む手順、誤検知をさばく運用設計までを実装者の解像度で整理します。最後に、受託開発の現場でSASTを入れるべきか見送るべきかを条件付きで言い切ります。

まとめ：SASTの守備範囲とDAST・SCAとの役割分担

先に結論を示します。SASTは万能の脆弱性検査ではなく、担当領域がはっきり決まった道具です。3つの検査を代替関係で捉えると、必ずどこかに穴が残ります。

• SASTが見るのは自社が書いたコード：SQLインジェクション、コマンドインジェクション、パストラバーサル、資格情報の直書きなど、コードの書き方そのものに現れる欠陥を実行前に検出します。
• OSS依存はSCA、実行時の挙動はDASTが担当：npmやMavenで取り込んだライブラリの既知脆弱性はSCA、認証後の画面遷移やサーバー設定に起因する問題はDASTでなければ届きません。
• 導入の勘所は「全件スキャン」から降りること：既存の指摘をベースライン化し、新規・変更コードの差分だけをプルリクエストで検査する構成にしないと、開発者は指摘を読まなくなります。
• 見送る判断もある：数週間で捨てるPoCコード、対応言語外の実装、トリアージの担当を置けない体制では、導入しても検出結果が放置されるだけに終わります。

SASTの定義と検査原理｜ソースコードから検出できる脆弱性の範囲

SASTという言葉は、同じ「静的解析」でもセキュリティ観点に絞った検査を指します。まずは隣接する概念との境界を引きます。

SASTの定義とコード品質向けの静的解析ツールとの対象範囲の違い

静的解析という語は、コンパイラ警告やLinter、コーディング規約チェックまで含む広い意味で使われてきました。SASTはそのうち、検出結果をCWE（共通脆弱性タイプ一覧）やOWASP Top 10といったセキュリティ分類にマッピングする種類のものを指します。境界は「その指摘が攻撃者に悪用されうるか」です。

たとえば未使用変数やネストの深さは保守性の問題であり、SASTの対象ではありません。文字列連結で組み立てたSQLをそのまま実行している箇所は、CWE-89として扱われます。ツール側でも役割は分かれており、SonarQubeの集計はバグ・コードスメル・セキュリティホットスポットの3分類。手法全体の位置づけは静的解析とは何か？ソースコードを実行せずに品質を確保する手法で整理しています。

テイント解析とデータフロー追跡｜SASTが脆弱性を特定する内部処理

SASTの中核はテイント解析です。外部から入る値（source）に「汚染」の印を付け、その値がどの変数を経由してどこへ流れるかを追跡し、危険な処理（sink）に無検証のまま到達すれば警告を出します。間に無害化処理（sanitizer）が挟まれていれば汚染は解除されます。

この追跡を成立させるため、ツールはコードを抽象構文木に変換し、制御フローグラフとデータフローグラフを構築します。CodeQLはさらに踏み込み、コードベースをクエリ可能なデータベースに変換したうえでQLというクエリ言語で問い合わせる方式を採ります。関数をまたぐ追跡（インタープロシージャル解析）に対応するかどうかが、検出力の差として現れる部分です。

誤検知が生まれる理由もここにあります。フレームワーク独自のエスケープ関数をsanitizerとして認識できなければ、安全なコードでも汚染が残ったままになります。

検出しやすい脆弱性と苦手な領域｜OWASP Top 10:2025との対応

コード上のパターンとして現れる欠陥は、SASTの得意分野です。SQLインジェクション、OSコマンドインジェクション、クロスサイトスクリプティング、パストラバーサル、ハードコードされたAPIキーやパスワード、MD5やDESといった脆弱な暗号アルゴリズムの利用は、いずれも高い確度で拾えます。

逆に苦手なのは、コードの字面に現れない欠陥です。2025年12月に公開されたOWASP Top 10:2025では、A01 Broken Access Control（アクセス制御の不備）が2021年版に続いて1位を保ち、2021年版のA10だったSSRFはA01へ統合されました。全10カテゴリには248のCWEがマッピングされています。このA01は「誰がどのデータにアクセスしてよいか」という仕様の問題であり、静的解析には正解が与えられません。認可ロジックの取り違え、金額計算の順序、権限昇格につながる画面遷移も同様です。OWASPの各プロジェクトとの関係はOWASPとは？主要プロジェクトの全体像とアプリ開発への組み込み方で確認できます。

SASTとDAST・IAST・SCAの違い｜検査時点と検出範囲の分担

4つの手法は競合ではなく分業です。どこに何を任せるかを表と条件で確定させます。

SASTとDASTの違い｜内側からの解析と外側からの攻撃再現の分担

DAST（Dynamic Application Security Testing）は、稼働中のアプリケーションに対して外部から擬似攻撃を投げ、応答から脆弱性を判定します。ソースコードを見ないため言語に依存せず、実行環境やミドルウェアの設定不備も検出可能。代わりに、到達できなかった画面や分岐は検査対象から漏れます。

修正コストの差も無視できません。SASTは行番号まで指摘するため開発者がそのまま直せますが、DASTの指摘はリクエストから原因箇所を特定する作業が挟まります。両者の性質差は静的解析と動的テストの違いとは｜検出できるバグ・代表ツール・使い分けを比較でも扱っています。DAST側の検査原理・ツール選定・CI/CDへの配置はDASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説にまとめました。

SASTとSCAの違い｜自社コードとOSS依存で分かれる検査責任

SCA（Software Composition Analysis）は、依存パッケージの一覧を作り、既知脆弱性データベースと突き合わせる検査です。対象はpackage-lock.jsonやpom.xmlに並ぶ他人のコードであり、自社が書いた実装は見ません。TrivyやOSV-Scannerはこちら側の道具です。

現代のWebアプリはコード量の大半が依存ライブラリで占められるため、SASTだけを入れてSCAを持たない構成は穴が大きくなります。逆も同じで、依存を最新に保っていても自社コードの注入欠陥は残ります。SCAの出力を資産管理につなぐ考え方はSBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説にまとめました。

IASTとRASPの位置づけ｜4手法を併用する現実的な導入順序

IAST（Interactive Application Security Testing）は、アプリにエージェントを組み込み、実行中の内部データフローを観測します。SASTの精度課題とDASTの網羅性課題を同時に埋める設計ですが、対応言語が限られ、テストの実行そのものが前提になります。RASPは検知ではなく実行時の防御を担う仕組みで、検査手法とは別枠です。

導入順序は費用対効果で決まります。まずSCA、次にSAST、そのあとDAST、IASTは最後です。SCAは設定が軽く既知脆弱性という確度の高い指摘が返るため初手に向き、IASTはテスト自動化が整っていない組織では投資が回収できません。テストコードのカバレッジが5割に届かない段階でIASTを検討するのは早すぎます。

主要SASTツールの比較軸｜Semgrep・SonarQube・CodeQLの選び分け

ツール選定で見る軸は、対応言語・ルールの書きやすさ・費用・結果の持ち出しやすさの4つに集約されます。

OSSと商用のSASTツール比較｜対応言語と料金体系の判断材料

主要ツールの性格は次のように分かれます（2026年7月時点の公開情報）。

費用面で押さえておきたいのがGitHubの体系変更です。GitHub Advanced Securityは2025年4月1日付で、GitHub Secret Protection（月額19ドル／アクティブコミッター）とGitHub Code Security（月額30ドル／同）の2製品へ分割されました。プライベートリポジトリでCodeQLによるコードスキャンを回すなら後者の契約が必要になります。

ルール記述性で選ぶ｜YAMLルールとクエリ言語の学習コスト差

組み込みルールだけで足りるなら学習コストは論点になりませんが、社内固有の禁止事項を検査したい場合は差が出ます。Semgrepのルールは対象コードに似た形をYAMLで書くため、正規表現より読みやすく、レビューもしやすい形です。CodeQLのQLは習得に時間がかかる代わり、関数をまたぐ複雑な追跡条件を表現できます。

判断基準を1つ置きます。独自ルールを3本以上書く見込みがなければ、クエリ言語の習得コストは回収できません。その場合は既成ルールの質で選び、Semgrepの公開レジストリやSonarQubeの組み込みルールをそのまま使うほうが早く回ります。Semgrepの設計思想はSemgrepの基本概要と静的解析ツールとして選ばれる3つの理由で解説しています。

SARIF対応が決める結果集約とツール入れ替え時の移行コスト

複数のツールを併用すると、結果の形式がばらばらでは集約できません。ここで効いてくるのがSARIF（Static Analysis Results Interchange Format）です。v2.1.0は2020年3月27日付でOASIS標準となり、2023年9月にErrata 01が公開されました。

SARIFで出力できるツールは、GitHubのコードスキャン画面や各種ダッシュボードへそのまま流し込めます。将来ツールを入れ替える可能性があるなら、SARIF出力の可否は選定の必須条件に入れてください。独自形式にしか対応しないツールを選ぶと、集約基盤とトリアージ履歴を作り直す羽目になります。

CI/CDへのSAST組み込み設計｜差分スキャンとPRブロック基準

SASTが定着するかどうかは、検出力よりもCIへの組み込み方で決まります。

フルスキャンから差分検査へ｜CIへの組み込みを4段階で進める手順

既存プロジェクトにいきなりブロッキングで入れると、初回に数百件の指摘が出て開発が止まります。段階を踏みます。

1. 非ブロッキングでフルスキャンを1回実行し、指摘の総量と分布を把握する
2. 既存の指摘をベースラインとして登録し、以後は新規・変更コードの差分だけを検査する
3. 重大度の高い検出に限ってプルリクエストのマージをブロックする設定に切り替える
4. 週次または夜間にフルスキャンを回し、ベースライン分を計画的に減らす

2段階目のベースライン化を飛ばすと、担当者は既存コードの山に埋もれて新規の指摘を見落とします。順番の入れ替えは避けてください。

PRブロック基準の決め方｜Severity閾値と例外運用の線引き

ブロック条件は重大度だけで決めず、確信度との2軸で設計します。Semgrepならseverityとconfidence、SonarQubeなら品質ゲートの条件がこれに該当。実務では「重大度High かつ 確信度High の新規検出のみブロック」から始めると、開発を止めずに効果が出ます。

例外を認める運用も先に決めておきます。抑制する場合は理由をコードコメントに残し、抑制自体をレビュー対象にする。この2つを外すと、締切前に無条件で抑制する慣習が定着します。

スキャン時間の抑え方｜モノレポでの並列分割実行とキャッシュ設計

スキャンが10分を超えると、開発者はCIの完了を待たずに次の作業へ移ります。モノレポでは変更されたディレクトリを検出してサービス単位に分割し、並列ジョブとして流すのが現実的です。

言語によってはビルドが前提になる点も設計に響きます。CodeQLはJavaやC#、C++といったコンパイル言語でビルドを伴う解析を行うため、依存解決のキャッシュを効かせないと待ち時間が延びます。テストコードや自動生成コードを解析対象から除外する設定も、初期段階で入れておきたい調整の一つ。

SASTの誤検知と運用設計｜トリアージ体制と抑制コメントの基準

SASTが放置される最大の理由は誤検知です。ゼロにはできない前提で、さばく仕組みを作ります。

誤検知率の実像とトリアージ体制｜検出結果を仕分ける担当と頻度

SASTツールの精度を測る取り組みとして、OWASPはBenchmarkというJava製の実行可能テストスイート（v1.2系）を公開しています。すべての脆弱性が実際に攻撃可能な形で埋め込まれており、真陽性率と偽陽性率の差で各ツールを評価する設計です。ここで示されるとおり、検出力と誤検知は基本的にトレードオフの関係にあります。

運用側で必要なのは、検出結果を仕分ける定例枠です。週1回30分、セキュリティに明るい開発者が新規検出を「修正する／抑制する／様子を見る」に分類する。担当を全員の持ち回りにすると判断基準がぶれるため、まずは固定してから引き継ぐ形が回ります。

抑制コメントの書き方と乱用の防止｜nosemgrepとNOSONARの扱い

誤検知と判断した箇所は、ツールの抑制機能で個別に消します。Semgrepはnosemgrep、SonarQubeはNOSONARをコード内のコメントに記述する方式です。CodeQLでもアラート単位で却下の記録を残せます。

乱用を防ぐ手立ては3つあります。抑制コメントには必ず理由を併記させること、抑制行を含む差分はレビューで個別に確認すること、抑制の総数をスプリントごとに計測して増加傾向を見ることです。3つ目を入れておくと、静かに膨らむ抑制に気づけます。

チケット化する検出と見送る検出の線引き｜開発者が使い続ける条件

すべての検出をチケット化すると、バックログが機能しなくなります。線引きの基準を置きます。外部から到達可能な入力を扱う箇所、認証・認可・決済に関わる箇所、個人情報を扱う箇所の検出はチケット化する。それ以外の中低重大度は、次に同じファイルを触るときに直す方針で構いません。

SASTを開発者が使い続ける条件は単純です。指摘の8割以上が「直すべき指摘」であること。この比率を割ったら、ルールセットを絞る側に舵を切ってください。

SASTを導入すべき現場と見送る現場｜受託開発での採用条件と判断基準

ここからは判断です。導入が成果につながる条件と、投資が無駄になる条件を分けて示します。

SASTを採用する条件｜対応言語・コード量・リリース頻度の目安

次の条件が2つ以上そろうなら、SASTは入れる価値があります。インターネットに公開されるアプリケーションであること。個人情報や決済情報を扱うこと。開発者が5名以上でコードレビューが形骸化しはじめていること。月に複数回リリースしていること。

言語も判断材料になります。JavaやC#、TypeScriptのように型情報が豊富な言語ではデータフロー追跡の精度が出やすく、動的型付けで動的なメソッド呼び出しが多い実装では取りこぼしが増えます。PHPやPython中心の開発では、SASTに期待する検出範囲をあらかじめ下方修正しておいてください。

SASTが過剰になる場面｜見送るべき3条件と典型的な失敗の型

見送るべき条件を明示します。第一に、数週間で破棄する検証用コードや社内限定のバッチ処理だけを書いている場合。第二に、主要な実装言語がツールの対応範囲外である場合。第三に、検出結果を仕分ける担当を置けない場合です。3つ目が特に致命的で、担当不在のまま導入すると数か月後には誰もダッシュボードを開かなくなります。

失敗の型も繰り返し目にします。初日から全件ブロッキングで有効化してリリースを止めてしまうパターン。ルールを全部オンにして誤検知の山を作り、開発者の信頼を失うパターン。そしてSASTを理由に脆弱性診断を省くパターン。最頻出のアクセス制御不備が未検査のまま残ります。

受託開発でのSAST運用｜脆弱性診断との併用と契約上の線引き

受託開発では、検査の責任分界を契約段階で決めておく必要があります。SASTで検査するのは受託側が書いたコード、SCAで扱うのは採用したOSSライブラリ、実行環境やインフラ設定は発注側の運用範囲、といった切り分けです。ここが曖昧なまま納品すると、リリース後に見つかった設定不備の責任所在で揉めます。

実務としては、開発中はCIでSASTとSCAを回し、リリース前に手動の脆弱性診断を挟む構成が現実的です。ツールが原理的に検出できないアクセス制御の不備や業務ロジックの穴は、診断員の手作業でしか埋まりません。設計段階からの検査体制づくりを外部に相談するなら、脆弱性診断・セキュリティ診断のように、ツール導入と手動診断の両方を扱える相手を選ぶと工程がつながります。

よくある質問

SASTの導入検討でよく挙がる質問をまとめました。

SASTは無料で始められますか？

始められます。SemgrepにはコマンドラインのOSS版があり、SonarQubeにも無償のCommunity Buildが用意されています。CodeQLは公開リポジトリであれば無償で利用でき、プライベートリポジトリの場合はGitHub Code Security（2026年7月時点で月額30ドル／アクティブコミッター）の契約が必要です。まずはOSS版をローカルで回し、指摘の質と量を確かめてからCIへ組み込む順序をおすすめします。

SASTとコードレビューはどちらを優先すべきですか？

両方必要ですが、役割が違います。SASTは注入系や資格情報の直書きといった機械的に判定できる欠陥を漏れなく拾うのが仕事で、レビュアーの体調や締切に左右されません。一方、権限設計の妥当性や業務ロジックの正しさは人間のレビューでしか判断できません。SASTを入れる目的は、レビュアーを機械的な確認から解放し、設計の議論に時間を回すことです。

誤検知が多すぎて運用できません。どこから直せばよいですか？

ルールセットの絞り込みから着手します。全ルールを有効にしている場合は、まず自社の技術スタックに関係しないルール群を無効化してください。次に、テストコードと自動生成コードを解析対象から除外します。この2つで検出数が半分以下になることも珍しくありません。それでも多いなら、ブロック条件を重大度Highかつ確信度Highに限定し、残りはレポート表示だけに留めます。

AIが生成したコードにもSASTは効きますか？

効きます。生成AIが書いたコードも文字列連結によるSQL組み立てやエスケープ漏れといった典型パターンを含むことがあり、テイント解析の対象としては人間が書いたコードと変わりません。生成量が増えるほどレビューの目は届かなくなるため、CIでの自動検査の価値は上がります。ただし検出範囲の限界は同じで、生成されたアクセス制御ロジックの妥当性は判定できません。

SASTを入れれば脆弱性診断は不要になりますか？

なりません。OWASP Top 10:2025で1位のA01 Broken Access Controlは仕様の理解を前提とするため、静的解析では原理的に判定できない領域です。SASTはコードの書き方に起因する欠陥を早期に潰す道具、脆弱性診断はリリース前に実環境で穴を探す工程であり、時点も対象も異なります。予算配分としては、CIでSASTとSCAを常時回しつつ、年1回または大規模改修時に手動診断を入れる形が現実解です。

関連記事

• GitHub Code Scanningとは？CodeQLの仕組み・設定方法・料金を解説：CodeQLでSASTを回す具体的な設定手順を扱っています。
• SonarQube（ソナーキューブ）とは？できること・対応言語・料金とSonarLintとの違いをわかりやすく解説：エディション差と対応言語の比較に役立ちます。
• DevSecOpsとは？DevOpsとの違い・ライフサイクル・導入判断を実装視点で解説：SASTを組み込む前提となる開発プロセス設計を解説しています。
• OWASP ZAPの診断項目とは？検出できる脆弱性一覧と使い方：DAST側の代表ツールで、SASTとの併用時の参考になります。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：手動診断との併用を検討する際の費用感がわかります。