SASTとは？静的アプリケーションセキュリティテストの仕組み・DAST/IASTとの違いと選び方

開発現場でセキュリティ診断やCI/CDへのツール導入、開発にセキュリティを組み込むDevSecOps、シフトレフトといった話題が増えるなかで、「SAST」という言葉を目にする機会が増えています。会議の資料やツールの営業で繰り返し出てくるものの、何を指す言葉なのかが曖昧なまま、という方も少なくありません。

SAST（Static Application Security Testing、静的アプリケーションセキュリティテスト）は、一言でいえば「ソースコードを実行せずに解析して、脆弱性を見つける手法」です。本記事では、この定義を起点に、仕組み・検出できる脆弱性・DASTやIASTとの違い・メリットと限界までを整理します。

そのうえで、SASTを自社の開発フローに取り入れるときの選び方や、SASTに対応したツール・ソースコード診断サービスも紹介します。

SASTとは？静的アプリケーションセキュリティテストを一言で

SAST（サスト、Static Application Security Testing、静的アプリケーションセキュリティテスト）とは、ソフトウェアを実行せずにソースコードを解析し、その中に潜む脆弱性を見つける手法です。アプリを動かさずにコードの内部そのものを見て検査する方式のため、「ホワイトボックステスト（内部＝コードを見て調べる方式）」の一種と位置づけられます。

SASTは特定の製品名やサービス名ではなく、検査の「やり方（手法）の分類」を指す言葉です。この手法を実装したツールは「SASTツール」や「ソースコード解析ツール（Source Code Analysis Tools）」と呼ばれます。

アプリケーションセキュリティの標準化団体であるOWASP（Open Worldwide Application Security Project）も、ソースコード解析ツールを「SAST（静的アプリケーションセキュリティテスト）ツール」と同じものとして説明しています。

Source code analysis tools, also known as Static Application Security Testing (SAST) Tools, can help analyze source code or compiled versions of code to help find security flaws.

出典：OWASP「Source Code Analysis Tools」（OWASP Community）

訳すと「ソースコード解析ツール（別名SASTツール）は、ソースコードやコンパイル後のコードを解析して、セキュリティ上の欠陥を見つけるのに役立つ」という意味です。OWASPはさらに、静的解析を「実行していない（static／non-running）ソースコードを対象に、開発の実装段階で行うコードレビュー＝ホワイトボックステスト」と説明しています。

アプリを稼働させて外側から攻撃を試すのではなく、コードを読み解いて問題を指摘する点が、ほかの検査手法との最大の違いです。

出典・参考資料（1件）

• 出典：Static Code Analysis｜OWASP Community

SASTの仕組み：ソースコードをどう解析して脆弱性を見つけるのか

ここからは、SASTがソースコードをどのように読み解いて脆弱性を検出するのか、その流れを見ていきます。

SASTツールは、人間がコードを1行ずつ目で追うのではなく、コードを機械が扱いやすい構造データに変換してから検査します。まず、ソースコードを解析して、抽象構文木（AST：プログラムの構造を木構造で表したもの）や制御フロー（処理が流れる順序）といった形に変換します。

次に、データフロー解析やテイント解析（後述）で、値がどこから入ってどこへ渡るかを追跡します。そのうえで、あらかじめ用意された脆弱性のルール（検出パターン）と照合して危険な書き方を見つけ、該当した箇所をファイル名・行番号まで特定して報告します。

このうち中心的な役割を担うのが「テイント解析（Taint Analysis）」です。これは、利用者が入力できる値（＝外部から汚染され得るデータ）に印を付けて追跡し、その値が適切な無害化（サニタイズ）を経ないまま、データベースへの問い合わせや画面出力といった危険な処理（シンク）に渡っていないかを調べる手法です。OWASPも、SASTがテイント解析やデータフロー解析といった技術を使うと説明しています。

