Open Source Summit Japan 2023から、組込系システムにおけるサプライチェーンに関するセッションを紹介

Open Source Summit Japan 2023から、The Linux Foundationにおける組込系システムのVPが解説するサプライチェーンをセキュアにするための仕組みと新しいツールに関するセッションを紹介する。プレゼンテーションを行ったのはKate Stewart氏だ。動画は以下から参照して欲しい。

●動画：Building Dependable Systems with Open Source

プレゼンテーションを行うKate Stewart氏

Stewart氏はまずクルマを例に挙げて、多くのハードウェアコンポーネント、ソフトウェアが連係してモダンなクルマが構成されていること、GPSセンサーなどによるナビゲーションなどの機能が利用できることが必要だと語った。

しかし最先端を行っているクルマにおける障害、特にTeslaによるさまざまなトラブルのニュースを示しながら、機能が豊富にあるからと言って安全性が高められるわけではないことを説明した。

Teslaのトラブルを示しながら安全性が必ずしも高くなっていないことを説明

その上でこれまでエグゼクティブオーダーなどで注目を集められるようになったSBOM（Software Bill of Materials）に言及。ソフトウェアだけに限定せずにシステムの安全性に関わるすべてのコンポーネント、データセットなどについてもその構成要素と依存関係を明らかするべきだとして、SBOMはSystem BOMになるべきだと強調した。

安全のためにはソフトウェアのBOMからシステム全体を網羅するBOMに移行が必要

ただしその際にベンダーごと、業界ごとの独自のデータフォーマットが乱立するべきではないとして、標準フォーマットでメタデータが提供される必要があると主張し、そこからSBOMのフォーマットであるSPDXにトピックを移した。

ソフトウェア、ハードウェア、データ、サービスで標準化されたメタデータが必要

SPDXはLFがホスティングするSBOMフォーマットの一種で、同様のフォーマットとしてOWASPが推進するCycloneDXが存在する。LFとしてはSPDXが主流のフォーマットとして業界標準となることを望んでいると思われるが、素性の良さや機能の多さではなく最終的に多くのサポーター、ユーザーを集めた側が勝つというこれまでのIT業界の常識が適用されることになるだろう。すでにSPDXはバージョン3.1まで開発が進んでおり、Stewart氏が冒頭で説明したソフトウェアだけではなくハードウェアやサービス、データセットまで含めたBOMを生成できるようになることが示されている。

SPDXの進化を説明

そして本来のソフトウェアにおけるBOM、SBOMについてはライフサイクルのすべてのプロセスでBOMが必要だと説明した。単にソースコードのビルドだけでインストールやデザインの段階でもBOMを生成できるようになることで、ライフサイクルのすべてを網羅するBOMとなるという意味だろう。

ソフトウェアライフサイクルのすべてのプロセスでBOMを生成することが必要

具体的にソフトウェアの仕様からコーディング、実装、テストなどのプロセスにおいて相互の関係を示しながら、どのような生成物が発生するのかを図で示しながら説明。

ソフトウェア開発のプロセスで何が何を生成するのか？ を図で示して説明

ここではソースコードをビルドしてテストするという主なプロセスの解説ではなく、コーディングのガイドラインからコードレビューのスクリプトが生成され実行形式モジュールであるアーティファクトとテストレポートが生成されるという成果物の依存関係を整理するフローチャートを使っているところに注目したい。CI/CDが自動化されていることが前提だが、それ以上に派生するすべての生成物を管理することでプロセスにおける成分（Ingredients）が明らかになるべきだというのがStewart氏の主張だ。

ソースコードのビルドからテストまでの依存関係を整理したチャート

またバグ修正などのプロセスにおいても、それぞれのバージョンのソフトウェアから生成されるテストレポートを元にどのバージョンでバグが修正されたのかをトレースできるように「Code to Test」だけではなく「Code to Test to Evidence」という発想でシステム化される必要があることを説明した。

Code to TestからCode to Test to Evidenceに

そしてLFが推進するこれの実装形としてELISA、Zephyr、Xenに応用したYoctoプロジェクトを紹介した。

LFのプロジェクトに応用された例を紹介

ELISAはLinuxのバリエーション、ZephyrはリアルタイムOS、そしてXenはハイパーバイザーだが、Yoctoはカスタマイズされた組込用Linuxを作るためのツールキットである。

そして新たなツールとして紹介されたのがBASILだ。ELISAプロジェクトのブログ記事として公開されているので参照して欲しい。

●参考：BASIL: the FuSa Spice

新しいツールBASILの紹介

BASILはRed Hatで開発されオープンソースとして公開されたツールで、ソフトウェアの仕様やドキュメントなどから仕様の分析、その仕様に合致したテストが実行されているのかなどをWebのユーザーインターフェースからチェックするツールであるという。ソフトウェアを開発したRed HatのQAエンジニアで、上記のブログの著者でもあるLuigi Pellecchiaによる動画も公開されている。

●動画：Introducing Basil

動画のデモを見る限り、ソースコードとコメントを分離し、その中身とマニュアル（man page）、テストコードを比較する方法で求められた仕様が実際のコードやコメントと合致しているのか、テストコードはその仕様のテストを満たしているのか、などをチェックするツールのようだ。セッションの中では深い説明は省いているが、安全性を高めるために仕様書が書かれていてもそれが実際に実装されていなければ意味がないし、その仕様を確認するテストが実行されていなければ意味がない、その部分に注目して作成されたツールということになる。

最後にSPDXや今回紹介されたELISA、Zephyr、Xen、Yoctoなどへの参加を促してセッションを終えた。

各プロジェクトへの参加を呼び掛けてセッション終了

安全性を高めることは組込系では特に重要であることを冒頭のTeslaのトラブルで喚起してから、SBOMの重要性、そしてLFが手がけるさまざまなプロジェクトを駆け足で紹介した。日本の自動車メーカーによるテストの偽装が2023年に大きな問題となったが、その製造過程に今回のプロセスをまじめに適用したら不正は防ぐことができたのだろうか？ ソフトウェアだけではなく製造業を含むすべての業界においても意識を高める必要があることを感じさせたセッションとなった。