SASTとは何か？仕組み・導入メリット・他手法比較まで実務で使える完全ガイド

「SASTとは何か。導入すべきか。誤検知で回らないのでは」——そんな不安、ありませんか。

SASTとは、実装段階で脆弱性の芽を早期に潰し、コストと手戻りを抑える静的解析です。

本記事は、仕組みと他手法との違い、ツール選定の勘所、CI/CDへの最短統合、運用の落とし穴と解決策、AI活用までを実務目線で解説します。

外資系エンジニア

この記事は以下のような人におすすめ！

SASTとは何か具体的に知りたい人

自社に最適なSASTの選び方が分からない

SASTとDAST/IAST/SCAの使い分けが曖昧でわからない

1 SASTとは何か
- 1.1 1-1. 定義と基本の考え方
- 1.2 1-2. 静的解析と動的解析の違い
2 SASTの仕組み・内部で何が起こっているか
- 2.1 2-1. コード解析の主な手法（構文解析・データフロー解析など）
- 2.2 2-2. スキャン対象（ソースコード／バイトコード／バイナリ）
3 SASTのメリット・デメリット
- 3.1 3-1. 導入による利点（早期発見、コスト削減、品質向上など）
- 3.2 3-2. 課題・限界（誤検知、文脈理解不能、解析コストなど）
4 他のセキュリティテスト手法との比較・併用
- 4.1 4-1. DAST（動的アプリケーションセキュリティテスト）との違い
- 4.2 4-2. IAST／SCAなどとの関係と使い分け
5 SASTを実務で使うには
6 最新トレンド・将来展望と活用アイデア
- 6.1 6-1. AI／機械学習との融合、自動化の動き
- 6.2 6-2. SASTの今後に向けた戦略

SASTとは何か

「SASTとは（Static Application Security Testing）」、すなわち静的アプリケーションセキュリティテストの略称です。

アプリケーションを実行せずにソースコードやバイトコードを解析し、脆弱性やセキュリティ上の欠陥を早期に洗い出す手法を指します。

つまり、開発途中のコードを“読み解く”ことで、SQLインジェクションやハードコードされた秘密情報、入力値の未検証といった問題を、テスト環境や本番環境に到達する前に見つけます。

したがって「SASTとは何か」を理解することは、開発スピードを落とさずに品質とセキュリティを両立させる第一歩になります。

1-1. 定義と基本の考え方

1-1-1. SASTとは：一言でいうと

SASTとは、プログラムを実行しない“静的解析”により、コード上の不具合やセキュリティ上の弱点を検知するテスト手法です。

なぜなら、コードの構造（構文）やデータの流れ（データフロー）を規則に照らして検査することで、実行して初めて現れる問題の前段階で多くの欠陥を把握できるからです。

1-1-2. ねらいと価値：早期発見でコストを下げる

早期発見・修正
設計・実装フェーズで不具合を潰すため、修正コストが低く、リリース遅延も最小化できます。
品質の底上げ
セキュアコーディング規約の逸脱やアンチパターンの常態化を防ぎます。
継続的な可視化
プロジェクト全体の「セキュリティ負債」を定量的に把握し、傾向を追跡できます。
その結果、セキュリティと生産性のトレードオフを緩和し、開発チームの“安全に速く作る”を支援します。

1-1-3. SASTの主な検出例

典型的な脆弱性：SQLインジェクション、コマンドインジェクション、XSS など
安全でないコーディング：未初期化の変数、危険な関数呼び出し、例外の握りつぶし
機密情報漏えいの芽：APIキーやパスワードのハードコード
認可・バリデーションの抜け：入力チェック不足、認可前提の欠落ロジック

1-1-4. SASTと“似て非なる”活動

コードリンター：主にスタイルや一般的なバグ検出。SASTはセキュリティ観点に特化し、より深いデータフロー解析を行います。
コードレビュー：人が文脈を踏まえて評価。SASTは広範囲を機械的に網羅。併用で相互補完が有効です。
ユニットテスト：仕様どおりの動作確認。SASTは「仕様の内外で起こり得る危険」を静的に点検します。

