ソフトウェア・サプライチェーンを可視化し、強固なセキュリティを実現するSBOM

米国では、相次ぐサイバー紛争／サイバー攻撃の対応策として、政府のソフトウェア調達の際にSBOM(Software Bill Of Materials)の開示が義務化されています。日本ではまだ議論の段階ですが、2023年に経済産業省が『ソフトウェア管理に向けたSBOMの導入に関する手引』を公表するなど、その有用性は周知されつつあります。今回は、サイバーレジリエンスを推進する上で重要な検討要素となるSBOMについて解説します。

SBOMとは何か

製造業では、BOM（部品表＋部品構成表：Bill Of Materials）が広く活用されています。BOMは、製品のレシピのようなものと言えばわかりやすいかもしれません。完成品をネジ1本単位まで分解し、それらの依存関係（部品Aは部品B,C,Dから構成される、といった階層構造）を管理します。そのため、BOMは部品発注の最適化や原価計算において必要不可欠な存在になっています。

SBOMは、BOMの頭にソフトウェアを加え、Software Bill Of Materialsの頭文字を取った言葉です。ソフトウェア製品に含まれるすべての「コンポーネント」情報をリスト化したものを指し、ソフトウェアの開発と運用を効率化する目的で使います。

中でも、多くのコンポーネントを組み込んで使用するOSS（Open Source Software）プロジェクトにおいて、SBOMは極めて価値の高い存在になります。SBOMは、プロジェクトで使用するすべてのコンポーネントを管理するため、各コンポーネント単位でセキュリティ情報を照会することができるほか、ライセンス条件の把握にも活用できるのです。

プロジェクトに外注業者が加わり、ソフトウェア・サプライチェーンを構成していたとしても、SBOMがきちんとしていれば、脆弱性がブラックボックス化されてしまうリスクはありません。コンポーネントのバージョンやライセンス情報、提供元などの情報を管理し、コンポーネント間の依存関係も記述できます。そのため、新たな脆弱性情報に接した際も、影響範囲をスムーズに特定し、迅速かつピンポイントに対策することができます。

優れたSBOMを得るために

製造業のBOMは、部品という目に見えるものがあるため、だれもが認める最小単位が存在します。一方、SBOMは直感的につかみにくいソフトウェアをコンポーネント単位でリスト化するため、自前で作ろうとすると運用スタイルに合わせて粒度を設定する必要があります。たとえば、粒度を大きくして外注業者が納品してくれたモジュールを1つのコンポーネントとして扱うことに決めてしまうと、そのモジュールに組み込まれたコンポーネントや参照先のコンポーネント、もしくは参照先のさらなる参照先のコンポーネントを把握できません。一方、粒度が細かすぎると管理に手間がかかりすぎて現実的でないという問題が発生します。

こうした「決まり事」をどうするかを検討する際に、プロジェクトでゼロから考えるとなると膨大な時間とコストがかかります。そこで、標準化されたフォーマットを活用することが効果的です。市場には数々のフォーマットがありますが、主要なものを3つご紹介します。

1. SPDX（Software Package Data Exchange）

Linux Foundation傘下のSPDXプロジェクトが標準化したフォーマットです。ISO/IEC 5962:2021として国際標準化されており、ライセンス管理とコンプライアンスに強いことが特徴です。

2. CycloneDX

OSSコミュニティのOWASP（Open Worldwide Application Security Project）のワーキンググループであるCycloneDX Core Working Groupが推進しています。ソフトウェア開発とセキュリティ向けの用途で広く活用されています。

3. SWID Tag

コンポーネントにタグを埋め込むことで、ライセンスや修正モジュールの管理をできるようにする仕組みで、米国立標準技術研究所（NIST：National Institute of Standards and Technology）が開発しています。ライセンス情報や提供元情報を収集できないため、完全にSBOMの要件を充たすとは言えないものの、SBOMライクに運用することができます。

また、SBOMは、OSSのためだけにあるのではありません。かつて自社開発し、いまも一部が生き残っている古いシステムや、プロプライエタリなソフトウェアも対象なのです。実際に、現在多くの企業では、OSSとプロプライエタリなシステムをどちらも運用していますし、旧来のシステム改修・更新においてOSSを組み込むこともあります。こうした混在環境において、セキュリティを高めるために、SBOMは大きく貢献してくれます。

SBOMの標準フォーマットも進化を続けています。SPDXを例に挙げると、最新バージョンは2.2ですが、2023年にプレビュー版の「SPDX3.0 Release Candidate」が発表されました。将来はコンテナやSaaSも標準化対象に組み込まれる見込みで、いまからすべてのソフトウェア資産をSBOM化するという計画を立てておくのが理想です。

SBOMがサイバーレジリエンスを加速する

サイバーレジリエンスとは、サイバー攻撃を受けても業務を継続できるような運用体制を実現することです。SBOMはサイバーレジリエンスの推進を強力に支援してくれるドライバーとして機能します。稼働するソフトウェアをコンポーネント単位で管理できるため、脆弱性が発見されてからの対処を迅速に実行できます。ソフトウェア・サプライチェーン全体を通して、同じ粒度でコンポーネントを管理できるため、大規模なソフトウェア開発においてもセキュリティの漏れ・抜けが発生するリスクを極小化できる点も大きなメリットになります。

最後に、SBOMは常に更新し続ける必要があることに注意してください。新たな脆弱性は日々発見され、そのたびに修正モジュールを適用するとコンポーネントのバージョンは変わります。現在使用しているバージョンをSBOMに正しく記録することで、発見された脅威の影響範囲を正確に特定することにつながります。また、SBOMに最新のライセンス情報を正確に記録し続けることで、コンプライアンス状況を最適化することもできます。SBOM全体で、バージョンやライセンス状況の異なるコンポーネントがあるかどうかを定期的に監査することも求められるでしょう。