2026.08.06 セキュリティ

SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説

SCA は Software Composition Analysis の頭文字で、日本語ではソフトウェア構成分析と訳されます。自分たちが書いたコードではなく、取り込んだOSSやサードパーティ製ライブラリの側を数え、既知の脆弱性とライセンス条件に突き合わせる工程です。現代のアプリケーションはコード行数の大半が第三者製で占められ、そこを見ない検査は守備範囲の半分を空けたままになります。この記事では、依存関係をどう数えるのか、SASTやSBOMと何が違うのか、そして受託開発の現場でどの規模から入れるべきかを、導入可否を決められる粒度で整理しました。

まとめ：SCAの守備範囲とSAST・SBOMとの分担・導入可否を分ける判断軸

SCAが見るのは第三者のコードです。自社が書いた行のバグを探すのはSASTで、この二つは代替関係になりません。守備範囲を一言で分けるなら、SASTは「書いた行の欠陥」、SCAは「取り込んだ部品の既知の欠陥とライセンス」。検査原理そのものが違うため、片方だけを入れて安心する構成は成立しません。自社コード側の検査をどう組むかはSASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説で押さえてください。

SBOMとの関係もよく混ざります。SBOMは部品表という成果物、SCAはそれを作って脆弱性データベースと照合し続ける工程です。SBOMを一度出力しただけでは、翌週に公開されたCVEには反応できません。逆にSCAを回していれば、SBOMは副産物として出てきます。順序としては、SCAの導入が先で、SBOMの提出要件はその出力形式の話に落ちます。

導入するかどうかは三つの数で決まります。第一に、外部ライブラリを含むプロダクトを継続的にリリースしているか。第二に、依存の総数（推移的依存を含む）が数百を超えるか。第三に、納品先やEU向け出荷で脆弱性の報告義務やSBOM提出を求められる見込みがあるか。一つでも当てはまるなら、無償ツールでよいので今週から回し始めた方が安く済みます。三つとも外れる社内ツール限りの構成なら、リリース前の一括スキャンで足ります。費用の山はツール代ではなく、検出後のトリアージと更新PRを誰が捌くかという運用工数です。

SCAの定義と検出原理｜マニフェストとロックファイルから依存を数える

SCAという言葉は幅広く使われますが、実装として何をしているかは三段階に分解できます。ここを理解しておくと、ツール間の精度差の理由が説明できます。

依存の一覧化・脆弱性照合・ライセンス判定という三つの分析対象

SCAツールが順にやることは、①プロジェクトに含まれるコンポーネントを特定する、②各コンポーネントのバージョンを既知脆弱性のデータベースと照合する、③各コンポーネントのライセンス条件を判定する、の三段です。①が外れると②③も総崩れになるため、実務での精度差はほぼ①の網羅性で決まります。「SCAを入れたのに検出が少ない」という相談の大半は、脆弱性が無いのではなく、依存を数え切れていない状態です。

直接依存と推移的依存｜ロックファイル解析とバイナリ解析の精度差

依存の数え方には二つの流儀があります。一つはマニフェスト解析で、package.json や pom.xml、requirements.txt といった宣言ファイルを読む方式。もう一つはロックファイル解析で、package-lock.json、yarn.lock、poetry.lock、Gemfile.lock、go.sum といった解決済みの固定情報を読む方式です。前者は「^4.17.0」のような範囲指定しか分からないため、実際に入ったバージョンを特定できません。後者は解決結果そのものなので、推移的依存まで正確に列挙できます。設定を選べるなら、ロックファイルを必ずリポジトリへ入れ、そちらを読ませてください。

数の実感としては、直接依存が30個のNode.jsプロジェクトで推移的依存が800〜1,500に膨らむ例が普通にあります。脆弱性の多くはこの推移側に現れ、開発者が名前すら知らないパッケージから出てくるのが実情です。さらに精度が要る場面では、ビルド済みのjarやコンテナレイヤーからハッシュで同梱ライブラリを割り出すバイナリ解析が加わります。ソースが手元にない受領物の検査で効く方式です。マニフェストだけを見る構成では、Dockerfileで apt install した OSパッケージ側の脆弱性が丸ごと落ちる点に注意してください。

SCAとSAST・DAST・SBOMの違い｜検査対象と成果物の分担

用語が並ぶと混乱しますが、切り分けの軸は二本しかありません。誰が書いたコードを見るか、そして成果物なのか工程なのかです。

自社が書いた行を見るSASTと、第三者の部品を見るSCAの境界