たとえば、利用者が入力した文字列を無害化しないまま、データベースへの問い合わせ文に直接つなげているコードがあったとします。SASTはこの入力を「汚染された値」として追跡し、それが無害化されずに問い合わせ処理へ渡っていることを突き止めて、SQLインジェクションの疑いありと該当行を指摘します。このように、危険な値の流れをコード上でたどって問題を見つけるのがSASTの基本的な動きです。

こうした解析はツール上で自動的に実行されるため、CI/CD（継続的インテグレーション／継続的デリバリー）のパイプラインやIDE（統合開発環境）に組み込み、コードを書いた段階やプルリクエストの段階で自動的にチェックする運用がしやすいのも特徴です。

出典・参考資料（1件）

• 出典：Static Code Analysis｜OWASP Community

SASTで検出できる代表的な脆弱性

SASTが得意とするのは、コードの書き方そのものに起因する脆弱性です。OWASPは、SASTツールの強みとして「バッファオーバーフロー」や「SQLインジェクション」といった、よく知られた脆弱性を特定できる点を挙げています。

• SQLインジェクション（CWE-89）：入力値を適切に処理しないままデータベースへの問い合わせ文に組み込んでしまい、不正な操作を許す問題
• クロスサイトスクリプティング（XSS、CWE-79）：入力値を無害化せずにWebページへ出力し、悪意あるスクリプトを埋め込まれる問題
• バッファオーバーフロー（CWE-120）：確保した領域を超えてデータを書き込み、プログラムの誤動作や攻撃の足がかりを生む問題

SQLインジェクションとクロスサイトスクリプティングは、脆弱性の共通分類であるCWE（Common Weakness Enumeration）でそれぞれCWE-89・CWE-79として整理され、OWASPがアプリケーションの代表的なリスクをまとめた「OWASP Top 10」でも、いずれも「インジェクション（Injection）」のカテゴリに含まれます。

SASTは、こうした業界標準の分類で知られる脆弱性をコードの段階で検出できる点に価値があります。

ただし、どの脆弱性をどこまで検出できるかはツールや対応言語によって差があります。ここで挙げた例は「SASTが見つけやすい代表例」であり、あらゆる脆弱性を必ず検出できるわけではない点には注意が必要です（検出できないものについては限界で解説します）。

出典・参考資料（5件）

• 出典：Source Code Analysis Tools｜OWASP Community
• 出典：CWE-89 Improper Neutralization of Special Elements used in an SQL Command｜MITRE CWE
• 出典：CWE-79 Improper Neutralization of Input During Web Page Generation｜MITRE CWE
• 出典：CWE-120 Buffer Copy without Checking Size of Input｜MITRE CWE
• 出典：A05:2025 Injection｜OWASP Top 10:2025

SAST・DAST・IAST・SCAの違い（対比表）

SASTという言葉を知ると、必ずといってよいほど一緒に出てくるのが、DAST・IAST・SCAという関連手法です。これらはいずれもアプリケーションの安全性を調べる手法ですが、「何を・どう検査するか」が異なります。まず全体像を対比表で確認します。

DAST（Dynamic Application Security Testing、動的アプリケーションセキュリティテスト）は、稼働中のアプリに実際に攻撃的なリクエストを送り、SQLインジェクションやXSSのような脆弱性を外側から探す手法です。OWASPはDASTを「ブラックボックステスト」と説明しており、ソースコードやフレームワークを知らなくても検査できる点がSASTと対照的です。

IAST（Interactive Application Security Testing、対話型アプリケーションセキュリティテスト）は、アプリのコード内に組み込んだセンサー（ソフトウェアライブラリ）が、テストで操作されている最中の挙動を追跡して脆弱性を検出します。実行時の情報を使う点でDASTに近い一方、内部の文脈も見られるのが特徴です。

SCA（Software Composition Analysis、ソフトウェアコンポジション解析）は、自作コードではなく、アプリが利用する第三者製・オープンソースの部品（ライブラリ）に潜む既知の脆弱性やライセンス上の問題を洗い出します。

OWASPは、第三者・OSSコンポーネントの利用に伴うリスクを特定する取り組みを「コンポーネント解析」と呼び、そのソフトウェアに限定した一般的な呼称がSCAだと説明しています。自作コードの欠陥を見るSASTとは、検査する対象そのものが異なります。

