アプリケーション開発のセキュリティ対策を調べると、SAST（静的アプリケーションセキュリティテスト）と SCA（ソフトウェア構成分析）という2つの用語に行き当たります。並んで登場することが多く、どちらを選べばよいのか、両方入れる必要があるのかで迷う場面は少なくありません。
この2つは、どちらが優れているかを競う手法ではなく、検査する対象が異なります。SAST は自社で書いたソースコードを、SCA は外部から取り込んだOSS（オープンソースソフトウェア）やサードパーティの部品を調べます。対象が重ならないため、互いの代わりにはなりません。
本記事では、SAST と SCA がそれぞれ何を検査するのか、検出できる脆弱性の違い、片方だけでは足りない理由を整理します。あわせて DAST・IAST を含めた4つの手法の守備範囲と使い分け、開発工程への取り入れ方、自社で導入するか外部に診断を依頼するかの選択肢まで解説します。
目次
一括ダウンロードする
SASTとSCAの違い——何を検査するツールなのか
SAST と SCA の一番の違いは、検査する対象です。SAST は自社で書いたソースコードを解析し、SCA は外部から取り込んだOSSや依存ライブラリなどの部品を調べます。前者は「自分たちが書いたコードに危ない書き方がないか」、後者は「使っている部品に公表済みの既知の欠陥がないか」を見るもので、担当する領域が分かれています。
SAST は、ソースコードやコンパイル後のコードを解析してセキュリティ上の欠陥を見つける手法です。コードを実行せずに中身を静的に調べる点が特徴で、OWASP は SAST を「ソースコードやコンパイル版のコードを解析してセキュリティ欠陥を見つける手助けをするツール」と説明しています。
一方の SCA は、プロジェクトが使っている依存部品を特定し、その部品に公表済みの既知の脆弱性がないかを照合する手法です。見ている対象がまったく別だという点が、使い分けのすべての出発点になります。
以下は、SAST と SCA の違いをまとめた比較表です。
| 観点 | 検査対象 | 検出できる脆弱性の例 | 実行タイミング | 得意なこと | 苦手なこと | 偽陽性の傾向 |
|---|---|---|---|---|---|---|
| SAST | 自社で書いたソースコード（独自のコード） | SQLインジェクション、クロスサイトスクリプティング（XSS）、ハードコードされた認証情報など、コードの書き方由来の欠陥 | コードを書く段階からビルド時まで。コードを実行しない静的な解析 | 自社コードの危ない書き方を早い段階で見つける | 認証やアクセス制御など自動検出しにくい領域、コードに表れない設定の問題 | 偽陽性（誤検知）が多く出やすい |
| SCA | 外部から取り込んだOSS・サードパーティの依存部品 | 使用中の部品バージョンに公表された既知の脆弱性（CVE） | 依存部品を取り込んだ以降。新たな脆弱性が公表されるため公開後も継続 | 既知の脆弱性を抱えた部品を特定する | 自社で書いたコード自体の欠陥は対象外 | 公表済みの脆弱性データとの照合が中心 |
表のとおり、2つは守備範囲が異なります。自社コードの欠陥は SAST、取り込んだ部品の既知の脆弱性は SCA が担当するという役割分担で捉えると整理しやすくなります。
SASTとSCAはそれぞれどんな脆弱性を見つけるのか
対象の違いを押さえたら、次は「実際に何が引っかかるのか」です。抽象的な定義よりも、具体的に見つかる脆弱性を知るほうが自社のコードに当てはめやすくなります。
SASTが見つける脆弱性
SAST は、コードの書き方に起因する欠陥を見つけます。OWASP は、SAST が自動的に検出しやすいものとしてバッファオーバーフローや SQLインジェクションを挙げ、問題のあるコードをファイル名・場所・行番号、さらに該当するコード片まで示して開発者を助けると説明しています。
実務では、これらに加えてXSSや、ソースコードに直接書き込まれた認証情報（ハードコードされたパスワード・APIキー）なども代表的な検出対象です。いずれも、コードの書き方そのものに原因がある欠陥だという共通点があります。
一方で、SAST には不得意な領域があります。OWASP は、認証の問題・アクセス制御の問題・暗号の安全でない使い方などは自動検出が難しく、現在の SAST ツールが自動的に特定できるのはアプリケーションのセキュリティ欠陥のうち比較的小さな割合にとどまると述べています。
また偽陽性（誤検知）が多く出やすく、コードに表れない設定の問題は見つけにくいという限界も挙げています。見つかった警告をそのまま鵜呑みにせず、人の目で精査する前提で使う手法だといえます。
出典・参考資料（1件）
SCAが見つける脆弱性
SCA は、使っている部品そのものに公表済みの脆弱性がないかを調べます。OWASP のプロジェクトである Dependency-Check の説明では、SCA はプロジェクトの依存部品を特定し、その部品に既知の公表済み脆弱性があるかを照合するツール群とされています。
照合には NIST が運用する脆弱性データベース NVD のデータが使われ、該当する部品が見つかると、CVE（共通脆弱性識別子）として登録された脆弱性が一覧として報告されます。
このように SCA が見つけるのは、自社コードの書き方ではなく、「取り込んだ部品のこのバージョンには、すでに世の中に公表されている欠陥がある」という事実です。自社のコードがどれだけ丁寧に書かれていても、古いバージョンのライブラリを使っていれば、その部品の既知の脆弱性は残り続けます。そこを照合して気づけるのが SCA の役割です。
出典・参考資料（1件）
SCAと切り離せないSBOM・ライセンスコンプライアンス
取り込んだ部品を管理するうえで、SCA と密接に関わるのが SBOM（ソフトウェア部品表）です。米国の NTIA（電気通信情報局）は SBOM を「ソフトウェアを構成するさまざまな部品の詳細と、その供給網の関係を記した正式な記録」と定義しています。開発者やベンダーは既存のOSSや商用の部品を組み合わせて製品を作るため、SBOM はそれらの部品を一覧にして列挙するものだと説明されています。
SBOM で自社が使っている部品を把握しておくと、新たな脆弱性が公表されたときに「自社の製品に影響する部品を使っているか」をすぐ確認できます。NTIA は SBOM の用途として脆弱性管理とライセンス管理の両方を挙げています。
どのライセンスの部品を使っているかを把握するライセンスコンプライアンスも、部品を管理する運用の一部です。SCA で部品を洗い出し、SBOM で記録し、脆弱性とライセンスの両面から管理していく流れとして捉えると分かりやすくなります。
なぜ片方だけでは足りないのか——対象が重ならない「互いの死角」
SAST と SCA は検査する対象が重なりません。だからこそ、片方だけでは相手側の領域が丸ごと死角になります。自社コードをいくら SAST で検査しても、取り込んだ部品の既知の脆弱性は SCA で照合しない限り見えないままです。逆に、部品を SCA で調べても、自社コードの書き方の欠陥は SAST でなければ見つかりません。
この「部品起因の死角」が実際の被害につながった例として、Python 向けの Redis クライアント redis-py の脆弱性があります。NVD に登録された CVE-2023-28858 は、非同期処理の途中でコマンドをキャンセルした際に接続が開いたまま残り、あるリクエストの応答データが無関係な別のクライアントに送られてしまう問題でした。
なぜ「別のクライアント」に届くのかというと、redis-py は接続を毎回作り直さず、使い回す仕組み（コネクションプール）を持つためです。キャンセルで中途半端になった接続は、まだ読み取られていない応答を抱えたままになります。既定のプール運用でこの汚染された接続が別のリクエストに再利用されると、次の呼び出し元が前のリクエスト宛ての応答を1つずれて受け取ってしまいます。
続報の CVE-2023-28859 では、同種の問題がパイプライン処理に限らず非同期接続全般で起こりうることが示されました。取り込んだ部品の既知の脆弱性は、1件の修正だけでは収まらないこともあります。
redis-py before 4.5.3 leaves a connection open after canceling an async Redis command at an inopportune time, and can send response data to the client of an unrelated request in an off-by-one manner.
出典：CVE-2023-28858｜NVD（NIST National Vulnerability Database）
この脆弱性は、自社が書いたコードではなく、取り込んだ部品の側にありました。NVD によれば、この CVE は生成AIサービスの ChatGPT に関する報告を受けて登録されたものです。
取り込んだ部品の既知の不具合が原因で、ある利用者の応答データが無関係な別の利用者に渡るという事象が、実際に稼働中のサービスで表面化した例にあたります。自社コードをどれだけ丁寧に書いても、部品側に潜むこうした欠陥は避けられないことを示しています。
自社コードを対象とする SAST では、こうした部品の問題に警告は出ません。部品のバージョンを既知の脆弱性と照合する SCA があってはじめて気づけます。SAST と SCA を両方そろえる理由は、この「互いの死角を埋める」補完関係にあります。
DAST・IASTとの違い——4つの手法の守備範囲
アプリケーションのセキュリティ検査には、SAST・SCA のほかに DAST（動的アプリケーションセキュリティテスト）と IAST（インタラクティブアプリケーションセキュリティテスト）があります。4つは別々のものを見ているため、違いを押さえると自社に必要な組み合わせが見えてきます。
DAST は、稼働中のWebアプリケーションを外側から動かして検査する手法です。OWASP は、Webアプリケーション脆弱性スキャナーを「通常は外側からWebアプリケーションをスキャンし、XSS・SQLインジェクション・コマンドインジェクション・パストラバーサル・安全でないサーバー設定などの脆弱性を探す自動ツール」と説明し、この種のツールが DAST と呼ばれるとしています。
IAST は、アプリケーションのコードに組み込んだセンサーモジュールを使い、テストの実行中にアプリケーションの挙動を追って実行時に検知する手法です。SAST や DAST とは別に、実行中の内部から見るという視点を持ちます。
| 観点 | 解析タイミング | 主な対象 | 視点 | 得意なこと | 苦手なこと |
|---|---|---|---|---|---|
| SAST | コードを書く段階からビルド時（非実行） | 自社のソースコード | コードの中身を静的に見る | 書き方由来の欠陥を早期に発見 | 認証・アクセス制御や設定の問題 |
| SCA | 依存部品の取り込み以降・公開後も継続 | 取り込んだOSS・依存部品 | 部品の構成を照合する | 既知の脆弱性を持つ部品の特定 | 自社コード自体の欠陥 |
| DAST | アプリが稼働している状態 | 稼働中のWebアプリ（外側から） | 外側から動かして見る | 稼働環境・設定の問題や外から見える挙動の検出 | コード内部での原因箇所の特定 |
| IAST | テストの実行中 | 実行中のアプリ内部 | 内部にセンサーを置いて実行時に見る | 実行時の挙動をその場で把握 | アプリへのセンサー組み込みが必要 |
ここで注意したいのが、業務の流れに潜む欠陥です。たとえば本来の手順を飛ばして処理を進められてしまうような、業務ロジックに関わる脆弱性があります。OWASP の Web Security Testing Guide は、この種の脆弱性は脆弱性スキャナーでは検出できず、自動ツールは文脈を理解するのが難しいため、こうした検査は人が行うしかないと述べています。
SAST や SCA を含む自動検査でカバーしきれない領域があり、業務全体の流れを理解した人手の試験が必要になります。この点は、手法を組み合わせるうえで押さえておきたいところです。
出典・参考資料（3件）
SASTとSCAの使い分けと組み合わせ方
SAST と SCA は役割が違うため、どちらかを選ぶというより、開発工程のなかで両方を組み合わせるのが基本です。「いつ・何を・どの順で」入れるかを、組み込む場所と、警告のノイズとの付き合い方の2つに分けて見ていきます。
開発工程のどこに組み込むか
SAST は、開発の早い段階から繰り返し使えます。OWASP は、SAST ツールを開発者の統合開発環境（IDE）に組み込めること、多くのソフトウェアに対して実行でき、夜間ビルドや継続的インテグレーション（CI）のように繰り返し実行できることを特徴として挙げています。
コードを書いている段階やプルリクエストの時点で早めに検出する考え方は、シフトレフトと呼ばれます。問題を早く見つけるほど、修正の手戻りは小さく済みます。
SCA には、公開後も続けて使うという特徴があります。部品の新たな脆弱性（CVE）は日々公表されるため、一度検査して終わりではなく、取り込んだあとも照合を続ける必要があります。OWASP Dependency-Check のように、NVD のデータフィードを使って照合用のデータを自動更新する仕組みを備えたツールもあります。
CI/CD パイプラインに SAST と SCA を組み込み、コードの変更時に自動で回しながら、SCA は公開後も継続的に監視する。これが現実的な組み合わせ方です。
出典・参考資料（2件）
SAST・SCAのようなツールを自社のCI/CDに組み込んで、どこまで内製で回せるのかは別途押さえておきたい論点です。診断項目ごとにツールで置き換えられるもの・人の判断が要るものの切り分けや、CI/CD組込みと年間コストの考え方は、脆弱性診断の内製化を扱った記事で詳しく整理しています。
偽陽性・ノイズで開発を止めないために
検査を組み込むうえで現場が最初にぶつかるのが、警告の多さです。SAST は偽陽性が多く出やすく、SCA も使っている部品が増えるほど「既知の脆弱性あり」という通知が積み上がります。すべてを同じ重さで対応しようとすると、確認作業に追われて開発が止まり、やがて警告が放置されていきます。
この「放置が始まる」状態は、診断ツールを提供する現場でも共通して聞かれる悩みです。
そこで、警告に優先順位を付けて対処する考え方が役立ちます。たとえば、脆弱性があると報告された部品でも、その危険な機能を自社のコードから実際には呼び出していなければ、悪用される経路はありません。
こうした「実際には使っていない部品の警告」の優先度を下げ、実際に使われている経路の問題から先に直すという絞り込み方があります。脆弱な機能に自社コードから到達できるかどうかで優先度を判断する考え方で、到達可能性〈reachability〉と呼ばれます。何を先に対応するかの基準を決めておくことが、ノイズに埋もれず運用を回し続けるうえで重要になります。
SAST・SCAを導入するには——自社で組み込むSaaSと外部へのソースコード診断
SAST・SCA を実際に取り入れる進め方は、大きく2つに分かれます。自社の開発環境にツールを組み込んで自分たちで回す方法と、外部の専門会社にソースコード診断を依頼する方法です。どちらが向くかは、継続性を重視するか、専門家の確認や第三者の報告書を重視するかで変わります。
なお、依存部品の SCA まで1つのツールで自動的に照合できるのは主に SaaS 型で、外部へのソースコード診断は自社で書いたコード（SAST 側）の精査が中心です。取り込んだ部品の照合まで含めて両面をそろえたい場合は、その手段がどちらの対象をカバーするかを確かめて選びます。
自社のCI/CDに組み込むSaaS型
1つ目は、SAST・SCA の機能を持つツールを契約し、IDE や CI/CD パイプラインに組み込んで自動でスキャンする方法です。前の章で見た開発工程への組み込みを自社の手で回す形で、内製で開発していて、開発を止めずにセキュリティを担保したいチームに向きます。依存部品の SCA まで1つのツールでカバーできるのは、主にこの形です。
費用は月額・年額のサブスクリプション型が中心で、利用する開発者の人数や連携するリポジトリ数に応じて規模が決まる形が一般的です。無料で試せるプランを持つツールもあります。
外部にソースコード診断を依頼する
2つ目は、専門の診断会社にソースコードを渡し、ツールと専門家の目視を組み合わせて診断してもらい、報告書を受け取る方法です。社内に専門人材がいない場合や、取引先・監査への提出のために第三者による報告書が必要な場合に向きます。
費用は診断対象の規模（コードの行数・ステップ数）に応じた個別見積もりが基本です。小規模なら十数万円から始まり、対象が広い場合や専門家による手動診断の比重が増えると数十万円以上になることもあります。スポットで一度依頼する形と、定期的に依頼する形があります。
外部へのソースコード診断は公開料金を持つベンダーが少なく、見積もりを比べる物差しを持ちにくい領域です。費用の考え方や、依頼先をタイプ別にどう選ぶかをもう一段詳しく確かめたい場合は、ソースコード診断の費用相場と依頼先の選び方を整理した記事が参考になります。
どちらを選ぶ場合も、確認しておきたい観点は共通しています。自社の開発言語・フレームワークに対応しているか、CI/CD と連携できるか、偽陽性やノイズをどう抑える仕組みがあるか、そして費用と報告の形式です。これらを基準に、自社の開発体制に合う進め方を選ぶとよいでしょう。
一括ダウンロードする
SAST・SCAに対応するサービス・診断の選択肢
ここからは、SAST・SCA に対応する具体的なサービスを紹介します。取り上げるのは、依存部品の SCA まで含めて1つのツールで検査できる SaaS 型と、自社で書いたコード側（SAST 相当）を専門会社に委託するソースコード診断です。
依存部品の照合（SCA）まで自動で回したい場合は SaaS 型が中心になる点を踏まえて読み進めると、自社に足りない対象を補う手段が選びやすくなります。まずは各サービスの提供形態・検査対象を一覧で比較します。
| サービス名 | Aikido Security | CoWorker 脆弱性診断サービス | SHIFT SECURITY ソースコード診断 | セキュアブレイン ソースコード診断 | レオンテクノロジー ソースコード診断 | KSK Verification ソースコード診断 |
|---|---|---|---|---|---|---|
| 提供形態 | SaaS（自社CI/CDに組込み） | 診断委託（外部に依頼） | 診断委託（外部に依頼） | 診断委託（外部に依頼） | 診断委託（外部に依頼） | 診断委託（外部に依頼） |
| 検査対象 | SAST・SCA両方 （依存部品・SBOMも対応） | 自社コードの静的診断（SAST相当） | 自社コードの静的診断（SAST相当） | 自社コードの静的診断（SAST相当） | 自社コードの静的診断（SAST相当） | 自社コードの静的診断（SAST相当） |
| CI/CD連携 | ●（IDE・CIに組込み） | ×（委託診断型） | ×（委託診断型） | ×（委託診断型） | ×（委託診断型） | ×（委託診断型） |
| 料金 | 月額制サブスク Basic 年3,780ドル〜（無料プランあり） | ソースコード診断150,000円〜 Lite 500,000円〜 | 要問い合わせ（見積り制） | 要問い合わせ（見積り制） | 要問い合わせ（見積り制） | 要問い合わせ（見積り制） |
| 特徴 | コード・クラウド・Webを1画面で検査 自動修正（PR作成）・自動トリアージ | 自社開発AI「Red Agent」解析＋専門家確認 最短3営業日で報告書 | 静的解析ツール＋エンジニア目視のハイブリッド 詳細な報告書 | 日立システムズが提供 20以上の言語に対応・環境準備不要 | ツール＋目視・開発途中の部分診断に対応 重大な脆弱性は診断中に速報 | 診断員の目視診断＋コード品質も評価 動的診断も同じ窓口で依頼可 |
| 詳細情報 | 公式資料を見る | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
1. Aikido Security（Aikido Security BV／株式会社AndGo）
Aikido Security は、ソースコード・依存ライブラリ・クラウド設定・稼働中のWebアプリを1つの管理画面で検査するSaaSです。ベルギーの Aikido Security BV が開発し、日本では株式会社AndGo が販売窓口として日本語での一次対応や導入・運用の伴走を担います。
SAST と SCA の両方に対応し、依存関係のチェックやSBOM の出力、クラウド設定診断（CSPM）、DAST までを一つのツールでカバーします。自社のCI/CDに組み込んで継続的にスキャンする使い方が中心で、内製でサービスを開発するSaaS事業者やスタートアップに向きます。
アラートを自動でトリアージして誤検知を減らし、見つかった脆弱性には修正案のドラフトを作ってプルリクエストまで投げる自動修正の機能や、コードを書いている段階で危険な箇所に気づけるエディター拡張も備えます。料金は月額利用料が固定のサブスクリプション型で、無料で試せる Developer プランから用意され、利用者数やリポジトリ連携数でライセンス規模が決まります。
日本窓口（AndGo）の案内では、年間契約・利用者10人までの参考価格として Basic が3,780ドル/年、Pro が7,560ドル/年とされ、請求は為替を考慮した日本円での案内となります。正式な料金は問い合わせでの確認が必要です。
2. CoWorker 脆弱性診断サービス（CoWorker株式会社）
自社開発のAI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせた外部診断サービスが、CoWorker株式会社の脆弱性診断サービスです。もともと受託開発を手がけてきた会社が提供しています。
診断メニューは3つで構成されます。ソースコードを読み取って脆弱性を確認する静的なソースコードAI診断、稼働中のWebアプリ・APIを対象とする動的診断、そして実際に攻撃を試みる実践攻撃シミュレーション診断（ペネトレーションテスト）です。ソースコードAI診断は、本番環境に影響を与えずにリスクを洗い出せる点を訴求しています。
料金は、ソースコードAI診断が150,000円、ソースコードと動的診断を組み合わせた Lite プランが500,000円から（いずれも2026年11月時点）で、プランに応じて再診断回数や対象のAPI数が変わります。診断は最短3営業日で報告書を受け取れるため、自社に専門人材を置かず、専門家が確認した報告書を早く受け取りたい場合に検討しやすい選択肢です。
3. SHIFT SECURITY ソースコード診断（株式会社SHIFT）
SHIFT SECURITY ソースコード診断は、静的解析ツールとセキュリティエンジニアの目視を組み合わせて、ソースコードに潜む脆弱性を検出する依頼型の診断です。運営は株式会社SHIFT（旧・株式会社SHIFT SECURITY。2026年9月1日付で親会社のSHIFTに吸収合併）で、サービスは継続して提供されています。
外部からの動的診断では見つけにくい、コード内部の脆弱性の洗い出しを主眼とします。対応規模や対象言語に応じて複数のプランが用意され、小規模なアプリ向けから、専門家の目視解析・構成解析まで含む個別対応のプランまで段階があります。
評価は深刻度に応じて示され、報告書には総評・検査項目一覧・個別の脆弱性報告（対象箇所・想定される脅威・対策・再現方法）が含まれます。料金は公式では非公開で、診断対象の規模をもとにした見積もり制です。手厚い目視診断と報告を求める場合に向きます。
4. セキュアブレイン ソースコード診断（株式会社日立システムズ）
セキュアブレインのソースコード診断は、株式会社日立システムズがセキュアブレインブランドで提供する「セキュリティ診断サービス」のメニューの一つです。ツールによる自動解析に加え、アナリストが手動で結果を精査してノイズ（誤検知）を除いた報告書にまとめる、ハイブリッド型の静的診断を行います。
Webサーバーの環境を用意する必要がなく、ソースコードを提供すれば診断できる点を特徴とします。検出項目にはSQLインジェクション、XSS、CSRF（クロスサイトリクエストフォージェリ）、OSコマンドインジェクション、ハードコードされた機密情報などが含まれ、脆弱性の所在をファイル名・行番号単位で報告するため、修正箇所を特定しやすくなります。
対応言語はJava、C#、Python、PHP、JavaScript、Swift、Go など20以上に及びます。料金は診断対象のステップ数（行数）に応じた個別見積もりで、公式には金額が掲載されていないため問い合わせでの確認が必要です。
5. レオンテクノロジー ソースコード診断（株式会社レオンテクノロジー）
株式会社レオンテクノロジーのソースコード診断は、診断ツールと目視チェックを併用し、ツールが検出した脆弱性を一つずつ確認する運用が特徴です。ツールのみの診断では誤検知が起きやすいという考えから、人の目による確認を組み合わせています。
対応言語はJava、C/C++、PHP、Rubyなどで、各種フレームワークにも対応すると記載されています。開発工程の途中でも部分的に診断できるため、完成を待たずに依頼できます。診断完了後は約5営業日以内に報告書を提出し、重大な脆弱性は診断中に速報で通知します。
報告会後の再診断や改修方法のフォローにも対応します。同社はISMS（ISO/IEC 27001:2022）やPCI DSSの認定審査機関（QSA）といった認証を会社として取得しており、料金は診断対象の行数などをもとにした見積もり制です。
6. KSK Verification ソースコード診断（株式会社KSK）
ソフトウェアテスト事業を長く手がける株式会社KSKが提供するのが、KSK Verification のソースコード診断です。診断員がソースコードを目視で確認して脆弱性を検出し、脆弱性に加えて非推奨APIの利用や未使用関数といったコード品質の観点も評価します。
対応言語はJava、PHP など、Spring Framework や Laravel といったフレームワークにも対応すると記載されています。同じ窓口でWebアプリケーション診断（動的診断）も提供しており、静的診断と動的診断の両方を1社にまとめて依頼できます。
検出した脆弱性は概要と対策方法を添えて報告書で送付し、危険度の高い脆弱性の速報や報告会をオプションで利用できます。料金は実ステップ数・言語・期間などをもとにした見積もり制で、金額は公開されていません。コード品質までまとめて見てほしい場合に検討しやすい選択肢です。
ここで取り上げたのは、ソースコード（SAST・SCA）に軸足を置くサービスです。Webアプリやネットワークなども含めた脆弱性診断サービス全体を、診断方法・費用相場・選び方の観点で見比べたいときは、カテゴリの比較記事もあわせて確認してみてください。
まとめ
SAST と SCA は、検査する対象が異なる補完的な手法です。SAST は自社で書いたソースコードの書き方由来の欠陥を、SCA は取り込んだOSS・依存部品に公表済みの既知の脆弱性がないかを調べます。対象が重ならないため片方だけでは相手側が死角になり、基本は両方を開発工程に組み込みます。
運用では、SAST を IDE や CI に組み込んで早い段階から検出し、SCA は公開後も継続して部品を照合します。警告のノイズには優先順位を付けて対処すると、運用を回し続けやすくなります。
取り入れ方は、自社のCI/CDに組み込むSaaS型と、外部にソースコード診断を依頼する方法の2つがあり、継続性を重視するか、専門家の確認や第三者の報告書を重視するかで選ぶとよいでしょう。対応言語・CI連携・費用・報告の形式を基準に、自社の開発体制に合うものを検討してみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. SCA（ソフトウェア構成分析）とは何ですか？
A. SCA（ソフトウェア構成分析）とは、アプリに取り込んだOSSやサードパーティの依存部品を洗い出し、それらに公表済みの既知の脆弱性（CVE）がないかを照合する手法です。自社で書いたコードを解析するSASTと対になる存在で、照合にはNIST が運用するNVD などの脆弱性データベースが使われます。
使っている部品を一覧にするSBOM（ソフトウェア部品表）やライセンス管理とも結びついた運用になります。
Q. SASTとSCAは、どちらか一方だけ導入すれば足りますか？
A. SASTとSCAは、片方だけでは不十分で、基本は両方を組み合わせて使います。SASTが調べる自社のコードと、SCAが調べる取り込んだ部品は検査対象が重ならず、一方だけを入れてももう一方の領域がまるごと死角として残るためです。どちらから着手するか迷う場合は、OSSや外部ライブラリを多用しているプロジェクトほどSCAの効果が出やすいなど、自社の構成に照らして優先度を判断するとよいでしょう。
Q. SASTとDASTは何が違いますか？
A. SASTとDASTの違いは、SASTがコードを実行せずに中身を静的に解析するのに対し、DASTは稼働中のアプリを外側から実際に動かして検査する点です。SASTは自社のソースコードの書き方由来の欠陥を早い段階で見つけ、DASTは稼働環境や設定の問題など外から見える挙動を検出します。見る対象もタイミングも異なるため、部品を調べるSCAも含めて組み合わせて使うのが一般的です。
Q. SAST・SCAで警告が出なければ、そのまま公開してよいですか？
A. 警告がゼロでも「安全」と言い切ることはできません。SASTやSCAが苦手とする認証やアクセス制御の不備、本来の手順を飛ばして処理できてしまうような業務ロジックの欠陥は、自動検査では見つけにくい領域として残るためです。OWASP も、こうした文脈の理解を要する検査は人が行うしかないとしており、公開前には境界値や不正入力を試す動作試験など、人手の確認を組み合わせる必要があります。
Q. SCAはデプロイ（公開）後も続ける必要がありますか？
A. SCAは、公開後も継続して実行する必要があります。取り込んだ部品の新たな脆弱性（CVE）は日々公表されるため、リリース時点で問題がなくても、あとから既知の脆弱性を抱える状態に変わり得るからです。NVD のデータフィードで照合用データを自動更新するツールを使い、CI/CD に組み込んで継続的に監視する運用が現実的です。
Q. SAST・SCAの導入にかかる費用はどのくらいですか？
A. 費用は取り入れ方によって大きく分かれ、自社のCI/CDに組み込むSaaS型は月額・年額のサブスクリプション、外部へのソースコード診断は診断対象の規模に応じた見積もり（十数万円規模から）が中心です。SaaS型は利用する開発者数や連携するリポジトリ数で、外部診断はコードの行数（ステップ数）や対象言語・診断手法で金額が変わります。
無料で試せるSaaSや、スポットで一度だけ依頼できる診断もあるため、まずは小さく試して自社に合うかを確かめる進め方もあります。
脆弱性診断・ソースコード診断サービスの資料を一括チェック
MCB FinTechカタログでは、SAST・SCA に対応する脆弱性診断・ソースコード診断サービスの資料を無料で一括請求できます。対応する検査手法や料金、CI連携の可否をまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