1-2. 静的解析と動的解析の違い

1-2-1. アプローチの違いを俯瞰する

SAST（静的解析）とDAST（動的解析）は“いつ・何を・どう検査するか”が大きく異なります。以下の表で要点を整理します。

観点	静的解析（SAST）	動的解析（DAST）
解析対象	ソースコード／バイトコード	実行中のアプリ（ブラックボックス）
実行の有無	実行しない	実行する（テスト環境が必要）
得意領域	コード上の脆弱性の早期検知、広い網羅性	実行時設定・ランタイム依存の問題発見、実攻撃に近い検証
苦手領域	実行時のみ顕在化する問題	到達困難な分岐や網羅性の確保
導入ポイント	開発初期からCIで常時	テスト段階でシナリオ設計と併用
成果物	ルール違反の箇所、修正候補の指摘	実行時の振る舞いとエビデンス
誤検知/見逃し	規則ベースゆえ誤検知が出やすい	環境依存で見逃しが起き得る
カバレッジ	コード全体（解析可能な範囲）	実行パスとテストケースに依存
速度/コスト	比較的高速、修正コストが低い	環境準備と運用コストが発生

つまり、「SASTとはコード起点で欠陥を早期に発見するための仕組み」であり、一方で「DASTは実行時の挙動から実被害につながる欠陥を洗う」アプローチです。

1-2-2. 使い分けの考え方

早い段階で“埋め込み型の欠陥”を見つけたい → SASTを優先
実行環境や設定に起因する問題も洗いたい → DASTを併用
規模が大きく変更頻度が高いプロジェクト → SASTをCIに常設し、プルリクごとに自動スキャン
リリース前の最終確認 → DASTで実攻撃に近い観点を追加
したがって、どちらか一方ではなく、目的とフェーズに合わせて組み合わせるのが合理的です。

1-2-3. 併用のベストプラクティス

開発フローへの自然な組み込み
SASTはプリプッシュ／プルリク時に自動実行。軽量ルールで素早くフィードバック。
ノイズ削減とチューニング
誤検知は抑制ルールや除外設定を整備し、重大度基準をチームで合意。
継続的な可視化
メトリクス（検出件数、修正までの時間、再発率）をダッシュボード化し、改善サイクルを回す。
他手法との統合
DAST、SCA（依存関係の脆弱性）、IaCスキャンなどと合わせ、ソフトウェア供給網全体をカバー。

SASTの仕組み・内部で何が起こっているか

「SASTとは何か」を一段深く理解するためには、ツール内部でどのような処理が連鎖して脆弱性を見つけているのかを知ることが近道です。

つまり、SASTとは単なる“コードのあら探し”ではなく、解析エンジンが複数の手法を組み合わせ、コードの意味やデータの流れを機械的に読み解く高度な工程なのです。

以下では、その中心となる解析手法と、スキャン対象の違いを整理します。

2-1. コード解析の主な手法（構文解析・データフロー解析など）

2-1-1. まずは前処理：トークナイズと構文解析

SASTとは、最初にソースコードを「意味のある最小単位（トークン）」へ分解し、言語の文法どおりに木構造（AST：抽象構文木）へ組み立てるところから始まります。

トークナイズ：キーワード、識別子、演算子、リテラルへ切り分ける
構文解析：ASTを生成し、文と式、関数やクラスの関係を機械が理解できる形へ
ねらい：表層的な文字列検索ではなく「意味」を扱う準備を整える

2-1-2. 制御フロー解析：プログラムの“道筋”を描く

次に、プログラムがどの順序で実行され得るかをグラフ化（CFG：制御フローグラフ）します。

if / switch / 例外処理などの分岐を網羅
関数呼び出しや戻りの関係を可視化
その結果、到達可能性や未実行コード、危険な分岐の経路が見えます

