ソフトウェア部品表 (SBOM) とは
SBOMは、あるアプリケーションに関連付けられているすべてのソフトウェアコンポーネント、依存関係、メタデータをまとめた包括的なリストです。ソフトウェア製品を構成するすべての要素のインベントリーとして機能します。組織は、SBOMを使用して、自社のアプリケーションを十分に把握し、管理して安全性を確保できます。
次のような要因により、SBOMが必要となっています。
- ソフトウェアの透明性を確保する
- オープンソースソフトウェアとサードパーティの依存関係を管理する
- セキュリティの脆弱性を特定して軽減する
- 法的要件と規制要件を遵守する
2021年5月に米国の行政機関によって国家サイバーセキュリティの向上に関する大統領令が出されました。ソフトウェアサプライチェーンのセキュリティを強化するうえでSBOMが重要であることを強調する内容となっています。
インベントリーとしてのSBOM
SBOMには、ソフトウェアコンポーネントと依存関係のインベントリーが含まれています。今日のソフトウェアアプリケーションでは、よくサードパーティのライブラリとフレームワークが利用されます。このような依存関係の多くが、他のコンポーネントへの独自の依存関係を持ちます。そのため、コンポーネントが相互に接続されてネストが複雑になります。こうした依存関係を明確に理解することは、組織にとって極めて重要です。SBOMを実装すると、こうした関係とアプリケーションの構成方法を可視化して、組織のソフトウェアサプライチェーンを効率よく管理できます。
このインベントリーには、コンポーネントの提供元とライセンスの情報も含まれます。各コンポーネントの提供元とライセンスを理解することで、コンポーネントの使用にあたって法的要件とライセンス条件を確実に遵守できるようになります。SBOMがあると、信頼できない提供元のコンポーネントの使用や、ライセンス条件への違反といった、組み込まれるコンポーネントによってもたらされるリスクを評価できます。
SBOMを使用した既知の脆弱性のチェック
SBOMは、セキュリティの脆弱性を特定して軽減するうえでも極めて重要な役割を果たします。コンポーネントと依存関係のインベントリーがあると、既知の脆弱性のデータベース(共通脆弱性識別子データベースなど)に照らしてインベントリーを体系的にチェックできます。セキュリティチームは、攻撃者に悪用される前に、ソフトウェアアプリケーションの依存関係の潜在的な脅威をプロアクティブに特定して対処できます。
SBOMの形式と標準
SBOMを作成して共有するための形式と標準がこれまでいくつか登場しています。形式が標準化されていれば、ソフトウェアサプライチェーン全体でのSBOMデータの共有が容易になり、さまざまなステークホルダーの間で透明性とコラボレーションが促進されます。よく知られた形式に次のものがあります。
いずれの形式でも、ソフトウェアエコシステムごとに異なる詳細レベルが用意されており、自社のニーズに最も適した形式を選択できます。
クラウドネイティブなアプリケーションがSBOMに及ぼす影響
クラウドネイティブなアプリケーションの登場で、ソフトウェアエコシステムの複雑さが増しています。こうしたアプリケーションは広く分散し、多くの場合事前構築されたコンテナイメージに依存し、そのうえ数百や数千ものマイクロサービスで構成される場合もあります(しかもマイクロサービスのそれぞれに独自のコンポーネントと依存関係があります)。そのため、ソフトウェアサプライチェーンのセキュリティを確保するというタスクは行き詰まりを見せています。これらのアプリケーションは、適切に管理されていない場合、セキュリティの脆弱性をもたらすリスクがあります。
以上の背景から、クラウドネイティブなアプリケーションのセキュリティを確保するうえでSBOMが重要な役割を果たすことは明白です。SBOMはソフトウェアコンポーネントをまとめた包括的なインベントリーであり、潜在的な脆弱性がないか体系的にチェックできるため、クラウドで組織のアプリケーションを効率よく管理し、安全性を確保できます。
SBOMを実装する利点
SBOMを実装すると、組織にとっては次のような利点があります。
- セキュリティポスチャの向上:SBOMを実装すると、潜在的なセキュリティリスクを効率よく特定して対処できます。
- 脆弱性管理の効率化:脆弱性に優先順位を付けて効率よく修復できます。
- チーム間でのコラボレーションの強化:アプリケーションのコンポーネントとそれに関連するリスクの理解を共有することで、組織内のさまざまなチーム(開発、セキュリティ、法務など)が効率よくコラボレーションできるようになります。
- ソフトウェアの監査とコンプライアンスチェックの簡便化:法的要件と規制要件に遵守していることを容易に実証できます。また、社内でソフトウェア監査を実施して、自社のアプリケーションのセキュリティと品質を確保できます。
SBOM導入の課題
SBOMに利点があることは明白ですが、ソフトウェア開発ライフサイクルにSBOMを組み込むと、いくつかの課題に直面することがあります。
- 既存のツールとワークフローとの統合:SBOMの生成と管理を既存の開発とセキュリティのプロセスに統合するにあたって、戦略的かつ一貫性をもって取り組む必要があります。ただし、開発速度に悪影響が及ぶ可能性があります。
- 正確かつ最新の情報の確保:SBOMの情報の精度を保ち、最新の状態に維持するのは(特に更新や変更が頻繁に行われるアプリケーションの場合)、時間とリソースを大量に消費する作業です。
- プライバシーと知的財産に対する懸念への対処:SBOMを外部のステークホルダーと共有すると、独自仕様や機密情報の開示について組織内に懸念が生じる可能性があります。セキュリティと透明性とのバランスを探る必要があります。
- ソフトウェアサプライチェーン全体での導入の促進:これを本当に効果的なものにするには、ソフトウェアサプライチェーンの全当事者がSBOMを導入して共有する必要があります。この方向に進むには、すべてのステークホルダーの間でコラボレーション、標準化、透明性確保への取り組みが必要になります。
SBOMと脆弱性管理ツールとの統合
組織のセキュリティポスチャをさらに強化するために、SBOMを脆弱性管理ツールと統合できます。例えば、アプリケーションやコンテナのスキャンツールでは、SBOMに記載された情報を使用して、既知の脆弱性や脅威がないかスキャンできます。自動セキュリティツールでは、CVEデータベースに照らしてSBOMインベントリーを日常的にチェックできます。組織でコンポーネントを使用することがライセンス条件に違反しているときには、アラートを生成できます。
脆弱性管理とコンプライアンス監査プロセスにSBOMデータを組み込むことで、組織の取り組みに効率よく優先順位を付け、的を絞って効率よくリスクに対処できます。
CrowdStrike Falcon® Cloud Securityには、ワークロードとコンテナを完全に可視化できるCloud Workload Protectionが組み込まれています。CrowdStrike Falcon® Cloud Securityにはコンテナイメージ、レジストリー、ライブラリのスキャンが事前構築されているので、脅威を早期に検知する、迅速にアラートを通知する、修復に向けて実用性のあるインサイトを得るといったことができます。
SBOM(ソフトウェア部品表)に関するFAQ
Q:サイバーセキュリティにおけるSBOMとは何ですか?
A:SBOM(ソフトウェア部品表)は、ソフトウェアアプリケーションで使用されているすべてのコンポーネント、ライブラリ、依存関係を詳しく記載したインベントリであり、潜在するセキュリティの脆弱性やライセンスの問題を可視化できます。
Q:BOMとSBOMの違いは何ですか?
A:BOM(部品表)は、製造やソフトウェア開発で使用されるコンポーネントの総合的なリストです。一方、SBOMは特にソフトウェアに焦点を当てたリストで、ライブラリ、依存関係、バージョンが明示されているため、セキュリティリスクの管理に役立ちます。
Q:DevOpsにおけるSBOMとは何ですか?
A:DevOpsでは、ソフトウェアの依存関係を追跡および管理するのにSBOMを利用します。CI/CD(継続的インテグレーションと継続的デプロイ)パイプライン内でセキュリティ、コンプライアンス、脆弱性管理を強化できます。
Q:SDLCにおけるSBOMとは何ですか?
A:SDLC(ソフトウェア開発ライフサイクル)では、SBOMを利用してソフトウェアコンポーネントの透明性を確保し、開発のあらゆる段階でセキュリティ評価、脆弱性スキャン、コンプライアンスチェックを実行できるようにします。
Q:ソフトウェア部品表には何が記載されていますか?
A:SBOMには通常、ソフトウェアコンポーネント名、バージョン、ライセンス情報、CVE(既知の脆弱性)、依存関係といった詳しい情報が記載されています。これにより、セキュリティリスクを効果的に追跡および軽減できるようになります。