サイバー攻撃がますます巧妙化し、頻度も高まる中、脆弱性を可能な限り正確に追跡するため、SBOM（ソフトウェア部品表）はソフトウェアサプライチェーン全体で一般的な取り組みになっています。ソフトウェア部品表は、アプリケーションを構成するさまざまな要素を開示することで、ソフトウェア購入者がより十分な情報に基づいて購入を判断できるようにします。
ソフトウェア部品表（SBOM）とは？
ソフトウェア部品表には、透明性とセキュリティを確保するため、オープンソースかプロプライエタリかを問わず、ソフトウェアの構成要素が記載されます。構成要素には次のようなものがあります。
- 依存関係
- ファームウェア
- 階層関係
- ライブラリ
- ライセンス
- オペレーティングシステム
- メタデータ
SBOMは、ソフトウェアの開発に使われた材料を説明する栄養成分表示に似た働きをします。ただの構成要素の一覧ではなく、ソフトウェアのバージョンやアップデートのカタログでもあります。つまり、ソフトウェアの進化に合わせて更新される、生きた文書なのです。
SBOMはなぜ使われるのか？
ソフトウェア開発には第三者が関与するため、ソフトウェアサプライチェーンは次第に攻撃を受けやすくなっています。実際、2021年にはPythonのオープンソースコードリポジトリが悪意ある行為に対して脆弱になりました。Pythonを利用する第三者製ソフトウェアは危険にさらされ、さらにその下流で、そのソフトウェアを利用する企業も危険にさらされました。もしその第三者製ソフトウェアにSBOMがあれば、サプライチェーンのさらに下流にいるユーザーは脆弱性を知らされ、より詳しく調査できたでしょう。
SBOMのメリット
SBOMは、セキュリティを重視するあらゆる組織にメリットをもたらします。HypergiantのDevSecOps担当バイスプレジデント、Bren Briggs氏によると、SBOMは「サイバーセキュリティ管理に不可欠な要素」です。Briggs氏はさらに、「資産インベントリは、脆弱性のリスクを低減するために組織が利用できる、最も基本的な管理策だ」と述べています。サイバーセキュリティ攻撃が複雑化・頻発化する中、Briggs氏は、SBOMを導入することは、組織が「基本的な管理策を規律正しく実施し」、より少ない労力とコストで「はるかに高い水準のセキュリティ」を実現するための良い方法だと考えています。
SBOMはまた、ソフトウェア購入者の力を高め、適応性、コンプライアンス、サプライチェーンの完全性を確保します。
適応性
SBOMには過去のソフトウェアバージョンのカタログが含まれているため、アップデートによってソフトウェアの性能やセキュリティが損なわれたり脅かされたりした場合、ソフトウェア開発者は以前のバージョンにすばやく戻せます。
購入者の優位性
そのためSBOMは、ソフトウェアに何が含まれているか、どのような潜在的脆弱性があるかについて、ソフトウェア購入者の可視性を高めます。これにより、アプリケーションの導入を決める前の調査・購入プロセスを、購入者自身が管理できるようになります。
コンプライアンス
SBOMは企業の裁量だけで決められるものではありません。バイデン大統領は大統領令で、サイバーセキュリティを向上させるため、アプリケーション開発者にソフトウェア部品表の提供を義務付けました。
同様に、2020年のカリフォルニア州およびオレゴン州のIoTサイバーセキュリティ法によると、メーカーは、定期的かつ自動的なセキュリティアップデートなど、標準的なセキュリティ機能をデバイスのソフトウェアに組み込まなければなりません。
SBOMには、ソフトウェアへの変更履歴とバージョンが記録されるため、開発者は記録を維持しやすくなり、監査の際にも規制基準への準拠を保てます。
サプライチェーンの完全性
総じて、ソフトウェアサプライチェーン全体で警戒を強めた結果、透明性を確保する目的でSBOMが使われるようになりました。ベンダー側では、SBOMによってソフトウェア開発者は第三者製コンポーネントへの警戒を高められます。SBOMはソフトウェアの構成要素に対する可視性を高め、コンポーネントの依存関係を容易に管理できるようにし、業界のベストプラクティスや標準の実践を支援します。SBOMはサプライチェーンの完全性を高め、開発者、ベンダー、顧客がセキュリティへの取り組みに関する情報を共有し、足並みをそろえられるようにします。
SBOMのデメリット
難しさ
SBOMの作成は、単純明快な作業ではありません。製造現場では個々の部品の一覧が機能しますが、ソフトウェア開発はそのようには進みません。開発者が第三者製ソフトウェアから特定のファイル、関数、あるいはコードの一部の行だけを組み込む場合もあり、SBOMの作成は難しくなります。
誤警報
ソフトウェアの構成要素は、それ自体が本質的に脆弱なのではなく、ソフトウェア内でどのように使われているかによって脆弱になります。そのため、顧客が脆弱性の追跡をSBOMだけに頼るのは適切ではありません。問題のコンポーネントは、特定の方法で使われた場合にのみ脆弱になる可能性があるからです。したがって、顧客に誤警報を発しないよう、SBOMには利用状況のコンテキストも含めるべきです。
時間の負担
SBOMの作成にはコンポーネントの追跡が必要で難しいため、時間もかかります。さらに、米国電気通信情報局（NTIA）のガイドラインに沿ったSBOMの作成を支援するツールの使い方をスタッフに教えることも、作業を長引かせる要因です。SBOMの作成に時間がかかるからといって、セキュリティと透明性をおろそかにしてよいわけではありません。しかし、ソフトウェア開発者が考慮すべき大きな課題であることは確かです。
データ不足
SBOMの有効性に懐疑的な人々は、サイバーセキュリティ攻撃の防止におけるSBOMの有効性を裏付けるデータがNTIAに不足していると指摘しています。SBOMは理論上は有効でも、ソフトウェア開発者や顧客の注意を、差し迫ったより深刻なリスクからそらすことで、最終的にはメリットよりも害をもたらす可能性があります。
SBOMは正しい方向への一歩
SBOMサービスは、脆弱性管理、第三者リスク管理、ソフトウェア構成分析の各サービスに、ますます組み込まれるようになっています。SBOMはサイバー攻撃を予防するものでも万能の解決策でもありませんが、ソフトウェア開発者や顧客がリスクを特定し、対処するための透明性と警戒を高める一歩です。