2-1-3. データフロー解析：入力が“どこから来て、どこへ行くか”

SASTとは、とりわけデータフロー解析が要です。外部入力（汚染データ）が検証されずに危険な関数へ到達する“経路”を追跡します。

汚染源（source）：HTTPパラメータ、環境変数、メッセージキューなど
検証（sanitizer）：エスケープ、バリデーション、型変換
シンク（sink）：SQL実行、OSコマンド、テンプレート出力、ファイル操作

簡単な例を示します。

// 疑似コード：ユーザー入力 → 検証なし → SQLへ
name = request.getParam(“name”) // source
query = “SELECT * FROM users WHERE name='” + name + “‘” // 結合
db.execute(query) // sink

この場合、検証を挟まない経路があれば、SQLインジェクションの可能性ありとしてフラグ化されます。

2-1-4. ルールベース検出とパターンマッチ

ルールセット：CWEなどの分類に基づく危険パターンを定義
言語・フレームワーク特化：例えば ORM の安全APIと非推奨APIを区別
したがって、SASTとは汎用ルールとプロジェクト特有のルールを合わせて“誤検知を抑えつつ網羅性を上げる”運用が肝要です。

2-1-5. 追加テクニック：シンボリック実行や型推論

近年のSASTは、軽量なシンボリック実行で条件分岐の可否を推定したり、型の流れを推論して危険な型変換を検出
インタープロシージャ解析（関数・モジュール間）で現実的なデータ到達性を精密化

2-1-6. 結果の正規化・優先度付け・重複排除

実務では「見つける」だけでは不十分です。だからこそ、

重大度・確度の評価（High/Medium/Low）
重複の束ね（同根事象の一括提示）
SARIF など標準フォーマット出力 → CI や課題管理へ連携
といった後処理が、運用効率を左右します。

2-2. スキャン対象（ソースコード／バイトコード／バイナリ）

SASTとは“静的解析”の総称ですが、実際には「何を」解析するかで得意・不得意が変わります。

ここでは、代表的な三つの対象の違いを整理します。

2-2-1. 対象ごとの比較表

対象	例	強み	弱み	向いているケース
ソースコード	Java, JS/TS, Python, Go, C/C++ など	意味情報が豊富。コメントや型ヒント、フレームワーク文脈を活用しやすい	ビルド生成物との差異やプリプロセス後の姿は別途考慮が必要	開発初期からの継続スキャン、規約違反の検出
バイトコード	JVM（.class, .jar）, .NET（IL）	実際に配布されるアーティファクトに近い。言語差を吸収しやすい	ソース固有の意図・コメントが失われる	ライブラリ混在の大規模プロジェクト、言語横断の一括検査
バイナリ	ELF, PE, 逆アセンブル結果	ソースが無い場合でも解析可能。サプライチェーンの検証に有効	抽象度が低く、精度確保が難しい。時間と専門知識が必要	クローズドソース、配布物の最終検証、レガシー資産の棚卸し

つまり、ソースコード解析は“文脈を深く理解して早期に修正”しやすく、バイトコードやバイナリ解析は“最終成果物に近い視点で漏れを拾う”のに向いています。

したがって、開発フローではソース中心、リリース前や監査ではバイトコード／バイナリも併用する設計が現実的です。

2-2-2. 解析対象が変わると、見える問題も変わる

ソースコード：ハードコード秘密情報、危険API呼び出し、入力検証抜け、ロジック上の欠陥
バイトコード：難読化や最適化後の呼び出し関係、依存関係の結合状況
バイナリ：実行ファイルの権限設定、メモリ操作まわりのリスク（ヒープ/スタック）、デバッグ情報漏えい

2-2-3. 現場での使い分けガイド

変更が頻繁なアプリ本体 → ソース解析を毎コミットで回す
外部配布ライブラリやプラグイン → バイトコード解析を併用
サードパーティ製バイナリやレガシー実行ファイル → バイナリ解析で最終物を点検

2-2-4. 実務パイプラインのひな型

