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

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

[渡邊歩，OpenChain Japan Work Group]

　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、それらに対応する国内法規制などに向け、平時から脆弱性問題への対応が求められる状況が広がっています。