これらは競合するものではなく、守る範囲が違う手法です。自作コードはSAST、動かして初めてわかる問題はDASTやIAST、使っている部品のリスクはSCA、というように組み合わせて多層的に守るのが実務の基本的な考え方になります。

出典・参考資料（3件）

• 出典：Dynamic Application Security Testing｜OWASP DevSecOps Guideline
• 出典：Interactive Application Security Testing｜OWASP DevSecOps Guideline
• 出典：Component Analysis｜OWASP Community

SASTを導入するメリット

SASTの主なメリットは、脆弱性を「開発の早い段階で・具体的な場所まで」見つけられる点にあります。順に整理します。

開発初期に脆弱性を検知できる（シフトレフト）。SASTはコードを書いている段階で検査できるため、リリースよりも前に問題を見つけて直せます。

セキュリティ対策を開発工程の早い側（レフト）に寄せる考え方は「シフトレフト」と呼ばれます。米国のNISTが定めるセキュアソフトウェア開発フレームワーク（SSDF、NIST SP 800-218）でも、静的解析ツールでコードを自動的に検査し、リリース前に脆弱性を修正する実践が位置づけられています。早い段階で見つけられれば、リリース後に発覚して手戻りが大きくなる事態を避けやすくなります。

問題のある箇所を行単位で特定できる。OWASPは、SASTツールの出力が「ファイル名・場所・行番号、さらには該当するコード片」まで示して開発者を助けると説明しています。どこを直せばよいかが具体的にわかるため、修正にかかる手間を抑えられます。

自動化・継続的な実行に向く。SASTは人手の作業を介さずに実行できるため、CI/CDパイプラインに組み込めば、コードが変更されるたびに自動で検査を回せます。年に1回のスポット診断では見つかりにくい、日々の変更に紛れた脆弱性を継続的に拾える点も利点です。

出典・参考資料（2件）

• 出典：Source Code Analysis Tools（Strengths）｜OWASP Community
• 出典：SP 800-218 Secure Software Development Framework (SSDF) Version 1.1｜NIST

SASTの限界・デメリット（誤検知と検出できない脆弱性）

SASTは万能ではありません。入門者ほど「良いことしか書かれていない解説」は判断を誤りやすいので、限界も正直に押さえておきます。OWASPも、SASTツールには明確な弱みがあると説明しています。

誤検知（フォールスポジティブ）が多い。OWASPは現在のSASTツールの弱みとして「誤検知が多い（High numbers of false positives）」ことを挙げています。実際には問題のない箇所まで「脆弱性の疑いあり」と報告されることがあり、報告をそのまま信じると対応に追われます。検出結果を人の目で振り分ける作業（トリアージ）が前提になります。

コードに現れない問題は見つけられない。OWASPは、設定の不備（configuration issues）はコード上に表現されないため検出が難しいと説明しています。また、認証・アクセス制御・暗号の不適切な利用といった問題も、自動検出が難しい類型として挙げられています。

対応言語・フレームワークに検出能力が左右される。SASTは言語ごとの文法や特性にもとづいて解析するため、ツールが対応していない言語やフレームワークでは、検出できる範囲が限られたり精度が落ちたりします。自社の開発言語に合うかどうかが、ツールや診断サービスを選ぶときの大きな分かれ目になります。

Current SAST tools are limited. They can automatically identify only a relatively small percentage of application security flaws. High numbers of false positives. Frequently unable to find configuration issues, since they are not represented in the code.

出典：OWASP「Source Code Analysis Tools」（OWASP Community）

この弱みは、訳すと「現在のSASTツールにできることは限られており、自動で特定できるのはアプリの脆弱性のうち比較的わずかな割合にとどまる。誤検知が多く、コードに表れない設定上の問題はしばしば見つけられない」という内容です。