SASTはソースコードを構文解析し、SQLインジェクションやパストラバーサルにつながる書き方を静的に見つけます。対象は自社が書いた行で、検出されるのは「未知だが構造的に危ない実装」です。SCAは対象が第三者製の部品で、検出されるのは「既知として登録済みの脆弱性」。DASTは動いているアプリに外から入力を投げる方式で、時間軸が実行時に寄ります。三つを並べたときの投資順序は、依存の多いWebアプリならSCAが先です。既知の脆弱性は攻撃側にとってコストがゼロに近く、実際の侵入経路として使われる頻度が高いためです。

SBOMは成果物・SCAは工程｜生成と照合のどちらが欠けるか

SBOMは、ソフトウェアに含まれる部品を機械可読な形式で列挙した部品表です。代表的な形式として、OWASP発の CycloneDX（1.6系が2024年6月にECMA-424の第1版、1.7系が2025年12月に第2版として承認）と、Linux Foundation発の SPDX（2.2.1が ISO/IEC 5962:2021 として国際規格化、3.0系が現行リリース）があります。いずれも2026年8月時点の状況です。

ここで押さえたいのは、SBOMは静止画だという点です。出力した瞬間の構成を写しただけなので、その後に公開された脆弱性情報は反映されません。SCAツールは同じ部品リストを持ち続け、データベース側の更新に対して再照合をかけます。つまりSBOMを提出物として求められている組織がやるべきことは、SBOM生成ツールを買うことではなく、SCAを回した副産物としてSBOMを出せる状態を作ることです。形式ごとの構造や必須項目はSBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説で確認してください。国内では経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引」がver2.0（2024年8月公表）まで進んでおり、業界ごとの対応モデルと取引上の責任分担まで踏み込んでいます。

脆弱性データベースとの照合｜NVD・OSV・GitHub Advisoryの差

SCAの検出結果は、突き合わせ先のデータベースで変わります。ツール比較の前に、どこを見ているかを確認してください。

CVE採番の遅れと、エコシステム単位で持つOSV形式が埋める範囲

伝統的な参照先はNVD（National Vulnerability Database）で、CVE識別子に対してCVSSスコアと影響範囲を付与します。ただしNVDは登録から解析完了までの滞留が起きやすく、CVE番号だけは存在するのに影響バージョンの機械可読な情報が付いていない期間が生じます。この空白を埋めるのが、Googleが主導する OSV（Open Source Vulnerabilities）と、GitHub Advisory Database です。両者はnpm・PyPI・Go・Maven・Cargoといったエコシステム単位でパッケージ名と修正バージョンを持つため、SCAツールがそのまま突き合わせできます。CVEとCWEの関係やCVSSの読み方に迷う場合はCVEとCWEの違いとは？脆弱性管理の基礎をCVSS・相互関係とあわせて解説を先に押さえておくと、検出結果の読み違いが減ります。

CVSSだけでは絞れない｜EPSS・KEVとVEXで対応順を決める

導入初日に出てくる検出件数は、中規模プロジェクトで数百件が珍しくありません。CVSSが7.0以上のものだけに絞っても数十件は残り、全部直そうとすると開発が止まります。ここで併用する指標が二つあります。EPSSは今後30日以内に悪用される確率を推定したスコアで、CVSSの深刻度とは別軸です。KEV（Known Exploited Vulnerabilities）カタログは、実際に悪用が確認された脆弱性を米国CISAが列挙したもの。運用としては、KEV収載を最優先、次にEPSSが高くCVSSも高いもの、残りは定期更新の波に乗せる、という三段の割り振りが回ります。

もう一つがVEX（Vulnerability Exploitability eXchange）です。検出されたが自社製品では悪用され得ないという判断を、機械可読な形で表明する仕組みです。脆弱な関数を呼んでいない場合に「not affected」と根拠付きで宣言でき、納品先へ説明を求められる受託開発で効きます。検出と対応を継続的な露出管理として回す枠組みはCTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説で扱っています。

到達可能性解析とは｜SCAの誤検知を構造的に落とす仕組みと限界

検出件数を構造的に減らす技術が到達可能性解析（reachability analysis）です。ここを理解しておくと、商用製品の価格差の理由が見えます。

呼び出しグラフをたどり、実行され得ない脆弱性の優先度を落とす

バージョン照合だけのSCAは、脆弱なライブラリが依存に入っていれば無条件に検出します。しかし脆弱性はライブラリ全体ではなく、特定の関数やクラスに存在するのが普通です。到達可能性解析は、自社コードのエントリポイントから呼び出しグラフをたどり、その脆弱な関数に到達する経路が存在するかを判定します。到達しないなら優先度を落とせます。実測では、この絞り込みで対応対象が2割から3割程度まで減る例が報告されており、トリアージ工数への効き方が大きい機能です。

動的読み込みとリフレクションによる取りこぼしを前提に置く運用設計

