ソフトウェア部品表 (SBOM) とは何ですか?

SBOM を使用すると (特に OSS で)、組織はコンポーネントと依存関係を可視化し、リスク管理を改善するなど、さまざまなことが可能になります。 以下に、これらの利点について概説します。

コンポーネントの可視性

OSS には、さまざまなサードパーティ コンポーネントと依存関係が組み込まれることがよくあります。 SBOM を使用すると、開発者とユーザーはソフトウェアで使用されるすべてのコンポーネントを明確に把握できます。 これには、オープンソース ライブラリとフレームワーク、およびそれらの特定のバージョンが含まれます。 この可視性は、ソフトウェアの構成を理解し、潜在的な脆弱性を特定し、オープンソース コンポーネントに関連するライセンス義務を追跡するのに役立ちます。

脆弱性管理

他のソフトウェアと同様に、OSS もセキュリティ上の脆弱性の影響を受ける可能性があります。 SBOM を使用すると、組織はオープンソース コンポーネントのバージョンを追跡し、それらのバージョンに関連する既知の脆弱性について最新情報を入手できます。 これにより、セキュリティ上の懸念を軽減して報告するためのパッチやアップデートを迅速に適用することで、プロアクティブな脆弱性管理が可能になります ( RFC8615を参照)。 最新の SBOM を導入することで、組織は脆弱性の影響を評価し、ソフトウェアを保護するための適切な対策を講じることができます。

サプライチェーンのセキュリティ

近年、ソフトウェアサプライチェーンのセキュリティは大きな懸念事項となっています。 SBOM は、ソフトウェアで使用されるコンポーネントとその出所の透明性を提供することで、サプライ チェーンのセキュリティ強化に貢献します。 また、組織は依存するコンポーネントの信頼性とセキュリティ体制を評価することもできます。 SBOM を使用すると、組織は侵害されたコンポーネントや悪意のあるコンポーネントに関連するリスクを特定して軽減し、ソフトウェア サプライ チェーン攻撃の可能性を減らすことができます。

コラボレーションとパッチ管理

OSS はコラボレーションとコミュニティの参加を奨励します。 SBOM は、さまざまな貢献者や利害関係者間でソフトウェアのコンポーネントに関する共通の理解を提供することで、効果的なコラボレーションを促進します。 更新または修正が必要なコンポーネントを明確に識別することで、パッチ管理作業の調整に役立ちます。 すべての参加者が共有 SBOM を参照してセキュリティの脆弱性やその他の問題に対処できる場合、オープンソース コミュニティ内でのコラボレーションはより効率的になります。

規制遵守

一部の業界では、規制の枠組みにより、組織はアプリケーションやシステムで使用されるソフトウェア コンポーネントに対する透明性と制御を実証する必要があります。 SBOM は、これらのコンプライアンス要件を満たすために必要なドキュメントを提供します。 これにより、組織は、特に OSS のセキュリティとライセンスの側面に関して、デューデリジェンス、トレーサビリティ、および関連規制への準拠を実証できます。

ライセンスコンプライアンス

OSS は通常、ソフトウェアの使用方法、変更方法、配布方法を規定する特定のライセンスによって管理されます。 SBOM は、すべてのオープン ソース コンポーネントとそれに対応するライセンスの包括的な概要を提供します。 これにより、組織は使用している OSS のライセンス条件に準拠できるようになります。 ライセンス義務を理解することで、組織は法的またはコンプライアンスの問題を回避しながら、ソフトウェアの配布と使用について十分な情報に基づいた決定を下すことができます。

銀行や医療など、規制が厳しい業界の政府や組織の中には、SBOM の使用を推奨したり、社内またはサプライヤーに対して SBOM の使用を必須にすることを検討しているところもあります。

SBOM を使用している業界の例

• 公共部門 –米国、欧州連合、英国、日本など、SBOM の使用を活用、規制、または推奨している国は数多くあります。
• テクノロジー – Google、Microsoft、IBM などの大手テクノロジー企業は、自社のソフトウェア開発プロセスに SBOM を実装し、 Software Package Data Exchange (SPDX) 、 OWASPなどのプロジェクトに貢献し、 SBOM 生成ツールをオープンソース化することで先頭に立っています。
• 自動車 –フォードやゼネラルモーターズなどの大手自動車会社数社は SBOM を実装しており、自動車システムで使用されるコンポーネントとソフトウェアに対してサプライヤーに SBOM を提供するよう奨励しています。
• ヘルスケア – 米国市場の医療機器メーカーは現在、2022 年の食品医薬品局規制に準拠するために 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 を構築するためのベスト プラクティスを反映した、失敗の一般的な原因をいくつか示します。

• 不完全または不正確な在庫: SBOM がプロジェクトで使用されるすべてのソフトウェア コンポーネントを正確にキャプチャしていない場合、または不完全な情報が含まれている場合、ソフトウェア サプライ チェーンの理解に盲点やギャップが生じる可能性があります。 インベントリが欠落していたり不正確だったりすると、脆弱性や依存関係が見落とされ、SBOM の有効性が損なわれる可能性があります。
• コンポーネントの可視性の欠如: SBOM がソフトウェア コンポーネントの起源、バージョン、依存関係を明確に可視化できない場合、関連するリスクを効果的に評価および管理することが難しくなります。 包括的な可視性がなければ、脆弱性を追跡し、パッチ更新を特定し、ライセンス要件への準拠を確保することが困難になります。
• 手動および時代遅れのプロセス: SBOM の作成と維持を手動プロセスに依存すると、非効率性とエラーが発生する可能性があります。 SBOM がソフトウェア プロジェクトの変更を反映するために定期的に更新されない場合、SBOM はすぐに古くなり、セキュリティとコンプライアンスの目的で信頼できる参照としての価値を失います。
• メタデータとコンテキストが不十分です: SBOM は、ソフトウェア コンポーネントのリストだけではなく、ライセンス情報、既知の脆弱性、リリース日などの関連メタデータも提供する必要があります。 この追加のコンテキストが欠落しているか不完全な場合、リスクを正確に評価し、情報に基づいた意思決定を行う能力が妨げられます。
• 利害関係者の協力の欠如: SBOM を効果的に活用するには、ソフトウェア サプライ チェーンの関係者間のコラボレーションと情報共有が不可欠です。 SBOM 情報を共有する際の協力が不足していたり、共有を躊躇したりすると、脆弱性を総合的に特定して対処することが困難になり、ソフトウェアの全体的なセキュリティが損なわれます。
• ツールと自動化の制限: SBOM を手動で作成して保守すると、時間がかかり、エラーが発生しやすくなります。 適切なツールと自動化がなければ、SBOM を効率的に生成、更新、管理することが困難になります。 自動化が不十分だと、新たな脆弱性や依存関係の特定が遅れる可能性もあります。
• 脆弱性監視が不十分: SBOM は、堅牢な脆弱性監視プロセスによって補完される必要があります。 ソフトウェア コンポーネントに関連する新しい脆弱性やセキュリティ更新を定期的に監視しないと、潜在的なリスクに気付かず、ソフトウェアが既知の脆弱性にさらされる可能性があります。

全体として、SBOM は OSS の複雑さを管理するための貴重なツールです。 オープンソース エコシステム内の透明性、セキュリティ、コンプライアンス、コラボレーションを促進します。 SBOM は、ソフトウェア コンポーネント、そのバージョン、および関連するライセンス情報の詳細なインベントリを提供することで、組織が情報に基づいた意思決定を行い、リスクを管理し、ソフトウェア プロジェクトの整合性とセキュリティを確保できるようにします。