仕様・業務ロジックの正しさは判断できない。SASTはコードの字面を静的に解析する手法のため、「仕様どおりに動くか」「業務上の意図に沿っているか」といった、正誤が設計意図に依存する問題は原理的に判断できません。また、実行して初めて現れる挙動も、動かさない検査では見えません。こうした領域は、DASTやIAST、手動の診断、そして設計レビューなど、ほかの手段と組み合わせて補う必要があります。

このようにSASTは「早く・自動で・コード起因の脆弱性を」見つけるのが得意な一方、万能の検査ではありません。導入すること自体をゴールにせず、誤検知の振り分けや他手法との併用を含めて運用してはじめて効果が出る点を押さえておきましょう。

出典・参考資料（1件）

• 出典：Source Code Analysis Tools（Weaknesses）｜OWASP Community

SASTの導入の流れとSDLC（CI/CD）への組み込み方

ここからは、SASTを実際に開発の流れに取り入れるときの進め方を確認します。開発の一連の工程（SDLC：ソフトウェア開発ライフサイクル）のどこにSASTを組み込むかがポイントで、基本的な導入ステップは次のとおりです。

1. 対象と目的を決める：どのアプリ・どの言語を、何のために検査するかを定める
2. ツールまたは診断サービスを選ぶ：対応言語やCI/CD連携、運用体制に合うものを選定する（次章で解説）
3. スキャンを実行する：IDEやCI/CDパイプラインに組み込み、コード変更時やプルリクエスト時に自動検査する
4. 検出結果をトリアージする：誤検知を振り分け、本当に対応すべき脆弱性を絞り込む
5. 修正し、再スキャンする：直した箇所を再度検査し、対応状況を記録する

SASTを継続的に効かせる鍵は、CI/CD（継続的インテグレーション／継続的デリバリー）への組み込みです。プルリクエストやコードのプッシュをきっかけに自動でスキャンし、基準を満たさないコードのマージを止める運用にすれば、脆弱性を含んだコードが先に進むのを防げます。IDEの拡張機能を使えば、開発者がコードを書きながらその場で指摘を受けることもできます。

NISTのSSDFも、人間可読のコードを解析して脆弱性を特定し、リリース前に修正する実践（PW.7）を定めており、静的解析ツールで自動的にコードを検査し、報告された問題を人がレビューする運用を例として挙げています。導入して終わりにせず、誤検知のトリアージやルールのチューニングを続けることで、SASTは開発速度を落とさずに回せるようになります。

出典・参考資料（1件）

• 出典：SP 800-218 Secure Software Development Framework (SSDF) Version 1.1（PW.7）｜NIST

SASTツール・ソースコード診断サービスの選び方

SASTを取り入れる方法は、大きく「自社でSASTツールを導入して運用する」か「ソースコード診断を外部の専門家に委託する」かの2つに分かれます。どちらを選ぶにしても、次のような観点で比較すると自社に合うものを見極めやすくなります。

• 対応言語・フレームワーク：自社の開発言語に対応しているか。SASTは言語やフレームワークへの依存が大きいため、最優先で確認する
• CI/CD・IDE連携：既存のパイプラインや開発環境に組み込めるか。継続的に回すなら重要
• 提供形態：クラウド（SaaS）型かオンプレミス型か。コードを外部に出せない要件があるかで変わる
• 誤検知への対応：トリアージ支援や優先度づけ、自動修正提案など、誤検知の負荷を下げる機能があるか
• 料金・相談のしやすさ：ツールの費用体系、診断サービスの見積りや相談のしやすさ

自社でSASTツールを導入するか、ソースコード診断を外部に委託するか

自社でツールを導入する方法は、CI/CDに組み込んで継続的・自動的に検査を回せるのが強みです。コードが変わるたびに検査でき、開発者がその場で修正できる一方、ツールの運用や誤検知のトリアージを自社で担う必要があり、セキュリティの知見と工数が求められます。

ソースコード診断を外部に委託する方法は、専門家がソースコードを静的解析（ツールと目視を組み合わせる場合が多い）して脆弱性を洗い出し、報告書で対策まで提示してくれます。自社に専任の体制がなくても、第三者の視点で診断を受けられるのが利点です。