ただし万能ではありません。Javaのリフレクション、Pythonの動的import、JavaScriptの動的requireやプラグイン機構を経由する呼び出しは、静的な呼び出しグラフに現れません。到達不能と判定されたものが実際には実行されるケースが残ります。運用上の線引きとしては、到達可能性解析の結果は「優先度を下げる根拠」には使い、「対応しない根拠」には使わないでください。KEV収載のものは到達不能と出ても更新する、という例外規則を先に決めておくと事故が防げます。

OSSライセンス管理｜SCAが持つもう一つの検出軸と受託開発の落とし穴

SCAは脆弱性ツールとして語られがちですが、受託開発で実害が出やすいのはライセンス側です。脆弱性は直せば済みますが、ライセンス違反は納品後に発覚すると回収コストが跳ね上がります。

コピーレフトの伝播条件と、SPDXライセンス識別子による自動判定

ライセンスは大きく三系統に分けられます。MIT・Apache-2.0・BSDのような許諾型は、著作権表示とライセンス全文の同梱を条件に、ほぼ自由な組み込みが可能です。GPL系のコピーレフト型は、それを組み込んだ成果物にも同じ条件で公開義務が伝播する点が特徴となります。AGPL系はさらに強く、ネットワーク越しにサービスとして提供する形態でもソース開示の対象です。SCAツールは各パッケージのメタデータからSPDXライセンス識別子を読み取り、社内ポリシーと突き合わせて違反候補を挙げます。

実装上の注意点として、伝播の条件はリンク形態や配布形態で変わるため、検出結果をそのまま違反と読まないでください。パッケージのメタデータとリポジトリ内のLICENSEファイルが食い違い、機械判定が誤る例も実在します。

受託開発の納品物で問題になる場面と、先に決めておく三段のポリシー

受託開発でよく起きるのは、クライアントへソースコードごと納品する契約なのに、AGPL系のライブラリが推移的依存として紛れ込んでいたという状況です。納品直前の検査で見つかると、代替ライブラリへの差し替えで工数が飛びます。プロジェクト開始時に、許可（許諾型は無条件で可）、要審査（LGPL・MPLなど条件付き）、禁止（GPL・AGPL系は事前承認が要る）の三段のポリシーを決め、CIで自動判定させる構成にしてください。ポリシーが無い状態でツールだけ入れると、警告が全部無視されて終わります。

主要なSCAツールの選び分けとCI/CDパイプラインへの組み込み設計

ツールは無償と商用で機能の段差がはっきりしています。どこで段が変わるかを押さえて選んでください。

無償ツールで足りる範囲｜Dependabot・OSV-Scanner・Trivy

GitHubを使っているなら、Dependabot alerts は設定を有効化するだけで依存の脆弱性検出が始まります。GitHub Advisory Database を参照し、修正バージョンへの更新PRまで自動作成の対象です。運用の組み方はGitHub ActionsとDependabotの連携設定｜依存関係の自動更新から自動マージまでにまとめています。CIから明示的に走らせたい場合や、GitHub以外のホスティングを使っている場合は OSV-Scanner が候補です。OSV.dev を参照し、ロックファイル・SBOM・コンテナイメージ・Gitサブモジュールまで対象にできます。TrivyやDockerイメージ側の検査との違いはOSV-Scannerとは？Google製OSS脆弱性スキャナの使い方とTrivyとの違いで比較しました。Trivyはコンテナイメージ・IaC・OSパッケージまで一本で見られるため、Kubernetes前提の構成ではこちらが収まりがよくなります。

商用製品が要る条件｜到達可能性・ライセンスポリシー・監査証跡

商用へ移る判断軸は三つです。第一に、到達可能性解析で検出件数を構造的に減らしたいとき。第二に、ライセンスポリシーを組織単位で定義し、違反を自動でブロックしたいとき。第三に、監査や取引先提出に耐える証跡（いつ検出し、誰がどう判断したか）を残す必要があるとき。この三つが要らないなら、無償ツールで実務は回ります。逆に、複数プロダクト・複数チームで横断的にポリシーを効かせる段階に入ると、無償ツールの寄せ集めは管理工数の方が高く付きます。

CIのどこで止めるか｜ビルドのブロック基準と更新PRの捌き方

CIへの組み込みで最初に決めるのは、ビルドを落とす条件です。全件でブロックすると開発が止まるため、実務では「新規に追加された依存が持ち込む高深刻度の脆弱性のみ落とす」という差分基準から始めます。既存の検出はチケット化して別途消し込み、リリースゲートでKEV収載の有無だけを見る二段構えにすると、開発速度を落とさずに歯止めが効きます。更新PRは週次でまとめて捌く枠を作り、パッチバージョンは自動マージ、マイナー以上は人が見る、という線を引いてください。放置された更新PRが数百件たまった状態は、SCAを入れていないのと実質同じです。

SCAを導入すべき現場と、リリース前スキャンで足りる現場の判断基準

