米国では既に標準化の流れ、日本企業も対応を迫られる「SBOM」とは：OSSのサプライチェーン管理、取るべきアクションとは（3）

「SBOM」が大きな注目を浴びている。そもそもSBOMとは何なのだろうか。なぜ米国は大統領令でこれを取り上げたのか。日本企業は対応する必要があるのか。どう対応すればいいか。ここでは、OSSのサプライチェーン管理に関する連載の3回目として、SBOMを解説する。

[渡邊歩，OpenChain Japan Work Group] PC用表示関連情報

LINE

Hatena

　DX（デジタルトランスフォーメーション）やIoT（Internet of Things）の進展により、ますますその存在感が増しているオープンソースソフトウェア（OSS）。ソフトウェアの高機能化、大規模化によるサプライチェーンの複雑化を背景に、SBOM（Software Bill of Materials）によるOSSサプライチェーンマネジメントに注目が集まっています。米国では既に必須化・標準化の動きが始まっており、日本企業も対応を迫られるようになってきました。本記事では、あらためてSBOMとは何か、そして日本におけるSBOM活用の普及促進にはどういった課題があるかについて、詳しく解説します。

SBOMとはいったい、どのようなものなのか

　Software Bill of Materials（SBOM、「エスボム」と読みます））とは、ソフトウェアを構成するOSSや商用ソフトウェアなどのライブラリやモジュールの情報を構成情報として記したもの、いわゆるソフトウェア構成表です。ソフトウェアサプライチェーンにおける「トランスペアレンシー（透明性）」と「トレーサビリティ（追跡可能性）」の確保に有効な手段として、世界的に普及が進んでいます。

　SBOMの具体的なイメージを下記に示します（内容理解のため、項目や記載内容を簡略化してあります）。

SBOMのイメージ（出典：「Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)」 Table2）

ソフトウェアサプライチェーンにおけるトランスペアレンシー（透明性）の重要性

　2021年12月に発見された、OSSのロギングライブラリApache Log4jの脆弱（ぜいじゃく）性であるLog4Shell（CVE-2021-44228）は、悪意のある第三者が任意のコードをリモート実行できてしまうというものです。これはCVSS（Common Vulnerability Scoring System：共通脆弱性評価システム）でスコア10に指定された、極めて深刻度の高い脆弱性です。

　Log4jは汎用（はんよう）性が高く、さまざまな業界の製品やサービスで広く活用されているため、多くの企業が影響を受ける可能性があり、各社が対応に追われたことで注目を集めました。こうしたニュースを耳にしたエンドユーザーが真っ先に考えるのは、「うちのシステムはこの脆弱性の影響を受けるかどうか」ということです。特にITサービス関連業界においては、脆弱性の発見から24時間以内に初期対応を実施しなければならないなど、早急な対応が求められることがあるので、対応は急務となります（脆弱性の深刻度による）。

　エンドユーザーが当該システムの構成を全てきちんと把握しているのであれば話は簡単ですが、そうではないケースでは、当然、そのシステムを提供したベンダーに問い合わせることになるでしょう。問い合わせを受けたベンダーはサプライヤー（場合によっては複数のサプライヤー）に問い合わせ、そのサプライヤーは開発を委託したソフト開発会社に問い合わせ……というように、サプライチェーンの上流へと問い合わせが次々に転送されていきます。

　このように問い合わせが多段にわたる場合、回答を待っている間にサイバー攻撃を受けてしまうこともあるでしょう。脆弱性対応のような一刻を争うような事態においては、すぐに対策がとれるよう、そのソフトウェアがどのような構成であるかが漏れなく分かること（＝トランスペアレンシー）が非常に重要になります（ソフトウェア・トランスペアレンシーの議論のきっかけとなったセキュリティ事件の詳細はこちらをご参照ください）。

　また、上記の例のような、脆弱性対応への時間的要求が厳しいITサービス関連業界以外であっても、例えば自動車向け車載機器における国際規格ISO/SAE 21434やUN-R155/UN-R156、それらに対応する国内法規制などに向け、平時から脆弱性問題への対応が求められる状況が広がっています。

