ソフトウェア部品表（SBOM）とは何か

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

コンポーネントの可視性

多くの場合、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生成ツールのオープン ソース化などのプロジェクトに貢献しています。
• 自動車 - FordやGeneral Motorsなど、一部の大手自動車会社は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により、ソフトウェア コンポーネント、そのバージョン、および関連するライセンス情報の詳細なインベントリが提供されるため、組織は、情報に基づいて決定を下し、リスクを管理し、ソフトウェア プロジェクトの完全性とセキュリティを確保することが可能になります。