最後に、運用の全体像を短くまとめます。SASTとは、次のような“流れ”で回すと効果が高まります。

プリプッシュ／PR作成時：軽量ルールで高速スキャン
マージ前：データフロー中心の深めのスキャン、重大度判定
ナイトリービルド：バイトコードや一部バイナリも含めた広範囲スキャン
結果連携：SARIF でCI、課題管理、ダッシュボードへ自動連携
チューニング：誤検知抑制、ルールのローカライズ、再発防止の教育

SASTのメリット・デメリット

まず押さえておきたいのは、「SASTとは開発の早い段階でコードの欠陥を見つけるための静的解析」であり、導入の良し悪しを理解することが最適な運用設計につながるという点です。

つまり、利点と限界を同時に把握してこそ、SASTは最大の効果を発揮します。

3-1. 導入による利点（早期発見、コスト削減、品質向上など）

3-1-1. 早期発見で“被害前”に手を打てる

SASTとは、プルリクやマージ前に脆弱性の“芽”を見つける仕組みです。

なぜなら、実行せずにコードのデータフローや危険APIの利用を検知できるため、運用環境で問題が顕在化する前に対処できるからです。

その結果、障害の連鎖やインシデント対応の手戻りを断てます。

3-1-2. コスト削減：修正は“早いほど安い”

欠陥の修正コストは、要件→設計→実装→テスト→本番と後ろに行くほど膨らみます。SASTとは、このコスト曲線を根元から圧縮する打ち手です。

したがって、導入直後は検出件数が増えたように見えても、数スプリント後には「重大インシデントの発生率」と「緊急対応工数」が目に見えて下がります。

3-1-3. コード品質の底上げと技術的負債の抑制

ルールに基づく指摘は、個人差の大きいコードレビューを補完します。つまり、SASTとはセキュアコーディングの基準を“自動で言語化”し、組織全体の品質ばらつきを減らす役割も果たします。

3-1-4. 開発スピードと開発者体験の向上

素早いフィードバックは学習効果を高めます。軽量スキャンをPR作成時に走らせれば、開発者は“その場で直せる”ため、レビュー待ち時間ややり直しが減ります。

その結果、ベロシティを落とさずに安全性を高められます。

3-1-5. コンプライアンス対応と監査のしやすさ

SASTの結果をSARIFなど標準形式で蓄積すれば、監査証跡が整います。

したがって、規制産業や顧客監査において「継続的にSASTとは何をチェックしているか」を明示でき、信頼性の訴求につながります。

3-1-6. ナレッジ共有と教育効果

同じルールで全員が指摘を受けるため、属人化が薄まります。再発防止の観点で、検出ルールと修正例を社内ドキュメントへ還流すれば、チームの“セキュアな作り方”が組織知として蓄積されます。

利点の要点まとめ

早期発見により本番インシデントを予防
修正コストと緊急対応を削減
品質基準の自動化でばらつきを縮小
監査・説明責任に強いエビデンスを確保

3-2. 課題・限界（誤検知、文脈理解不能、解析コストなど）

3-2-1. 誤検知（False Positive）のノイズ

SASTとはルールベースや静的推論に依存するため、実行時には問題にならないケースを指摘することがあります。

だからこそ、除外設定（抑制アノテーション）、ルールのチューニング、重大度基準の合意が不可欠です。

3-2-2. 文脈理解の限界と“見逃し”

静的解析だけでは、設定値や実行環境依存の問題（実行時の権限、ネットワーク構成、シークレットの取扱いなど）を取り切れません。

したがって、SASTとは DAST・SCA・IaC スキャンと補完関係にあり、単独での完全性は期待しすぎない設計が現実的です。

3-2-3. 解析コストとパフォーマンス

大規模リポジトリでは、深い解析は時間を要します。CIが遅くなると開発体験が落ちるため、

PR時は軽量ルール、本線マージ前に深いルール
差分スキャンの活用
夜間にフルスキャンを定期実行
といった運用分割が有効です。

