ソフトウェア構成分析（SCA）とは

SCAツールの動作では、ソフトウェアのソースコードをスキャンし、それをデータベースに収集し、既知の脆弱性データベースと比較し、更新やライセンスの問題を確認して、レポートが作成されます。

ソフトウェア構成分析では、独自のコンポーネントやコンテナ・イメージなど、あらゆる種類のソフトウェア要素をスキャンできますが、最も一般的にはオープンソース・ライブラリーの分析に使用されます。オープンソース・コンポーネントは、ほぼすべての最新のコードベースにある程度含まれており、コードの脆弱性は公になっているため、オープンソース・ソフトウェアを最新の状態に保ち、透明性を維持することが特に重要です。

SCAツールは、出所が不明なソフトウェア・コンポーネントによるセキュリティー脆弱性、異なるオープンソース・ライセンス間の互換性の問題、オープンソース・ライブラリーについての不完全または不十分なドキュメンテーションやサポートなどのリスクを管理します。

ソフトウェア構成分析は、ソフトウェア開発プロセスをIT運用と統合するクラウドネイティブな DevOpsパイプラインの一部です。SCAはまた、組織のセキュリティー体制を、セキュリティーと開発およびオペレーションを統合するDevSecOpsパイプラインの一環としてサポートします。SCAツールは統合開発環境（IDE）にデプロイすることができ、開発プロセス中にリアルタイムでコード解析を行うことができます。

SCAは、静的アプリケーション・セキュリティ・テスト(SAST)、動的アプリケーション・セキュリティ・テスト(DAST)、依存性スキャンなど、他の脆弱性スキャンとは形式が異なります。

ITチームは、多くの場合、SCAツールを使用してソフトウェア部品表（SBOM）を生成しますSBOMは、コンプライアンスとサプライチェーン・セキュリティのために、ソフトウェア製品内のすべてのコンポーネント、ライブラリ、モジュールを機械可読形式でリスト化します。SBOMはまた、SCAスキャンポリシーにさらに情報を提供することもできます。

International Data Corporationの調査データによると、2024年時点で従業員100人以上の企業の93%がオープンソース・ソフトウェアを使用しており、SCAソリューションの幅広いニーズが浮き彫りになっています。¹

SCAはソースコードを収集し、それを脆弱性データベースと比較し、コードベースを分析してコンプライアンスの潜在的な問題を探し、誤検知を除去し、 サイバーセキュリティーや開発チーム向けのレポートを作成します。

SCAツールは、オープンソースコンポーネントとサードパーティー依存関係に主に焦点を当てながら、開発ライフサイクル全体にわたり継続的統合と継続的デリバリー（CI/CD）パイプラインの一環として、開発中にコードを積極的にスキャンし分析します。

そのために、SCAツールはまず、コンポーネント、フレームワーク、ライブラリ、コンテナイメージ、モジュール、依存関係など、IT環境にあるすべてのソフトウェアの基本要素をリストアップします。SCAスキャンの主な形態は以下の2つです：

• 静的またはマニフェスト・スキャンでは、構成およびメタデータ・ファイルを読み取り、そこに明示的に記述されている要素を見つけます。

• 動的スキャンまたはランタイム・スキャンでは、バイナリー・コードをスキャンすることで、リアルタイムで実行されるライブラリーを特定します。

どちらの種類のスキャンにもメリットとデメリットがあります。静的スキャンには、実際にはランタイム環境にデプロイされていないソースコード内のサードパーティコンポーネントに起因する脆弱性が含まれる可能性があり、誤検知を生みます。一方、動的スキャンの場合、コードのすべての要素がランタイム環境で実行されている訳ではない関係で、完全に実施されない可能性があります。多くの組織は、両方を組み合わせて使用しています。

コードの収集を完了したSCAツールは、ソフトウェア部品表（SBOM）を作成し、そのSBOMのコンポーネントを、一般的な脆弱性と最新のソフトウェアのセキュリティー・リスクを説明したデータベースと比較します。

セキュリティチームは、SBOMを既知のセキュリティ脆弱性の独自データベースと、National Vulnerability Database(NVD)や共通脆弱性識別子(CVE)リストのような公開データベースの両方と比較しています。潜在的な脆弱性にフラグが立てられると、SCAツールはそれぞれに脅威スコア（多くの場合、CVSS：共通脆弱性評価システムを使用）を割り当て、サイバーセキュリティー・チームが修復の優先順位を決定できるようにします。

一部のセキュリティー・ツールは、CI/CDパイプラインの一部として適切なパッチまたはアップデートを適用することで、脆弱性管理を自動化します。セキュリティチームは通常、このプロセスを監視して、適用された変更が既存の依存関係や機能に影響を与えないことを確認します。

SCAツールは、コンプライアンスを確保するために、ソフトウェア・ライセンスに関する会社のポリシーや法律に照らしてSBOMをチェックします。

オープンソース・イニシアチブは、100以上の承認されたオープンソース・ライセンスをリストアップしており、そのうちのいくつかは、オープンソース・コードから独自製品を作成することを許可しています。ただし、すべてが互換性があるわけではないため、組織は自社製品がコンプライアンスに準拠していることを確認する責任があります。

SCAソリューションでは、すべてのオープンソース・ソフトウェアに必要な帰属の明記があることや、著作権で保護された独自ソフトウェアでの使用を禁止する「コピーレフト」の対象となる要素がソフトウェアの開発に含まれていないことを確認できます。