多くはスポット（都度）での依頼になり、継続的な自動検査には向かない面はありますが、「まず現状を把握したい」「リリース前に専門家の診断を受けたい」といった場面に適しています。社内にSASTの運用リソースがない場合は、こうしたソースコード診断サービスの活用が現実的な選択肢になります。

外部委託を検討する場合は、費用の考え方や依頼先タイプごとの選び方を押さえておくと、見積り比較の物差しを持ちやすくなります。ソースコード診断の費用相場と、発注前に社内で準備しておくべき事項は、以下の記事で詳しく整理しています。

無料OSSという選択肢（SonarQube・Semgrep・CodeQL 等）とその限界

SASTには、無料で使えるオープンソース（OSS）のツールもあります。SonarQubeのコミュニティ版、Semgrepのオープンソース版、GitHubのCodeQLなどが代表例で、費用をかけずに導入を試せるのが魅力です。

一方で、無料版は解析できる範囲や機能が商用版より限られることが多く、検出結果の管理・トリアージの基盤やサポートが付かない点には注意が必要です。たとえばSemgrepのオープンソース版は、単一の関数・ファイルの範囲での解析に限られます。まず無料のOSSで感触をつかみ、本格運用では商用ツールや外部診断を検討する、という段階的な進め方が現実的です。

SASTツール・ソースコード診断サービスの比較表

SASTに対応した主なツール（SonarQube・Semgrep・Snyk Code・Checkmarx・Veracode など）と、ソースコードの脆弱性診断を依頼できるサービスを、提供形態・対応範囲・料金の観点で一覧にまとめました。自社でツールを回すか、専門家に診断を委託するかを検討する際の出発点として活用してください。

※2026年11月時点の各社公式情報・MCB FinTechカタログ掲載情報による。料金・対応範囲は変更される場合があります。

ここで取り上げたのは、ソースコードを対象とするSASTツールとソースコード診断サービスです。動的診断や手動診断まで含めて脆弱性診断サービス全体を比較検討したい場合は、診断方法・費用相場・選び方を整理した以下の記事もあわせてご覧ください。

ソースコードの脆弱性診断に対応した掲載サービス

ここからは、実際にSASTを取り入れる段階に進む方に向けて、ソースコードの脆弱性診断に対応したサービスを個別に紹介します。自社ツールとして導入できるクラウド型のサービスと、専門家にソースコード診断を委託できるサービスの両方があります。

Aikido Security｜オールインワン脆弱性診断SaaS

Aikido Securityは、ソースコード（SAST）・依存ライブラリ（SCA）・クラウド設定（CSPM）・コンテナ・稼働中のWebアプリ（DAST）を1つの管理画面でまとめて検査できるクラウド型のSaaSです。開発元はベルギーのAikido Security BVで、日本では株式会社AndGoが販売窓口となり、日本円の請求書払いにも対応しています。

アラートを自動で振り分けて誤検知の負担を抑える仕組みや、修正内容を含むプルリクエストの自動作成、Slack・Jira・AWSなどとの連携を備えます。無料のDeveloperプランがあり、本格導入の前に試せる点も魅力です。SASTを含む複数の検査を、1つの画面でまとめて始めたい企業に適しています。

CoWorker 脆弱性診断サービス

CoWorker株式会社が提供する脆弱性診断サービスは、自社開発のAI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせているのが特徴です。診断メニューは、ソースコードを読み取る静的診断、稼働中のアプリ・APIを対象とした動的診断、ペネトレーションテストの3種類をそろえています。

料金は、ソースコードAI診断が15万円から用意されています。AIの活用で診断スピードを高め、四半期ごとや月次といった継続的な診断にも対応しやすいとしています。ソースコードの静的診断を、専門家のレビュー付きで依頼したいときに適したサービスです。

同社は、年に1回のスポット診断から継続的な診断へと重心を移している背景を、次のように説明しています。

SHIFT SECURITY ソースコード診断