3-2-4. カバレッジのギャップ

SASTとは主にコードを対象にします。テンプレート、設定ファイル、インフラコード、ランタイム設定などは別系統の検査が必要です。

結果として、全体の安全性は“複数ツールの合奏”で担保します。

3-2-5. ツール運用・チューニング負荷

初期は検出が多く、現場から「ノイズが多い」という反発が起きがちです。

だからこそ、トップ10の重大欠陥に集中してクイックウィンを示し、段階的にルールを厳格化するロードマップを示すと定着しやすくなります。

3-2-6. 組織文化との摩擦

“品質・セキュリティを先に担保する”文化が弱いと、SASTの優先度が下がります。

経営・PO・開発の合意形成（SLAs、品質ゲート、KPIの設定）を先に整えることが、実は技術的施策より効くことがあります。

3-2-7. よくある疑問に短答で答える

「SASTとは導入しても結局DASTが必要なのでは？」
そのとおりです。役割が違うため、併用が前提です。
「誤検知が多いと聞くが現実的？」
主要ルールの選別・除外パターンの整備で大幅に低減可能です。
「スキャンでCIが遅くなるのでは？」
差分スキャンと段階的ルールで緩和できます。フルスキャンは夜間へ。

3-2-8. メリット・デメリットの俯瞰表

観点	メリット（SASTとは…）	デメリット／限界	打ち手
タイミング	早期に欠陥を発見	実行時の問題は拾い切れない	DAST/SCA/IaCと併用
コスト	修正が安く早い	初期チューニングに手間	ルールの段階導入・差分スキャン
品質	組織の基準を自動化	誤検知でノイズ増	除外運用・重大度基準の統一
説明責任	監査証跡を残せる	単独では完全でない	ダッシュボードで全体最適を可視化

他のセキュリティテスト手法との比較・併用

まず前提として、「SASTとは開発中のコードを実行せずに解析して脆弱性を早期発見するための手法」です。

では、同じ“アプリケーションセキュリティテスト”でも、DAST・IAST・SCAは何が違い、どう組み合わせればよいのでしょうか。

ここでは、重複しがちな用語や役割を整理し、実務で迷わない使い分けと併用の型を示します。

4-1. DAST（動的アプリケーションセキュリティテスト）との違い

4-1-1. 目的とタイミングの違い

SASTとは：実行前のコードを静的に読み解き、設計・実装段階で“欠陥の芽”を摘むアプローチ。したがって、プルリクやマージ前の早いフェーズに最適です。
DASTとは：稼働中のアプリを外部から擬似攻撃して挙動を検証するアプローチ。つまり、テスト環境が整った後の検証やリリース前の最終確認に向いています。

4-1-2. 検出できる問題の差

観点	SAST	DAST
対象	ソース/バイトコード	実行中のアプリ（ブラックボックス）
得意	危険APIの使用、未検証入力、ハードコード秘密情報などのコード起点の欠陥	認証回りの抜け、設定ミス、実行時エラーなどランタイム依存の問題
苦手	設定・環境でのみ発生する不具合	到達しづらいコード分岐の網羅、ソースに埋まる設計上の欠陥
フィードバック速度	速い（PRごと）	シナリオ準備と環境依存で相対的に遅い

4-1-3. 実務での併用シナリオ

日常開発：PR作成時にSASTを自動実行。軽量ルールで素早い指摘。
機能結合〜リリース前：DASTで認証・権限・入力の想定外パスを重点確認。
結果の相互補完：SASTで“原因”を、DASTで“現象”を可視化。だから、両者の結果を課題管理でひも付けると修正が速くなります。

4-2. IAST／SCAなどとの関係と使い分け

4-2-1. IASTとは：実行しながらの内部観測

IAST（Interactive AST）は、アプリを動かしつつ内部にセンサーを仕込み、実行時のデータフローやコールスタックを観測する手法です。

