「SAST」という略語を、セキュリティ製品の資料や開発の現場で目にして、何を指すのか正確に知りたい方は多いのではないでしょうか。SAST（Static Application Security Testing／静的アプリケーションセキュリティテスト）は、プログラムを実行せずにソースコードを解析して、脆弱性を見つける手法です。
ただ、DAST・SCA・IAST といった似た略語との違いや、SAST で何が見つかり何が見つからないのかまで整理できている方は、それほど多くありません。似た手法を混同したまま導入すると、守れていると思っていた範囲に穴が残ることもあります。
本記事では、SAST の定義と仕組みから、DAST・SCA・IAST との違い、導入するメリットと限界、開発工程での使いどころ、そしてツールや専門家によるソースコード診断の選び方までを解説します。自社の開発にセキュリティ検査をどう組み込むかを判断する材料としてご活用ください。
目次
一括ダウンロードする
SAST（静的アプリケーションセキュリティテスト）とは
SAST（Static Application Security Testing／静的アプリケーションセキュリティテスト）とは、プログラムを実行せずにソースコード（やコンパイル済みのコード）を解析し、セキュリティ上の脆弱性を見つける手法です。OWASP は SAST ツールを「ソースコードやコンパイル済みのコードを解析してセキュリティ上の欠陥を見つけるのに役立つツール」と定義しています。
コードを動かさずに検査することから、プログラムの中身（ソースコード）を見ながら行う「ホワイトボックステスト」の一種に位置づけられます。実行中の動作を外から観察するのではなく、「実行していない（static／non-running）」状態のコードそのものを読み解いて、問題のある書き方を洗い出す点が特徴です。
公的機関による定義も同じ方向を向いています。米国国立標準技術研究所（NIST）の SAMATE プロジェクトは、ソースコードセキュリティアナライザを「ソースコードを検査し、セキュリティ上の脆弱性につながる弱点を検出・報告するもの」とし、開発中または運用開始後にソフトウェアの脆弱性を取り除く「最後の防衛線の一つ」と位置づけています。
業界標準（OWASP）と公的機関（NIST）の双方で、SAST の役割は「ソースコードを静的に調べて弱点を見つける」ことで一致しています。
出典・参考資料（3件）
SASTの仕組み
ここからは、SAST が「静的に解析する」とは具体的に何をしているのかを見ていきます。SAST ツールは、コードを実行せずに読み解くために、いくつかの解析技術を組み合わせています。
代表的なのが、データフロー解析・制御フローの解析・テイント解析です。データフロー解析はデータがどこから入ってどこへ渡るかを、制御フローの解析は処理がどの順序で進むかを追い、テイント解析はこの2つを土台に危険な入力の流れを突き止めます。
OWASP の解説では、テイント解析を「ユーザーが操作できる入力で『汚染された』変数を特定し、それが脆弱性につながりうる処理（sink と呼ばれる箇所）まで到達するかを追跡する。汚染された変数が無害化されずに sink へ渡されると脆弱性として報告される」と説明しています。
たとえば、画面から入力された文字列が、適切な処理を挟まないまま SQL 文の組み立てに使われていれば、SQLインジェクションの候補として検出される、という仕組みです。
検出から報告までの流れは、ツールを開発プロセスに組み込む形で自動化されます。GitLab の公式ドキュメントは、SAST を CI/CD パイプラインに直接組み込み、コミットのたびに自動でスキャンが走ること、各アナライザーが検出結果を JSON 形式のレポートとして出力することを示しています。
開発者が統合開発環境（IDE）で書いている段階から問題の指摘を受けられるツールもあり、本番環境に到達する前に、開発の流れを止めずに脆弱性へ気づける点が、静的解析を自動化する価値です。
SASTとDAST・SCA・IASTの違い
SAST と並べて語られる略語に、DAST・IAST・SCA があります。これらはまとめてアプリケーションセキュリティテスト（AST）と呼ばれ、NIST の文書（SP 800-204C）では、Gartner の分類に依拠して、SAST・DAST・IAST・SCA の4つが主要な AST 技術として整理されています。
検査の原理・タイミング・対象が異なるため、どれか一つを入れれば十分というものではなく、役割の違いとして捉えるのが実態に近い考え方です。
NIST の整理では、SAST はソースコード・バイトコード・バイナリを静的に解析する手法、DAST は稼働中のアプリケーションに対して攻撃を模擬し、その反応から脆弱性を判定する手法です。
IAST は DAST の要素とアプリ内部への計装を組み合わせて実行時に観測する手法、SCA は利用しているオープンソースや第三者部品と、その既知の脆弱性を特定する手法です。
SAST が「自分たちで書いたコード」を対象にするのに対し、SCA は「借りてきた部品」を、DAST は「動いているアプリの外側」を見る、という住み分けになります。
まず、4つの手法が開発工程のどの段階で働くかを整理すると、次のようになります。
以下は、4つの検査手法の違いをまとめた比較表です。
| 検査手法 | SAST（静的解析） | DAST（動的解析） | IAST（対話型解析） | SCA（ソフトウェア構成分析） |
|---|---|---|---|---|
| 検査の原理 | ソースコードやバイトコードを実行せずに静的に解析する | 稼働中のアプリを外部から動かし、攻撃を模擬して検査する | アプリ内部に計装（エージェント）を組み込み、動的な検査と組み合わせて実行中に観測する | 利用中のオープンソースや第三者部品を特定し、既知の脆弱性やライセンスを照合する |
| 主な検査タイミング | 開発・実装〜テスト工程（早い段階から） | テスト・運用工程 | 機能テストなどの実行時 | 開発〜運用の全体 |
| 検査対象 | 自社で書いたソースコード | 実行中のWebアプリケーション・API | 実行中アプリの内部の挙動 | OSS・依存ライブラリ |
| 見つけやすい脆弱性の例 | SQLインジェクション、クロスサイトスクリプティングなどコードに起因する欠陥 | 設定の不備など、動かして初めて現れる問題 | テスト実行中に実際のデータの流れから確認できる脆弱性（到達した箇所のSQLインジェクション・XSSなど） | 既知の脆弱性を持つ依存部品 |
| ソースコードの要否 | 必要 | 不要 | 必要（計装による内部観測） | 必要（部品の一覧の情報） |
| 誤検知の傾向 | 多めで、検出結果の精査（トリアージ）が前提 | SASTより少なめ | 少なめ（テストの網羅範囲に左右される） | 少なめ（既知の脆弱性情報との照合が中心） |
※上記は各手法の一般的な傾向です。実際の検出範囲や誤検知の多寡は、使用するツール・対象システムによって異なります。
SAST とよく対比されるのが DAST です。OWASP は DAST ツールを「Webアプリケーションを通常は外部からスキャンし、クロスサイトスクリプティングや SQLインジェクション、安全でないサーバー設定などの脆弱性を探す自動ツール」と説明しています。
コードの中身を読む SAST と、外から動かして試す DAST は、見える問題が異なるため補完関係にあります。たとえば同じ SQLインジェクションでも、SAST はコードの書き方から、DAST は実際に動かしたときの反応から検出する、という違いがあります。
出典・参考資料（2件）
一括ダウンロードする
SASTを導入するメリット
SAST を開発に取り入れると、脆弱性への対処を開発工程の早い段階に前倒しできます。主なメリットは次の4つです。
開発初期に見つけて、修正コストを抑えられる。GitLab の公式ドキュメントは、CI/CD パイプラインに組み込んだ SAST が「修正が最も容易で費用対効果が高い開発段階で」セキュリティ問題を特定すること、逆に「開発の後半で見つかった脆弱性は、高くつく遅延や侵害につながる」ことを示しています。リリース直前に重大な脆弱性が発覚して対応に追われる、という事態を避けやすくなります。
問題のある箇所を特定しやすい。ソースコードを直接解析するため、どのファイルのどの処理に問題があるかを、コードの位置として示せます。外から動かして検知する手法に比べ、修正すべき場所の当たりがつけやすくなります。
開発の流れの中で継続的に回せる。コミットごとに自動でスキャンが走る運用にすれば、新しく書いたコードを都度チェックできます。検査を一度きりのイベントにせず、日々の開発に溶け込ませられる点は、頻繁にリリースする開発体制と相性が良い特徴です。
コードを広く機械的に調べられる。人手のコードレビューでは見落としやすい定型的な脆弱性を、対象コードに対して漏れなく機械的に走査できます。人のレビューと役割を分け合うことで、見るべき範囲を広げられます。
開発の早い段階からセキュリティを織り込み、継続的に検査を回すという考え方は、セキュリティ診断の現場でも共有されています。脆弱性診断ツールを提供する株式会社AndGoの原氏は、開発現場でのセキュリティの位置づけの変化について次のように話しています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。
出典・参考資料（1件）
SASTの限界・苦手なこと（デメリット）
一方で、SAST はあらゆる脆弱性を見つけられる万能な手法ではありません。導入前に、何が苦手なのかも押さえておく必要があります。OWASP は SAST ツールの弱点を具体的に挙げており、主な限界は次のとおりです。
誤検知が多く、精査が前提になる。OWASP は SAST ツールの弱点として「誤検知が多い（High numbers of false positives）」こと、そして「指摘された問題が本当に脆弱性であると『証明』するのが難しい」ことを挙げています。検出結果をそのまま受け取るのではなく、本物の脆弱性かどうかを一件ずつ判断する作業（トリアージ）が欠かせません。
認証・認可やビジネスロジックの不備は自動では捉えにくい。OWASP は、認証の問題・アクセス制御（認可）の問題・暗号の不適切な使用などは、多くの種類の脆弱性について自動での探索が難しいとしています。「この利用者がこの操作をしてよいか」といった、仕様や業務の文脈に依存する欠陥は、コードの字面を追うだけでは判断がつきにくい領域です。
実行環境の設定不備は見つけにくい。OWASP は、設定に起因する問題はコードとして表現されていないため、SAST では見つけられないことが多いと指摘しています。サーバーやミドルウェアの設定ミスのように、ソースコードの外にある問題は、静的解析の守備範囲から外れます。
対応言語に依存し、現在のツールが拾える範囲は限られる。OWASP は、現在の SAST ツールは「アプリケーションのセキュリティ上の欠陥のうち、比較的小さな割合しか自動で特定できない」とし、コンパイルできないコードの解析が難しいツールが多いことにも触れています。使用するツールが自社の開発言語・フレームワークに対応していなければ検査そのものが成り立たないため、対応範囲の確認は欠かせません。
出典・参考資料（1件）
開発工程でのSASTの使いどころと他手法との併用
SAST の限界を踏まえると、使いどころは「開発工程の早い段階で、コードに起因する脆弱性を継続的にすくい上げる」ことに絞れます。そのうえで、SAST だけでは見えない部分を他の手段で補う、という組み立てが現実的です。
運用面では、誤検知が多いという前提に立った設計が要になります。検出結果を鵜呑みにせず、本物の脆弱性かどうかを判断するトリアージの手順を決め、自社のコードに合わせてルールを調整します。さらに、重要度の高いアプリから段階的に CI/CD へ組み込んでいくことで、誤検知に埋もれて運用が回らなくなる事態を避けられます。
一方で、認証・認可やビジネスロジックの不備、実行環境の設定ミスといった、SAST が苦手とする領域は別の手段で補う必要があります。稼働中のアプリを外から動かして試す DAST、実行時に内部を観測する IAST、利用している部品の既知の脆弱性を照合する SCA は、それぞれ SAST とは違う角度から脆弱性を見ます。
さらに、仕様や業務の文脈を踏まえた判断が要る部分については、ツールによる自動検査だけでなく、専門家がソースコードを読み解いて精査する手動のソースコード診断を組み合わせることで、ツール単独では残ってしまう穴を埋められます。
どこまでをツールに任せ、どこから先を人の目で確かめるかという線引きについては、ツールによる自動診断と専門家による手動診断の両方を手がける事業者からも語られています。株式会社TECHFUNDの生田氏は、次のように説明しています。
ツールを使えば大量の項目を短期間で効率的に診断できますが、ビジネスロジックに関わる部分や、複数の脆弱性の組み合わせで一つの問題が起きるようなケースは、単一のツールでは取りこぼしやすい領域です。そこは人間の目で判断する必要が必ずありますので、両方を組み合わせて診断しています。
出典・参考資料（2件）
SASTツール・ソースコード診断の選び方
SAST を自社に取り入れる手段は、SAST の機能を備えたツールを導入して自社で運用する方法と、専門家にソースコード診断を依頼する方法の2通りがあります。どちらを選ぶ場合も、確認しておきたい観点は共通する部分が多くあります。
このうち、ツールを自社に導入して運用する方法については、商用・オープンソースの主要な SAST ツールを比較し、費用や選び方まで整理した別記事があります。どのツールが候補になるかを具体的に検討したい方は、こちらもあわせてご確認ください（以下の選定観点は、ツール・診断依頼のどちらにも共通します）。
自社の開発言語・フレームワークに対応しているか。OWASP が選定基準の前提に「自社のプログラミング言語をサポートしていること」を挙げているとおり、対応言語は最初に確認すべき点です。対応していない言語は検査そのものができないため、主要言語だけでなく、実際に使っているフレームワークまで含めて確認することが欠かせません。
検出の網羅性と、誤検知の少なさのバランスはどうか。検出できる脆弱性の種類が広いほど見落としは減りますが、誤検知が多いと精査の負担が増えます。どれだけ拾えるかと、拾った結果をどれだけ信頼できるかの両面で見ることが、運用を回し続けるうえで重要になります。
開発の流れに組み込めるか。IDE や CI/CD パイプラインと連携できれば、開発者が書いている段階やコミットのたびに検査を回せます。普段の開発ツールと無理なくつながるかどうかは、検査を継続できるかを左右します。
レポートが分かりやすく、次の行動につながるか。検出結果が、どのコードのどの問題で、どう直せばよいかまで示されているかは、確認しておきたい点です。開発者が修正に動ける粒度で報告されるかどうかで、検査後の対応速度が変わります。
AIによる誤検知の削減や修正支援に対応しているか。近年は、AI を活用して誤検知を減らしたり、修正方法を提案したりするツールが登場しています。誤検知の精査が負担になりやすい SAST では、こうした支援の有無が運用のしやすさを左右する場合があり、どこまで自動化されているかを確認しておくと判断の助けになります。
依頼型のソースコード診断を選ぶ場合は、これらに加えて確認したい点があります。専門家がツールの検出結果をどこまで精査してくれるか、認証・認可やビジネスロジックのような自動検査が苦手な領域まで見てくれるか、速報や報告会などのサポートがあるかも判断材料になります。
ツール導入と専門家診断は二者択一ではなく、自動化できる範囲はツールで日常的に回し、仕様に踏み込んだ確認は診断サービスに委ねる、という組み合わせも選択肢に入ります。
専門家に依頼するソースコード診断について、公開料金が少ないなかでの費用相場の考え方や、依頼先タイプごとの選び方をさらに詳しく知りたい場合は、以下の記事で整理しています。見積りを取る前に比較の物差しを持ちたいときに役立ちます。
ソースコード診断とは？費用相場と依頼先の選び方をタイプ別に整理
自社のWebアプリやスマホアプリを提供する立場で、上司や取引先から「ソースコード診断もやっておくべきだ」と要請を受けたり、既に実施している脆弱性診断（動的診断）だけで十分か不安を感じたりする場面が増えています。 一方で「ソースコード診断」と…
出典・参考資料（1件）
SASTを自社の開発に取り入れる方法（サービス活用）
ここからは、専門家によるソースコード診断サービスを中心に、代表的な依頼先を比較表とともに紹介します。SAST を備えるツール単体の比較は先ほどの別記事に譲り、本記事では、ツールだけでは補いきれない部分を専門家が読み解くソースコード診断に絞って取り上げます。
自社でツールを運用する体制が整っていない場合や、リリース前に第三者の目で確かめたい場合の依頼先の候補としてご覧ください。
SAST やソースコード診断は、脆弱性対策の一部にすぎません。Webアプリケーション診断やクラウド診断なども含めて脆弱性診断サービス全体から導入先を比較検討したい場合は、以下の比較記事が役立ちます。診断方法・費用相場・選び方を横断的に解説しています。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
| サービス名 | CoWorker 脆弱性診断サービス | SHIFT SECURITY ソースコード診断 | セキュアブレイン ソースコード診断 | レオンテクノロジー ソースコード診断 | KSK Verification ソースコード診断 | GMO Flatt Security 脆弱性診断 |
|---|---|---|---|---|---|---|
| 提供会社 | CoWorker株式会社 | 株式会社SHIFT（旧SHIFT SECURITY） | 株式会社日立システムズ（セキュアブレインブランド） | 株式会社レオンテクノロジー | 株式会社KSK | GMO Flatt Security株式会社 |
| 診断手法 | AI「Red Agent」による自動解析＋社内専門家の最終確認 | 静的解析ツール＋セキュリティエンジニアの目視（ハイブリッド） | ツールによる自動解析＋アナリストの手動精査（ハイブリッド） | 診断ツール＋自社診断士の目視（ハイブリッド） | 診断員による目視診断（手動主体） | 手動主体の専門家診断＋ホワイトボックス（ソースコード）診断 |
| 主な対応言語 | 公式サイトに記載なし（要問い合わせ） | Java・PHP・.NET Framework・Ruby on Rails ほか（上位プランで最大28言語） | Java・C#・Python・PHP・JavaScript・Ruby・Go・Swift ほか20以上 | Java・C/C++・PHP・Ruby ほか多数 | Java・PHP ほか（Spring Framework・Laravel 等） | 公式サイトに記載なし（要問い合わせ） |
| 料金 | 要問い合わせ（公式サイトでは通常50万円〜） | 要問い合わせ（個別見積り） | 要問い合わせ（個別見積り） | 要問い合わせ（個別見積り） | 要問い合わせ（個別見積り） | 要問い合わせ（個別見積り） |
| 速報・報告会 | 公式に記載なし | 公式に記載なし | 速報・報告会（オプション） | 速報・報告会（オプション） | 速報・報告会（オプション） | 公式に記載なし |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | 公式サイト |
※料金・対応言語・診断内容は2026年10月時点の各社公開情報にもとづきます。最新の内容は各社にご確認ください。
1. CoWorker 脆弱性診断サービス（CoWorker株式会社）
ソースコードの解析を自社開発 AI「Red Agent」で自動化しつつ、最終確認を社内のセキュリティ専門家が担う二段構えが、CoWorker 脆弱性診断サービスの特徴です。CoWorker株式会社が提供し、診断メニューは「ソースコードAI診断」「動的脆弱性診断（Web/API診断）」「実践攻撃シミュレーション診断（ペネトレーションテスト）」の3つで構成されています。
ソースコードAI診断は、ソースコードや設計書を AI が解析し、本番環境に影響を与えずにリスクを洗い出すメニューです。料金は公式サイトでは通常50万円からとされ、診断するソースコードの範囲や組み合わせる診断に応じた個別見積りです。
AI による自動解析で検査のスピードを上げつつ、専門家のレビューで結果を精査したい場合に検討しやすいサービスです。
2. SHIFT SECURITY ソースコード診断（株式会社SHIFT）
静的解析ツールによる自動診断と、セキュリティエンジニアによる目視確認を組み合わせたハイブリッド型のソースコード診断です。提供元の株式会社SHIFT SECURITY は2026年9月1日付で親会社の株式会社SHIFT に吸収合併され、現在のサービス提供主体は株式会社SHIFT（旧SHIFT SECURITY）となっています。
診断は、対象言語と規模に応じた複数のプランで案内されており、上位プランでは専門家による目視解析や構成解析まで含まれます。自動検出の結果をエンジニアが精査して誤検知を取り除く運用で、ツール任せにしない点が特徴です。料金はアプリの規模などに応じた個別見積りで、公式サイトでの金額の掲載はありません。
3. セキュアブレイン ソースコード診断（株式会社日立システムズ）
株式会社日立システムズが「セキュアブレイン」ブランドで提供するソースコード診断は、ツールによる自動解析とアナリストによる手動精査を組み合わせて脆弱性を検出します。旧・株式会社セキュアブレインは2024年4月1日に日立システムズへ吸収合併され、サービスはセキュアブレインブランドとして継続しています。
Webサーバーへのアクセスを伴わずソースコードを解析するため、稼働中のシステムに影響を与えずに実施できます。検出した脆弱性をファイル名・行番号の単位まで報告する仕様で、修正箇所の特定がしやすい点を打ち出しています。対応言語は Java・C#・Python・PHP など20以上に及びます。料金はソースコードのステップ数に応じた個別見積りです。
4. ソースコード診断（株式会社レオンテクノロジー）
株式会社レオンテクノロジーのソースコード診断は、診断ツールによる検出と自社診断士による目視チェックを組み合わせ、自動検出の結果を一つずつ確認して誤検知を取り除く運用が特徴です。外部委託を使わず自社の診断士のみで対応する体制を掲げています。
インジェクション・認証・認可制御・セッション管理・情報漏えいなど8つのカテゴリで脆弱性を検出し、重大な脆弱性を発見した場合は正式な報告書を待たず速報で通知します。報告書の提出は診断終了後おおむね5営業日が目安とされ、診断を担当した診断員が同席する報告会もオプションで用意されています。開発工程の途中段階での部分診断にも対応します。料金は対象の規模に応じた個別見積りです。
5. ソースコード診断サービス（株式会社KSK）
ソフトウェアテストを手がける株式会社KSKが「KSK Verification」ブランドで提供するソースコード診断は、診断員による目視診断を軸にしています。開発・実装段階からの診断に対応し、早期に脆弱性を見つけることで修正コストを抑えられる点を打ち出しています。
対応言語は Java・PHP など、フレームワークは Spring Framework・Laravel などに対応します。静的なソースコード診断に加え、動的な Webアプリケーション診断と組み合わせることで、実行中にのみ現れる脆弱性まで含めた検知ができるとしています。
危険度の高い脆弱性を検出した際の速報サービスや、診断後の報告会をオプションで提供します。料金は対象の実ステップ数・使用言語などに基づく個別見積りです。
6. GMO Flatt Security 脆弱性診断（GMO Flatt Security株式会社）
GMOインターネットグループに属する GMO Flatt Security株式会社は、セキュリティエンジニアによる手動診断を軸にした脆弱性診断を提供しています。Webアプリケーションの標準診断に、条件を満たす場合は部分的なソースコード診断（ホワイトボックス診断）を追加料金なしで組み合わせる運用をとっており、認可制御の不備のようなパターン化された処理の検出に強みがあるとしています。
SPA（シングルページアプリケーション）向けには、ソースコード・仕様書・設計書を通じてシステム内部のロジックを検証する完全なホワイトボックス形式のメニューも用意されています。経済産業省の「情報セキュリティサービス基準」に登録されたサービスで、料金は診断対象に応じた個別見積りです。
まとめ
SAST（静的アプリケーションセキュリティテスト）は、プログラムを実行せずにソースコードを解析して脆弱性を見つける手法です。開発の早い段階から継続的に検査を回し、修正コストを抑えられる点が大きな利点である一方、誤検知が多く、認証・認可やビジネスロジック、実行環境の設定不備は自動では捉えにくいという限界もあります。
そのため、SAST は DAST・SCA・IAST といった他の検査手法や、専門家によるソースコード診断と組み合わせることで、単独では残ってしまう穴を埋める使い方が現実的です。
自社の開発言語への対応、誤検知の少なさ、開発の流れへの組み込みやすさ、レポートの分かりやすさを軸に、ツールの導入と診断サービスの依頼を使い分けることが、SAST を実務で活かす近道になります。自社の体制や確かめたい範囲に合わせて、最適な手段を選んでください。
一括ダウンロードする
よくある質問（FAQ）
Q. SAST（静的アプリケーションセキュリティテスト）とは何ですか？
A. SASTとは、プログラムを実行せずにソースコードを解析して、セキュリティ上の脆弱性を見つける手法です。Static Application Security Testing（静的アプリケーションセキュリティテスト）の略で、コードを動かさずに中身を読み解くことから、ホワイトボックステストの一種に位置づけられます。
OWASP や NIST も、ソースコードを静的に調べて弱点を検出する手法・ツールとして SAST を定義しています。
Q. SASTとDASTは何が違い、どちらを先に導入すべきですか？
A. SAST と DAST は、見つけられる脆弱性が異なるため、優先順位ではなく補完関係として併用するのが基本です。SAST はソースコードを静的に解析する手法、DAST は稼働中のアプリを外から動かして試す手法で、守備範囲が重なりません。
あえて順序をつけるなら、SAST は開発の早い段階からコードに組み込めるため、まず SAST で実装段階から継続的に検査し、動かして初めて現れる設定不備などを後工程で DAST が補う、という進め方が現実的です。
Q. SASTを導入すれば、自社のアプリケーションは安全と言えますか？
A. SAST だけで安全とは言えません。SAST は認証・認可やビジネスロジックの不備、実行環境の設定ミスといった脆弱性を自動では捉えにくいためです。これらは稼働中のアプリを試す DAST、実行時に内部を観測する IAST、利用部品の既知の脆弱性を照合する SCA、そして専門家による手動のソースコード診断と組み合わせることで、SAST 単独では残ってしまう穴を埋められます。
Q. SASTは誤検知が多いと聞きますが、実務で運用できるのですか？
A. SAST は誤検知が出やすい手法ですが、検出結果を精査する手順（トリアージ）を前提に設計すれば実務で運用できます。OWASP も SAST ツールの弱点として誤検知の多さを挙げています。
検出結果を鵜呑みにせず本物の脆弱性かどうかを一件ずつ判断し、自社のコードに合わせてルールを調整し、重要度の高いアプリから段階的に CI/CD へ組み込むことで、誤検知に埋もれて運用が回らなくなる事態を避けられます。
Q. SASTで、利用しているオープンソースやライブラリの脆弱性も見つけられますか？
A. SAST が得意とするのは自社で書いたソースコードの脆弱性であり、外部から取り込んだオープンソースや第三者ライブラリの既知の脆弱性を調べるのは SCA（ソフトウェア構成分析）の役割です。借りてきた部品の脆弱性まで押さえたい場合は、SAST と SCA を組み合わせて使います。
Q. SASTはどのプログラミング言語やアプリケーションに対応していますか？
A. SAST が対応する言語やフレームワークは、使用するツール・サービスによって異なります。ツールが自社の開発言語に対応していないと検査そのものが成り立たないため、主要言語だけでなく、実際に使っているフレームワークまで含めて対応範囲を確認することが欠かせません。本記事で紹介したソースコード診断サービスのように、Java・PHP・Python など20以上の言語に対応するものもあります。
Q. 無料で使えるSASTツールはありますか？
A. オープンソースで無償利用できる SAST ツールも存在します。代表的なものに、多言語に対応する Semgrep、Python 向けの Bandit、公開リポジトリなら無料で使える GitHub の CodeQL などがあります。
ただし、対応言語や検出できる脆弱性の範囲、誤検知の精査のしやすさ、レポートの分かりやすさ、サポートの有無は有償ツールや専門家による診断と差があります。無償ツールで自社の要件を満たせるかを見極めたうえで、足りない部分は有償ツールやソースコード診断サービスで補う判断が必要です。
Q. SASTを取り入れるには、ツールの自社運用と専門家へのソースコード診断依頼のどちらがよいですか？
A. SAST を取り入れる手段はツールを導入して自社で運用する方法と、専門家にソースコード診断を依頼する方法の2通りがあり、二者択一ではありません。日々の開発で継続的に検査を回すならツール、仕様や認可の文脈まで踏み込んで確かめたいなら専門家による診断が向きます。自動化できる範囲はツールで日常的に回し、ツールが苦手な領域は診断サービスに委ねる、という組み合わせも有力な選択肢です。
Q. ソースコード診断を外部に依頼する場合、自社のソースコードを渡しても大丈夫ですか？
A. ソースコードを外部に渡すことに不安がある場合は、診断会社の情報管理体制や、第三者への再委託の有無を確認して依頼先を選ぶことが重要です。外部委託を使わず自社の診断士のみで対応する体制を掲げる事業者もあり、経済産業省の「情報セキュリティサービス基準」への登録など、公的な基準を満たしているかも判断材料になります。本記事で紹介したサービスの詳細や管理体制は、各社の資料で確認できます。
ソースコード診断・脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、ソースコード診断をはじめとする脆弱性診断サービスの最新資料を無料で一括請求できます。診断手法や対応言語、サポート体制を比較して、自社に合う依頼先を効率的に見つけられます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