SHIFT SECURITY ソースコード診断は、静的解析ツールとセキュリティエンジニアの目視を組み合わせて、コード内部に潜む脆弱性を検出するサービスです。提供主体は、2026年9月に株式会社SHIFTへ統合された旧・株式会社SHIFT SECURITYで、現在は株式会社SHIFTのセキュリティサービスとして提供されています。

対象規模や言語に応じた複数のプランが用意され、評価にはCVSS（共通脆弱性評価システム）が用いられてきました。料金は公開されておらず、診断範囲に応じた見積り制です。ツールと専門家の目視の併用で、自動検査だけでは拾いにくい脆弱性まで確認したいというニーズに応えます。

セキュアブレイン ソースコード診断

セキュアブレイン ソースコード診断は、ITインフラ診断・Webアプリケーション診断と並ぶセキュリティ診断メニューの一つです。提供主体は、セキュアブレインブランドを引き継ぐ株式会社日立システムズ。稼働中のシステムに影響を与えずにソースコードを解析し、動的診断では見つけにくい内部の脆弱性を洗い出します。

20以上の言語（Java・C#・Python・PHP・JavaScript・Rubyなど）に対応し、脆弱性が見つかった場合はファイル名・行番号まで報告するため、修正の工数を抑えられるとしています。料金は診断範囲に応じた見積り制です。幅広い言語のコードを対象に、報告の具体性を重視する企業に向いています。

レオンテクノロジー ソースコード診断

レオンテクノロジー ソースコード診断は、診断ツールと専門家の目視チェックを併用して、ソースコード上の脆弱性を洗い出すサービスです。株式会社レオンテクノロジーが提供し、PCI DSSの認定審査機関（QSA）としての実績も持ちます。

Java・C/C++・PHP・Rubyなどの言語に対応し、開発工程の途中でも部分的に診断を依頼できる柔軟さが特徴です。診断報告書は約5営業日以内に提出され、重大な脆弱性は診断中に速報されます。報告会での技術的な質疑や、改修方法のフォローにも対応します。開発を進めながらこまめに診断を挟みたい開発チームに適しています。

KSK Verification ソースコード診断

KSK Verification ソースコード診断は、株式会社KSKの検証サービスの一つで、診断員がソースコードを目視で診断して脆弱性を検出します。ソフトウェアテスト事業で培った品質検証の知見を背景に、脆弱性に加えて非推奨APIの利用や未使用関数といったコード品質面も評価するのが特徴です。

Java・PHPなどの言語や、Spring Framework・Laravelといったフレームワークに対応します。危険度の高い脆弱性の速報や報告会のオプションもあり、同じ窓口でWebアプリケーション診断（動的診断）も依頼できるのが強みです。料金は実ステップ数や言語・期間をもとにした見積り制です。静的・動的の両方をまとめて相談したいときに有力な選択肢です。

まとめ

SAST（静的アプリケーションセキュリティテスト）は、ソースコードを実行せずに解析して脆弱性を見つける手法です。SQLインジェクションやクロスサイトスクリプティングのようなコード起因の脆弱性を、開発の早い段階で行単位まで特定できる一方、誤検知が多い・設定不備や業務ロジックの問題は検出できない、といった限界もあります。DAST・IAST・SCAと役割を分担し、多層的に守るのが基本の考え方です。

自社でSASTツールを運用するか、ソースコードの脆弱性診断を専門家に委託するかは、対応言語・CI/CD連携・運用体制・料金をふまえて選びます。社内に体制がない場合は、ソースコード診断サービスの活用も有力な選択肢です。まずは各サービスの資料を取り寄せ、自社の開発フローに合うものを比較してみてください。

よくある質問（FAQ）

Q. SAST（静的アプリケーションセキュリティテスト）とは何ですか？

A. SAST（Static Application Security Testing）とは、ソフトウェアを実行せずにソースコードを解析し、その中に潜む脆弱性を見つける手法です。日本語では「静的アプリケーションセキュリティテスト」と訳され、コードを内側から検査することからホワイトボックステストの一種に位置づけられます。

