SCA（Software Composition Analysis：ソフトウェア構成解析）は、自社のアプリに取り込んだ外部の部品、とくにオープンソース（OSS）を洗い出し、既知の脆弱性とライセンスのリスクを突き合わせる仕組みです。今のソフトウェアは、自分で書いたコードより、借りてきた部品のほうが多く動いています。その借り物に穴があれば、自社のアプリにそのまま穴が空きます。SBOM（ソフトウェア部品表）が「何を使っているか」の一覧なら、SCA は「その一覧を作り、脆弱性と照らし、危ないものから直す」工程にあたります。2021年末の Log4Shell は、広く使われた OSS のログ部品に重大な穴が見つかり、世界中のシステムが一斉に危険にさらされた事例でした。本記事では SCA が何をするのか、SBOM との違い、そして開発に組み込む進め方を扱います。
LOCKED は、SSO と多要素認証で認証を束ねる LOCKED MSO、アカウントの発行・停止・棚卸しを自動化する LOCKED DAS、フィッシング訓練の LOCKED ATP を組み合わせたサービス群です。コードの中の部品を見張る SCA に対し、LOCKED はその開発基盤を守る「開発者アカウントとリポジトリ」の側を固める層になります。
無料で製品資料をお送りしています。開発基盤のアクセス管理の見直しにお使いください。 製品資料をダウンロードする →
SCAとは、借りてきた部品のリスクを洗い出す仕組み
アプリを作るとき、暗号化、画像処理、ログ出力といった機能をゼロから書く人はいません。すでにある OSS の部品を取り込んで組み立てます。速くて品質も高い反面、その部品に既知の脆弱性があれば、取り込んだ瞬間に自社のアプリの弱点になります。しかも、取り込んだ部品がさらに別の部品に依存していることが多く、開発者が存在すら知らない「間接的な依存（推移的依存）」の中に穴が潜みます。
この見えにくい部品の束を機械的に追うのが、SCA です。おおまかな流れは4つです。まずコードベースを走査して、使っている部品とバージョン、依存関係を特定します。次に、それぞれのライセンスと利用状況を記録します。そして、特定した部品を既知の脆弱性のデータベースと突き合わせます。最後に、深刻度や悪用のされやすさ、実際にそのコードに到達し得るか（到達可能性）をもとに、どれから直すかの優先順位をつけます。開発者が把握していない推移的依存の脆弱性まで見つけられる点が、手作業にはできない強みです。
ゼロトラスト実装の現実
ゼロトラストの理想と現実のギャップを分析。段階的な実装アプローチと、ID管理・デバイス管理から始める現実的なロードマップを提示します。
SBOMとの違いは、「一覧」か「工程」か
両者は一緒に語られますが、性質が違います。SBOM（ソフトウェア部品表）は、ソフトウェアに含まれる部品と依存関係、ライセンスをまとめた「一覧」、つまり成果物です。対して SCA は、その一覧を作り、脆弱性やライセンスと照らして管理する「工程・ツール」です。多くの SCA ツールは、標準形式（SPDX や CycloneDX）の SBOM を出力します。つまり SBOM の生成は、SCA が持つ機能の1つにすぎません。
| 観点 | SBOM | SCA |
|---|---|---|
| 性質 | 部品と依存の一覧（成果物） | 部品を見つけ、脆弱性を照合する工程・ツール |
| 主な役割 | 構成情報の可視化・共有 | 脆弱性・ライセンスリスクの検出と是正 |
| 典型的な使い道 | 取引先への提出、法令対応、インシデント時の影響範囲特定 | 開発中の自動スキャン、ビルド時のブロック |
関係を一言でいえば、SBOM は「何が入っているかの棚卸し結果」、SCA は「棚卸しして、危ないものを見つけて直す仕事」です。Log4Shell のとき、被害を早く抑えられた組織とそうでない組織を分けたのは、「自社のどの製品に、どのバージョンの Log4j が入っているか」を即座に言えたかどうかでした。SBOM でその一覧を持ち、SCA で脆弱性と照らし続ける。この組み合わせが、サプライチェーン攻撃への備えになります。
SASTとの違いは、見るのが「自社コード」か「借り物」か
もう1つ混同されやすいのが SAST（静的アプリケーションセキュリティテスト）です。SAST は、自社で書いたコードそのものを検査し、そこに潜むバグや危ない書き方を見つけます。対して SCA が見るのは自社コードではなく、取り込んだ OSS 由来のリスクです。
両者は守る範囲が違うので、置き換えではなく併用します。自分で書いた部分は SAST、借りてきた部分は SCA。アプリは両方でできているので、片方だけでは半分しか見ていないことになります。クラウド設定の層まで含めて通して見たいなら、CSPMなど別の道具が加わります。
SCAが見つける2種類のリスク：脆弱性とライセンス
照合するのは、脆弱性だけではありません。OSS には使用条件を定めたライセンスがあり、これを守らないと法的なリスクになります。
脆弱性の面では、取り込んだ部品のバージョンを既知の脆弱性情報（CVE など）と突き合わせ、「このバージョンには、この深刻度の穴がある」と知らせます。直すには、修正済みのバージョンへ上げるのが基本です。
ライセンスの面では、部品ごとのライセンス種別を洗い出します。種類によっては、自社のソースコードの公開を求めるものや、商用利用に条件が付くものがあります。知らずに取り込むと、製品の出荷後に条件違反が発覚する、という事態になりかねません。この2つを同時に棚卸しするので、セキュリティと法務の両面でリスクを早期に把握できます。
SCAを開発に組み込む進め方
SCA は、リリース直前に一度回すより、開発の流れに組み込んで継続的に回すほうが効きます。穴は日々新しく見つかるので、一度きりの検査ではすぐ古くなるからです。
- 対象と範囲を決める — まず重要な製品やサービスから始めます。すべてのリポジトリを一度に対象にしない
- CI/CDに組み込む — コードを変更するたびに自動で走査が走るようにします。ビルドの段階で危険な部品を止める（ブロックする）設定もできます
- SBOMを生成・保管する — 走査の結果として標準形式の SBOM を出力し、一元管理します。新しい脆弱性が出たとき、どの製品が該当するかを即座に照合できます
- 優先順位をつけて直す — 検出された脆弱性すべてを一度に直そうとせず、深刻度と到達可能性の高いものから対応します
- 誤検知と向き合う — SCA は既知の脆弱性データベースとの照合なので、「部品は入っているが、その穴に実際には到達しない」ケースも警告に出ます。到達可能性の分析を持つツールを選ぶと、選り分けの手間が減ります
制度面の後押しもあります。経済産業省は「ソフトウェア管理に向けた SBOM の導入に関する手引」を公開し、脆弱性管理の文脈で部品の可視化を促しています。SBOM を求められる場面が増えるほど、それを生成し運用する SCA の役割も大きくなります。
開発者アカウントとリポジトリの保護状況を、無料でご相談を承っています。 デモ・個別相談を申し込む →
SCAが見ないところ：開発者アカウントとリポジトリの乗っ取り
SCA は、コードに取り込んだ部品のリスクを洗い出します。ただし、サプライチェーン攻撃の入口はそれだけではありません。近年目立つのは、OSS のメンテナや開発者のアカウントが乗っ取られ、正規の部品に悪意あるコードを混ぜ込まれる手口です。この場合、混ぜ込まれた直後は「既知の脆弱性」ではないので、SCA の照合だけでは拾いにくいことがあります。
だからこそ、部品を見張る SCA と並んで、開発基盤そのものを守ることが要ります。コードの保管庫（リポジトリ）に入れるアカウント、部品を公開する開発者のアカウント、これらが乗っ取られれば、SCA が信頼している「正規の部品」そのものが汚染されます。
LOCKED MSO は、リポジトリや開発基盤へのログインを SSO と多要素認証で束ね、パスワードが1つ漏れても入れない状態を作ります。LOCKED DAS は入社・退社に合わせたアカウントの発行と停止、権限の棚卸しを自動化するので、退職した開発者のアカウントや余分な権限が残りません。LOCKED ATP のフィッシング訓練は、開発者を狙った偽メール（OSS メンテナ乗っ取りの起点になりやすい）への組織耐性を高めます。部品のリスクを見張る前提として、その部品を扱う人とアカウントを守っておく、という分担です。
開発基盤のアクセス管理とアカウント棚卸しから、無料でご相談を承っています。 資料請求・デモ依頼はこちら →
参考資料
- 経済産業省：ソフトウェア管理に向けたSBOMの導入に関する手引
- IPA（情報処理推進機構）：サプライチェーンリスクマネジメント
- CISA：Software Bill of Materials (SBOM)
- OWASP Dependency-Check