ソフトウェア構成分析では、潜在的な脆弱性の主な原因である、プロジェクト・コンポーネント間の依存関係も検知できます。

SCAツールは、直接依存関係（ソフトウェア・コンポーネントがコード・レベルで相互に直接使用される依存関係）と推移的な依存関係の両方を検知できます。推移的な依存関係は、あるソフトウェアが、直接的な依存関係の1つが依存しているソフトウェア・コンポーネントに間接的に依存するようになった場合に発生します。たとえば、コンポーネントAはコンポーネントBに依存し、コンポーネントBはコンポーネントCに依存しています。このシナリオでは、コンポーネントAはコンポーネントCに推移的に依存します。

SCAツールは、誤ったアラートの数を減らすために、どの依存関係が脆弱性をもたらし、どの依存関係がそうでないかを判断する必要があります。これは、ソフトウェアのサプライチェーンを評価し、コードの脆弱性が「到達可能」かどうか、つまり、ネットワークの現在の構成を考慮したとき、ランタイム環境で呼び出されるかどうかを判断することによって行われます。

その後、ソフトウェア構成分析の成果はレポートにまとめられ、多くの場合、独自のダッシュボード、JSONファイルなどの未加工データ、新しいSBOM、またはそれら3つすべてを組み合わせて示されます。

近年、開発者は、これらのレポートにおける誤検出を減らす点で進歩を遂げています。

• 脆弱メソッド分析では、ソフトウェア・コンポーネントの呼び出しパスをトレースし、検出された脆弱性に到達できるようにします。

• 機械学習と人工知能は誤検知の特定に貢献しています。適切なトレーニングを行うことで、モデルは脆弱性が到達可能かどうかを正確に識別できます。自然言語処理は、GitHubなどのリポジトリーからのバージョン管理のコミット・メッセージを分析し、コード内で特定できない潜在的な問題を検知するためにも使用されます。

一部のSCAツールには、継続的な監視機能と自動修復機能が含まれており、この実践をDevSecOpsの開発ワークフローにさらに統合しています。自動修復は通常、ライセンスの問題を修正したり、新しいセキュリティー・パッチを適用したりするために開発者に通知する、プル・リクエストを開始することによって行われます。

SCAのメリットには、組織のコンプライアンスとサイバーセキュリティーの取り組みに対する信頼が高まることや、ITワークフローの自動化が進むことなどがあります。

SCAは、ITエコシステム内のすべてのオープンソース・コンポーネントがライセンスおよびコンプライアンス要件に従って使用されるようにすることで、組織が法的リスクを軽減するのに役立ちます。

オープンソース・ソフトウェア・コンポーネントの予測不可能性によって生じるネットワークの脆弱性を特定することは、ITリスク管理の重要な部分です。オープンソース・ソフトウェアのサプライチェーンの透明性を高めることで、組織はカスタマイズ性とコスト削減のメリットを享受しながら、付随するセキュリティー・リスクを軽減できたという確信が持てるようになります。

SCAソリューションにより、脆弱性、依存関係、コンプライアンスの追跡の大部分を自動化することで、ITチームは他のタスクに専念できるようになります。この広範囲にわたる自動化は、組織のDevOpsプラクティスの強化にも役立ちます。

ソフトウェア構成分析がもたらす課題には、脆弱性の追跡、誤検知の制限、分析範囲の管理における包括性の欠如などがあります。

ソフトウェア構成分析は、最新のアプリケーションのセキュリティー脆弱性を特定するために使用される2つの追加のテスト方法であるDASTやSASTとは異なります。

SCAがITチームにソフトウェア・コンポーネント、依存関係、脆弱性の包括的なマップを提供するのに対し、DASTとSASTは、それらのコンポーネントとそれらが構成するもっと大規模なソフトウェア・アプリケーションの個々の欠陥に焦点を当ててそれを明らかにします。

DASTとSASTの違いは、SCAにおける静的スキャンと動的スキャンの違いに似ています。動的アプリケーション・セキュリティー・テスト（DAST）は、本番環境のアプリケーションを評価し、悪意のあるユーザーやサイバー攻撃を模倣してセキュリティー上の問題を特定するのを支援します。静的アプリケーション・セキュリティー・テスト（SAST）は、アプリのソースコードを掘り下げて、コードの記述時に脆弱性を検索します。

SCAが、あるソフトウェアに含まれるコンポーネントの列挙と分析に重点を置いているのに対して、DASTとSASTは、そのソフトウェアにセキュリティ上の脆弱性がないかどうかを（前者ではランタイム、後者ではソースコードのいずれかにおいて）テストすることに特に重点を置いています。どちらもSCAと併用されることが多いですが、独立して実践されることもあります。

SCAは、組織のITオペレーションにおけるアプリケーション、システム、プロセス間の関係を特定、理解、可視化するプロセスである依存関係マッピングとは異なります。

SCAツールは、コンポーネントの依存関係の概要を提供し、それらから発生する可能性のある潜在的な脆弱性を特定しますが、依存関係マッピングとは、IT環境全体の依存関係を特定するより広範なカテゴリーのオブザーバビリティー・プラクティスのことを指します。

依存関係マッピングでは、アプリケーション内およびアプリケーション間の依存関係に焦点を当てることができますが、より広範に、ネットワーク・インフラストラクチャーやスマート電力網などの現実世界のシステム全体の依存関係を探すこともできます。依存関係マッピングはSCAプラクティスのコンポーネントであることが多いですが、SCAソリューションとは独立して、単独で実行することもできます。