特定の製品名ではなく検査の「やり方（手法）の分類」を指す言葉で、この手法を実装したツールはSASTツールやソースコード解析ツールと呼ばれます。

Q. SASTとDAST・IAST・SCAの違いは何ですか？

A. SASTがソースコードを実行せずに解析するのに対し、DASTは稼働中のアプリに攻撃リクエストを送って外側から検査し、IASTはアプリ内部に組み込んだセンサーで実行中の挙動を監視し、SCAは利用している第三者・OSSライブラリの既知の脆弱性を照合する、という検査対象とやり方の違いがあります。これらは競合する手法ではなく、守る範囲が異なります。

自作コードはSAST、動かして初めてわかる問題はDASTやIAST、使っている部品のリスクはSCA、というように組み合わせて多層的に守るのが実務の基本的な考え方です。

Q. SASTではどのような脆弱性を見つけられますか？

A. SASTは、SQLインジェクション（CWE-89）やクロスサイトスクリプティング（XSS、CWE-79）、バッファオーバーフロー（CWE-120）といった、コードの書き方そのものに起因する脆弱性の検出を得意とします。OWASPもSASTツールの強みとして、こうしたよく知られた脆弱性を特定できる点を挙げています。

ただし、どこまで検出できるかはツールや対応言語によって差があり、あらゆる脆弱性を必ず見つけられるわけではありません。

Q. SASTだけでセキュリティ対策は十分ですか？

A. SASTだけでは不十分で、他の検査手法との併用が前提になります。SASTは誤検知（フォールスポジティブ）が多いうえ、設定の不備や認証・アクセス制御の不適切な利用、業務ロジックの欠陥、実行して初めて現れる挙動などは、コードの静的解析では検出できません。これらはDASTやIAST、手動の診断、設計レビューなどと組み合わせて補い、多層的に守る必要があります。

Q. 無料で使えるSASTツールはありますか？

A. SonarQubeのコミュニティ版、Semgrepのオープンソース版、GitHubのCodeQL（公開リポジトリ向け）など、無料で使えるSASTツールがあります。費用をかけずに導入を試せるのが魅力ですが、無料版は解析できる範囲や機能が商用版より限られ、検出結果の管理・トリアージ基盤やサポートが付かないことが多い点には注意が必要です。

まず無料のOSSで感触をつかみ、本格運用では商用ツールや外部診断を検討する、という段階的な進め方が現実的です。

Q. SASTの導入にはどれくらいのコストがかかりますか？

A. 無料のオープンソースツールから、月額数十ドル規模のSaaS型ツール、要問い合わせの商用製品まで幅広く、ソースコードの脆弱性診断を外部に委託する場合は十数万円から（たとえばソースコードのAI診断で15万円〜）が一つの目安です。どの手法・サービスを選ぶかで費用は大きく変わります。

自社の開発言語・検査したい範囲・継続的に回すのか都度の診断で足りるのかを整理したうえで、各サービスの料金体系を比較するのが近道です。

Q. SASTツールを自社導入するのと、ソースコード診断を外部に委託するのはどちらがよいですか？

A. CI/CDに組み込んで継続的・自動的に検査を回したいなら自社でのSASTツール導入、専任の体制がなく第三者の視点で現状を把握したいなら外部へのソースコード診断の委託が向きます。自社導入はコードが変わるたびに検査でき開発者がその場で修正できる反面、ツールの運用や誤検知のトリアージを自社で担う必要があります。

外部委託は専門家がソースコードを静的解析し、報告書で対策まで提示してくれますが、多くはスポット（都度）での依頼になり、継続的な自動検査には向きません。両者は排他ではなく、組み合わせて使うこともできます。

脆弱性・セキュリティ診断サービスの料金・資料を一括チェック

MCB FinTechカタログでは、ソースコード診断をはじめとする脆弱性・セキュリティ診断サービスの最新資料を無料で一括請求できます。対応言語・診断手法・料金を比べて、自社の開発フローに合うサービスを選べます。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。