日本におけるソフトウェアサプライチェーンセキュリティとSBOMの目的：ソフトウェアサプライチェーンの守り方（2）（3/3 ページ）

[松岡 正人，MONOist]

業界ごとに異なるサプライチェーンの構造と商習慣

　これら、医療機器と自動車の業界でソフトウェアサプライチェーンセキュリティに関する取り組みが先行していることもあり、経済産業省の「サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース」は、これらの業界の協力を得てSBOMの導入に関する実証プロジェクトを進めている（関連資料）。これは、2021年度に実施したSBOMの導入運用コストの実証プロジェクト^※3）を受けて、実際のビジネス環境でSBOMの導入の課題と利点を明らかにするためのものである。予定通りに進めば、2023年春には結果が公開されると思われるので期待したい。

※3）SBOMの生成と管理の基本的なコストの捉え方と、SBOMの生成と管理を無償のツール、商用ツール（Black Duck）などで行った場合の工数を含むコストの参考データを提供している。

　果たして、SBOMを利用することでソフトウェアのサプライチェーンセキュリティにおけるリスク管理がどの程度容易になるのか、それとも想定以上の課題があるのか。課題が技術的に解決すべきものであればと思う。

　このように、業界を巻き込んで進めなければならないのはサプライチェーンの構造と商習慣が業界ごとに異なるためだ。

　自動車業界では多くの部品メーカーが提供する3万点もの部品を組み立てて製造される。また、車種によって20〜100個あまり搭載されているとされるECU（電子制御ユニット）はそれぞれ制御用に専用のソフトウェアをOS上で動作させており、それらの構成を含め、内部は自動車メーカーに開示されないことが一般的だ。

　産業用制御システムやプラントなどは、顧客の要望に合わせてPLC、センサー、アクチュエータといったものから、必要に応じてさまざまな装置や機器を統合する。システムの透明性という意味では、機械図面や電気図面、ソフトウェアのソースコードや、PLC上の制御プログラムとセンサーなどのデータを格納するメモリ領域をどのように配置するかなど、詳細な設計情報をシステムと一緒に納品することが多い。これはユーザー側が必要に応じて手を加えることを想定した契約になっていることが多いからだ。センサーの入力が得られない場合、センサーの故障かもしれないが、配線やPLCの入力ポートが分からなければ修理することができないし、必ずしも開発した会社が保守をするわけではない。しかし、PLCやセンサーなど制御用のコンポーネントに組み込み済みのソフトウェアは、自動車のECU同様にブラックボックスでの提供となる。

　医療機器も、体脂肪計付き体重計のように小型の装置であれば部品点数も少なく、ソフトウェアも小規模だ。しかし、スマートフォンやクラウド上のサービスと連携する機能があるような場合、体重計はMQTTプロトコルを使ってAWSやAzureなどクラウド上のデータ可視化サービスと通信することが必要となり、MQTT Xのようなオープンソースのクライアントソフトを採用して、TLSを利用して経路の暗号化を行う。そして、データ可視化のためのアプリケーションをスマートフォン用に開発提供する際にはサードパーティーが開発を請け負う場合もあり、自動車のようにコードの開示などが行われず保守はサードパーティーの責務とすることが多いと思われる。

　これらのどのケースであっても、製品やシステムを構成する「オープンソースソフトウェア」「商用ソフトウェア」「自前のソフトウェア」の全体像は把握できない。しかし、SBOMを利用することで全体像を把握できるようになる。これは、米国商務省電気通信情報局（NTIA）のSBOMによるソフトウェアエコシステムを示したチャートをご覧いただくのがよいと思う^※4）。

※4）米国商務省の下部組織であるNTIAは、SBOMによるソフトウェアサプライチェーンリスク管理の実現を推進してきた。

図3　NTIAによるソフトウェアサプライチェーンのエコシステムのチャート［クリックで拡大］ 出所：NTIA

　自動車、制御システム、医療機器などで例示したように、製品やシステムを構成するコンポーネントにブラックボックスで提供されるソフトウェアが含まれている場合、利用者の多くはそれらのコンポーネントが内包している既知、あるいは新たに発見された脆弱性の情報などを入手できるとは限らない。多くの場合は、最終製品を提供するメーカーが開示するまで分からない。

　しかし、メーカー側も同様で、サードパーティーから購入しているコンポーネントやソフトウェアがどのような構成になっているのか分からないことが容易に想像できると思う。つまり、もし利用している製品に脆弱性のあるコンポーネントが含まれていてもパッチを当てることができるのは、サードパーティーやメーカーが問題を把握してパッチによるその他の機能への影響がないことが確認されるまで待つことになり、対策が遅れることになる。

　2021年末に報告された「Log4j」の脆弱性では、パッチを当てずに運用しているシステムがサイバー攻撃の対象となっており、2022年1月に米国公正取引委員会（FTC）はパッチを当てない企業に対して法的措置を講じると通告した（関連記事：米国では「Log4j」脆弱性の放置に法的措置も　攻撃に引き続き警戒を呼び掛け）。米国サイバーセキュリティ・社会基盤安全保障庁（CISA）は2022年7月にアラートを発行したが、状況が改善しないため、同年11月にあらためてアラートを発行している（関連資料）。CISAなどからLog4jの脆弱性を確認するための無償のツールが公開されているが、SBOMが流通する世の中になればLog4jを含む製品やシステムであることがすぐに確認できるようになる。

　さて、日本でのSBOMの扱いはどのようになっているのだろうか。2022年6月30日、デジタル庁が発行した「DS-200 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」の「8）セキュリティ運用」において、次のようにSBOMの利用がうたわれている。

アプリケーションで使用するライブラリやミドルウェア等に深刻な脆弱性が発見された場合、自システムで該当のライブラリやミドルウェアが該当のものが含まれるかどうかを迅速に判断できるよう、システムで使用するソフトウェアの開発元、バージョン、ライセンス、依存関係などを容易に参照できるような構成管理を行う（SBOM等を利用したソフトウェア構成管理を行うことも有用）。

　当然のことながら、セキュリティテストについては同ガイドラインの「6）セキュリティテスト」に記載がある。つまり、2021年に発令されたEO14028で述べられている「自動化セキュリティテストによる不具合の低減」と「SBOMを利用したサプライチェーンリスク管理」と同様な指針をおおまかにではあるが示しているのである。

図4　デジタル庁による「DS-200 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」［クリックで拡大］ 出所：デジタル庁

筆者プロフィール

松岡 正人（まつおか まさと）

新潟県立長岡工業高校電気科卒。組み込み含む元ソフトウェア開発者。主に制御システムや組み込みソフトウェア開発を中心に昔ながらのベタな開発現場を経験した後、外資系で組み込み開発、サイバーセキュリティビジネスに携わる。JNSA IoTセキュリティWGリーダー、セキュリティ・キャンプ2022講師、サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース メンバーを務める。

日本シノプシス合同会社https://www.synopsys.com/ja-jp.html