SASTとの関係：SASTが“可能性”を広く拾うのに対し、IASTは“実際に通った経路”の事実を示します。
使いどころ：統合テストやUATで自然に実行されるシナリオと合わせると、誤検知を絞り込みやすくなります。
注意点：エージェント導入やオーバーヘッド、環境制約への配慮が必要です。

4-2-2. SCAとは：依存関係の脆弱性管理

SCA（Software Composition Analysis）は、OSSライブラリやコンテナの既知脆弱性・ライセンスを検出します。

SASTとの関係：SASTが“自分たちのコード”を、SCAが“持ち込んだ部品”をチェック。
使いどころ：ビルド時にSBOMを生成し、CVEの有無や更新推奨を自動判定。
注意点：脆弱性の“実際の到達性”はコード側（SAST/IAST）の文脈と突合すると優先度が付けやすいです。

4-2-3. いつ何を使うべきか（フェーズ別の指針）

開発フェーズ	主要目的	有効な手法	ポイント
実装開始〜PR	早期発見・再発防止	SAST	軽量ルールで差分スキャン、レビューの前段で自動化
結合・統合テスト	実行時の実害把握	IAST / DAST	実シナリオにエージェント適用、重要導線を重点計測
ビルド・リリース前	供給網・設定の健全性	SCA / コンテナスキャン	SBOM作成、既知脆弱性とライセンス適合性を確認
運用・継続改善	逸脱検知・回帰防止	SAST継続/DAST定期/IAST随時	ダッシュボードでKPI管理、品質ゲートで基準維持

4-2-4. 現場に落とす併用テンプレート（CI/CDの型）

PR作成時：SASTをトリガーし、重大度が一定以上ならマージブロック。
メインブランチ統合時：SCAで依存関係を検査し、SBOMをアーティファクト化。
ナイトリービルド：SASTフルルール＋コンテナ/イメージスキャンを広く実行。
結合テスト：主要E2EシナリオにIASTエージェントを適用。
ステージング：DASTで認証・権限・入力検証を重点攻撃。
レポート統合：SARIFや共通スキーマで集計し、重複を束ねて優先度を自動付与。

SASTを実務で使うには

実務に落とし込むときに重要なのは、「SASTとは単なるツール導入ではなく、開発フローと文化に溶け込ませる“仕組み化”である」という視点です。

つまり、選定→統合→運用改善を一気通貫で設計することで、初期のノイズやコストを最小化し、継続的な効果を引き上げられます。

5-1. ツール選定ポイントと代表例

5-1-1. まず決めるべき評価軸

SASTとは、プロジェクトの性質により“最適解”が変わる領域です。

したがって、最初に評価軸を明確化します。

対応言語・フレームワークの幅と深さ
誤検知率とチューニング手段（除外、カスタムルール）
開発者体験（IDE連携、PRコメント、修正ガイド）
CI/CD適合性（差分スキャン、SARIF出力、品質ゲート）
導入形態（SaaS／オンプレ）、機密コード取り扱いポリシー
ライセンス費用と運用工数（誰が面倒を見るか）

5-1-2. 言語・フレームワーク対応の見極め

同じ“対応”でも検出の深さが異なるため、主要スタックでの実サンプル検証が近道です。
つまり、テンプレートエンジン、ORM、シリアライゼーションなどフレームワーク固有の危険APIをどれだけ理解しているかが決め手になります。

5-1-3. 誤検知とチューニング能力

抑制アノテーション、パス単位除外、ルールの重大度変更が柔軟かを確認します。
その結果、初期段階から重大度の高いルールに集中しやすくなります。

5-1-4. 開発者体験とレポートの質

IDE内の即時フィードバック、PRへの自動コメント、修正例や関連CWEの提示は学習効果を高めます。
SARIFなどの標準形式を出せると、ダッシュボードや課題管理との連携が容易です。

5-1-5. セキュリティ・ガバナンス要件

ソースコードを外部へ送らない運用が必要か、オンプレ運用の可否を確認します。
複数リポジトリ・複数組織を横断するロール・監査証跡の整備も重要です。