ここは判断を言い切ります。SCAは継続的に回して初めて価値が出る仕組みで、単発の検査として入れるなら投資対効果は薄くなります。

採用条件は依存規模・リリース頻度・提出義務の三つで機械的に決まる

採用の条件は三つです。第一に、外部ライブラリを含むプロダクトを月1回以上リリースしていること。第二に、推移的依存を含む依存総数が数百を超えること。第三に、納品先の要件やEU向け出荷でSBOM提出や脆弱性報告を求められる見込みがあること。二つ以上が当てはまるなら、無償ツールでよいので常時稼働へ入れてください。特に三点目は期限が具体的に迫っており、EUサイバーレジリエンス法（CRA）では、悪用が確認された脆弱性と重大インシデントの報告義務が2026年9月11日から適用されます。24時間以内の早期警告と72時間以内の本通知が求められる以上、どの製品にどの部品が入っているかを人手で調べる体制では間に合いません。SBOMを含む主要義務の適用は2027年12月11日で、それまでに構成情報を機械で引ける状態にしておく必要があります。

SCAを見送ってよい場面と、導入工数の内訳から見た費用配分の目安

見送ってよい場面もはっきりしています。依存が数十個で更新も年に数回、社内限りで外部公開しないツール類であれば、リリース前の一括スキャンで足ります。同様に、ポリシーもトリアージ担当も決まっていない段階で商用製品を契約する判断は取りません。検出結果を誰も見ない状態が半年続き、契約更新時に解約されるだけです。

工数の内訳は、ツール導入とCI組み込みが1割、ポリシー策定と例外規則の合意が2割、初回トリアージと既存検出の消し込みが5割、運用ルールの定着が2割というのが実感値で、費用の大半は初回の棚卸しに集中します。自社に判断できる担当がいない場合は、初回の棚卸しと運用ルールの設計だけを外部に出し、日々の更新PRは自社で回す分担が現実的です。診断まで含めて外部の目を入れるなら、脆弱性診断・セキュリティ診断で扱う検査範囲と、SCAで自動化できる範囲を先に切り分けておくと、費用の重複が避けられます。

SCAの読み方・費用・SBOM対応についてよくある質問への回答

導入検討の初期に受ける質問のうち、判断へ直結する部分だけ答えます。

SCAは何の略で、どう読みますか？

SCA は Software Composition Analysis の略で、そのまま「エスシーエー」と読みます。日本語ではソフトウェア構成分析、あるいはソフトウェアコンポジション解析と訳され、どちらの表記も実務で通用します。

SCAとSASTはどちらを先に導入すべきですか？

依存関係の多いWebアプリケーションなら、SCAが先です。理由は投資対効果で、SCAは設定を有効化した当日から既知の脆弱性が出てくるのに対し、SASTは誤検知のチューニングに数週間かかります。攻撃側から見ても、既知の脆弱性を持つライブラリは探索コストが低く、実際の侵入経路として使われやすい状態です。ただし自社コードのSQL組み立てや認証処理に不安がある場合は順序が逆転します。両方を入れる前提で、着手順を決める話だと捉えてください。

SCAツールの費用はどのくらいかかりますか？

無償での開始が可能です。GitHub上のリポジトリなら Dependabot alerts は追加費用なしで有効化でき、OSV-Scanner や Trivy もOSSとして使えます。商用製品は開発者数やリポジトリ数に応じた年額課金が一般的で、到達可能性解析やライセンスポリシー管理が付く階層で価格が上がります。金額より先に押さえるべきは運用工数で、初回の棚卸しに数十人日、その後の定常運用に月あたり数人日を見込んでください。

検出件数が多すぎて対応しきれません。どう絞ればよいですか？

三段での絞り込みです。第一段はKEVカタログ収載の有無で、悪用が確認されているものは期限を切った修正対象です。第二段はEPSSとCVSSの組み合わせで、悪用確率が高く深刻度も高いものを次に置きます。第三段が到達可能性解析で、脆弱な関数への呼び出し経路が無いものは優先度を下げます。そのうえで、残りは定期的な依存更新の波で自然に消えるものとして扱ってください。全件をゼロにする目標は設定せず、期限付きで直す集合と、更新に任せる集合を分ける運用に切り替えるのが現実解です。

SBOMの提出を求められました。SCAツールで対応できますか？

できます。主要なSCAツールは CycloneDX 形式と SPDX 形式でのSBOM出力に対応しており、CIのビルド成果物として毎回生成する構成が組めます。注意点は二つで、どの形式をどのバージョンで求められているかを提出先に確認すること、そしてビルド時点で生成することです。提出後も脆弱性情報は更新され続けるため、SBOMを出して終わりにせず、同じ部品リストで再照合を回し続ける運用まで設計してください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る