ソフトウェアサプライチェーンにおけるトレーサビリティ（追跡可能性）の重要性

　上記の例の続きとして、サプライチェーンに所属する各社では、実際にその脆弱性が顕在化するかどうかの検証が行われます。例として、下記のような観点での検証が必要であり、なかなか大変なタスクであると言えるでしょう。

当該OSSを使っているか（脆弱性のあるバージョンかどうか）
どこで、どのように使っているか（モジュール間の依存関係や内包関係）
悪用され、攻撃される可能性があるかどうか
対策する必要があるかどうか、対策可能かどうか
パッチを適用する場合、既存機能に影響があるか
バージョンアップする場合、依存関係に影響はないか（他のモジュールも合わせてアップデートする必要がないか）

　各構成要素がどこから来て、どこで、どのように使われているかを正確に把握すること（＝トレーサビリティ）ができていれば、これらの調査の負荷は軽減でき、どのような対応をすれば良いかがすぐに判断できるでしょう。同じソフトウェアが別のサプライチェーンでも流通しているかどうかなど、範囲を広げて調査することも容易です。

各企業においてSBOMを作成し、管理する必要がある理由

　上記の例のように、あるOSSに脆弱性が発見された場合、それが自身の提供する製品やサービスに影響を及ぼすか否かを把握し、必要な対策を講じる必要があります。迅速で確実な脆弱性対応を実施するためには、製品やサービスのどこで、どのようなOSSが活用されているかを正確に追跡できなければなりません。また、製品やソフトウェアでOSSを活用している場合、最終頒布者は各OSSのライセンスが要求する責務を確実に履行する必要があります。そのためには、複雑なサプライチェーンから提供された全てのOSSを漏れなく把握しなくてはなりません。

　サプライチェーンのどこかで作りこまれた不具合や脆弱性、仕込まれたマルウェア、ライセンス情報の不足等がある場合、その影響はサプライチェーンの下流に対して広い範囲で影響を及ぼすことになります。このため、製品やサービスの最終頒布者は、インシデント発生時に備えて、自身の製品やサービスを構成するソフトウェアがどのようなコンポーネントで構成され、それらがどこから来たものであるかを把握しておかなければなりません。この情報の把握のために使われるのがSBOMです。各企業は、自身が頒布するソフトウェアに対応するSBOMを作成し、必要な場合にすぐ参照または提供し、リスクのクリアランスに活用できるように準備しておくことが求められます。

サプライチェーン内で求められるSBOMフォーマットの標準化

　各企業でSBOMを作成し、それがソフトウェアと共にサプライチェーン内を流通するようになると、次に考えるべきことはSBOMの作成や管理の自動化です。各社がばらばらの書式で作成したSBOMを受け取って管理したり、取引先ごとに異なる指定フォーマットでSBOMを作成したりする場合の人的コストは、かなりのものになるでしょう。このため、管理や生成の効率化を目的として、フォーマットの標準化の議論が行われています。現在では、Software Package Data Exchange（SPDX）、CycloneDXなどが主要なフォーマットとして採用されています。

　業種・業態により必要な情報が異なるため、全世界で統一的な規格が誕生することは考えにくいですが、今後、自動車、医療、ソフトウェア業界などで、それぞれ業界標準の規格を定める可能性が高いと思われます。このため、各企業においては、どのようなフォーマットのSBOMでも提供できるように、SBOMデータの蓄積方法を工夫しておくと良いでしょう。

　また、SPDX やCycloneDXなどの主要なフォーマットに関しても、記載すべき必須項目、記載できる追加項目、フォーマット間の相互運用性、ファイルを生成する手法などを含めた議論が継続的に行われており、規格自体の更新が行われる可能性が高いことへの注意も必要です。

米国大統領令によるトップダウン的アプローチ