5-1-6. 代表的なタイプ（例を挙げる観点）

SaaS型：セットアップが容易。スケールやメンテが軽い。
自前ホスト型／OSS：データ主権を確保しやすい。自由度が高い一方で運用負荷が上がりがち。
※具体製品名はプロジェクト要件に合わせて比較表を作ると精度が上がります。

導入形態の比較（要点）

観点	SaaS型	自前ホスト型／OSS
立ち上げ速度	速い	中〜遅い
運用負荷	低い	中〜高い
データ主権	事業者依存	自社管理しやすい
カスタマイズ	事業者仕様に依存	自由度が高い

5-2. CI/CDパイプラインへの統合と運用の流れ

5-2-1. 最短ループを作る：PRで差分スキャン

SASTとは、開発者が直せるタイミングで返すほど効果的です。

だから、PR作成時に差分スキャンを自動実行し、重大度が一定以上ならマージブロックする“短いループ”を作ります。

5-2-2. 品質ゲートと失敗基準の設計

重大度（High/Critical）、到達可能性、反復出現などで品質ゲートを定義。
初期は緩めに、数スプリントで段階的に強化します。したがって、開発速度を損なわずに基準を引き上げられます。

5-2-3. ナイトリーでのフルスキャンと成果物スキャン

PR時は軽量、夜間はフルルールで全体スキャン。
さらに、ビルド成果物（バイトコード／コンテナイメージ）も対象に入れると、配布物視点の抜けを補えます。

5-2-4. レポート統合とチケット自動化

SARIF出力→集約→重複束ね→課題自動起票という一気通貫が理想です。
その結果、SASTとは“レポートを読む作業”から“改善サイクルを回す作業”へと役割が変わります。

5-2-5. モノレポ／マイクロサービスでの工夫

モノレポ：ディレクトリごとにルールセットを分割し、変更範囲に応じたスキャンを実行。
マイクロサービス：サービスごとに基準値と例外ルールを持ち、共通ルールは中央管理するハイブリッド型が運用しやすいです。

トリガー別の推奨スコープ

トリガー	推奨スコープ	目的
PR作成／更新	差分スキャン、軽量ルール	即時フィードバックと手戻り削減
メイン統合	重要ルールの全体スキャン	回帰防止と品質ゲート
ナイトリー	フルルール＋成果物	広範囲の網羅と逸脱検知
リリース前	重点領域を再確認	漏れ取りと監査証跡

5-3. 運用上の注意点・改善アプローチ

5-3-1. 誤検知との付き合い方

初期は重大度の高いルールだけをゲートに採用し、低重大度は観察に留めます。
誤検知は除外アノテーションやパス除外をチーム標準として整備し、属人化を避けます。

5-3-2. 重大度とSLA（修正期限）

重大度×リスク露出で修正期限を定義します。例：Criticalは48時間、Highは1スプリント、Mediumはバックログ管理。
つまり、SASTとは検出だけでなく迅速に閉じる仕組みがあってこそ価値を生みます.

5-3-3. 例外承認プロセスの明文化

ビジネス優先で例外を出す場面は避けられません。だから、期限付き例外と代替コントロール（WAFルールやフィーチャーフラグ）をセットで記録します。

5-3-4. セキュアコーディング教育との連携

検出の多いCWEトップを社内勉強会やコーディング規約に反映。
修正例とアンチパターンをリポジトリのテンプレートへ落とし込み、再発を減らします。

5-3-5. KPIとダッシュボード

改善が進んでいるかを可視化しましょう。代表的な指標は次のとおりです。

KPI	定義	ねらい
MTTR（修正平均時間）	検出からクローズまでの平均	早期修正の徹底
再発率	同種CWEの再検出割合	教育効果の測定
誤検知率	除外・無効化件数の比率	チューニングの進度
ベースライン減少	既存欠陥の残量推移	技術的負債の解消度