　2021年5月12日に発令された、米国連邦政府機関におけるサイバーセキュリティ改善に係る大統領令（EO #14028）において、連邦政府の情報システムに求められるサイバーセキュリティ対策の基準と要件が定められました。この中で、システムを構成するソフトウェアの部品表、すなわちSBOMの作成と提供を求め、それを元に脆弱性のチェックと修復を行うべし、ということが明確に記載されています。また、この大統領令を受けて、同年7月にSBOMの最小構成を定めたドキュメントを公表するなど、米国は国家的な施策としてSBOMの普及促進に取り組んでいることが分かります。米国の大企業も続々とSBOM関連の活動を公表しています。

　日本においては、経済産業省が、このような米国の動向を踏まえつつ、SBOM作成の実証実験を通じて効果の検証や課題の検討などを進めています。

日本企業のオープンソース的アプローチから生まれたSPDX Lite

　日本企業の有志による、SBOMの普及促進に貢献しようという活動を紹介します。

　前述のSBOMフォーマットの一つであるSPDXは、非常に優秀な仕様ではありますが、多岐にわたる情報を取り扱うように設計されているため、作成するのが難しく、導入しにくいというデメリットがあります。

　これに対して、必要最小限の必須情報を記述するためのフォーマットとして「SPDX Lite」というサブセットが用意されています。SPDX Liteは、手書きやスプレッドシートでも作成が可能です。

　企業規模やOSSに関する習熟度を問わず、広く持続的に活用してもらうために定義されたこのSBOMフォーマットは、The Linux Foundation傘下のOpenChainというコミュニティーの活動の一つとして、日本企業によるチームが提案し、採用されたものです。「SPDXは無理だけど、SPDX Liteならなんとか対応できる」という企業も多く、広く活用されています。

それでもSBOMの普及が進まない現状がある

　これまで述べてきたように、SBOMはソフトウェアサプライチェーンマネジメントにおいて非常に有効な施策であるにもかかわらず、日本ではまだ普及しているとは言い難い状況です。SBOMの普及促進における主な課題について、私は以下のように考えています。

SBOMの作成に関する課題

SBOMにどのような情報を含めるべきかが分からない
SBOM作成に関する新たなコストが発生する
ソフトウェアIDやSBOMの形式が統一されていないなど、自動化の障害が存在する

SBOMの提供に関する課題

顧客にとってのメリットが不明、SBOM受領者から合理性のない対応を求められる懸念がある
ソフトウェア開発契約書面のような、更新頻度に課題がある正本が別に存在し、SBOMとそれ以外の文書との整合性が取れない
他社にソフトウェアの構成要素を知られたくない
知的財産の流出の懸念がある

SBOMの活用に関する課題

SBOMに記載されている情報をどのように活用できるか分からない
記載されているコンポーネントの名称やIDが共通ではなく、管理しにくい
対象に合わせて自動化された管理方法が必要である

　例えば、「SBOM作成に要する新たなコストを誰が負担するのか」という課題については、企業間の受発注契約における取り決めの標準化が必要でしょう。また、コミュニティーから共有される、低コストで効率よくSBOMを作成できるようなツールやベストプラクティスも有効でしょう。このように、一つ一つの課題に対して業界全体でアイデアを出し合い、議論しながら解決していくことが重要になります。

　次回の座談会では、「日本企業におけるSBOM活用の普及促進」をテーマに、各企業の取り組みやコミュニティーとして貢献できることなどを議論したいと思います。

l特集：OSSのサプライチェーン管理、取るべきアクションとは

オープンソースソフトウェア（OSS）の利用が多くの企業で本格化し、ライセンスやセキュリティ、品質などのリスクが表面化しようとしている。「OSS＝フリーソフトウェア」という認識ではこの状況に追いつくことができない。しかもOSS利用は企業内の異なる事業部、グループ内企業、開発パートナーなどに広がっている。企業はこれをサプライチェーンとしてとらえ、リスクを適切に管理していく必要がある。では、どう行動すべきか。本特集では、OSSの推進とマネジメントを行う社内組織「OSPO（Open Source Program Office）」、およびソフトウェア構成表「SBOM（Software Bill of Materials）」に焦点を当て、これらの現実の姿を解説および座談会で解き明かす。

特集：OSSのサプライチェーン管理、取るべきアクションとは