概要
Open Compliance Summit 2022 が 12 月 7～8 日に開催されました。 私もスピーカーとして参加してきましたので、その発表の概要を紹介させていただきます。
The Open Compliance Summit 2022 was held on December 7-8. Since I participated as a speaker, I would like to introduce the summary of the presentation.
なおスライドはイベントのスケジュール ページにアップロードしてありますので、必要でしたらそちらからダウンロードしてください。
https://sched.co/1CwXb
大まかな内容は、SBOMの概要やSPDXの紹介、またYoctoでのSPDXの生成や脆弱性の検出、それらを管理するためツールとしてSW360を使ってみたので、その構成や使い方の紹介になります。
ソフトウェアのライフサイクルにおけるSBOM
SBOMはSoftware Bill Of Materialsの略で、"ソフトウェア部品表"と訳されます。
最近の組込みシステム開発では大規模なものであれば複数のサプライヤーが関わり、それぞれのサプライヤーが独自にOSSを取り込んで開発することが一般的です。製品開発を行うベンダーはサプライヤー各社が取りこんだ大量のOSSを、ライセンスに準拠するためだったり脆弱性を監視するために適切に管理する必要があります。SBOMはこうしたソフトウェア パッケージが上流 (サプライヤー) から下流 (製品ベンダー/ユーザーなど)へと受け渡される際に、そのパッケージがどのようなソフトウェアで構成されているのかを示す説明書として機能します。
その際、各社がバラバラなフォーマットでSBOM提供していると、受け取る側ではその読み取りや管理する作業が煩雑になるだけでなく、情報の不備により「肝心なライセンス情報が抜けているじゃないか」といったようなことが生じる可能性もあります。そのために、SBOMは標準的なものを使用すべきです。
SPDX (Software Package Data Exchange) はLinux Foundationによって仕様化され、2021年にISO標準化されました。共通のフォーマットといってもSPDXではタグ/バリューやJSONなど複数のフォーマットで記載が可能です。SPDXではパッケージ名・バージョン、パッケージのベンダー情報 (ホームページなど)、ライセンスといった情報や、ビルド時の依存関係、ランタイムでの依存関係などを表現できます。
SPDXは元々、ライセンスの扱いを中心としたOSSを扱う上でのコンプライアンス遵守のために発展してきたものだと筆者は認識しているのですが、たとえばパッケージ名・バージョン、ベンダー情報といったものは、そのパッケージの機能を把握するのに使えるので筆者のようなソフトウェア技術者にも役立ちますし、それらの情報はそのパッケージのセキュリティ監視をする際に必要になります。
特にセキュリティに関して、SBOMとともに脆弱性を管理することは重要です。米国の「国家のサイバーセキュリティ改善に関する大統領令 Executive Order on Improving the Nation's Cybersecurity」においてSBOMを用いたソフトウェア パッケージの透明性の確保とセキュリティ強化が求められたことで話題になりましたが、自分たちが使っているソフトウェアの中に、いったいどんなコンポーネントが含まれているのか？ を知ることは、そのソフトウェアの脆弱性を知り脅威を回避するために必要となります。SBOMはそういったことを知るためにも役立ちます。
SBOMは基本的に、"ここに含まれているソフトウェア部品は何か?"を示す情報のため、特に組込みシステムにおいてはビルド時にほぼ全ての情報が固定化されるものです(※実行時に依存するライブラリをダウンロードしたり、それこそ近年発展が著しいAIによってコードを自動生成するような仕組みが一般化されれば話は別ですが？) 。
しかし、脆弱性は日々発見されるもののため、固定的なSBOMとともに、動的に変化する脆弱性を適切に管理することが重要です。
また、これらSBOMや脆弱性に関する情報は、ソフトウェアのライフサイクルにかかわる登場人物 (開発者やセキュリティ担当者、法務担当やユーザー) のうち、必要な人が必要なときにアクセスできるように管理する必要があると思います。そのためには、SBOMを適切に管理できるツールのサポートが重要になります。
Yoctoで生成できるSPDXと脆弱性情報の紹介
Yoctoは組込みシステム向けのビルド ツールで、使用するOSSのダウンロード、独自パッチの適用、ビルド、RPMやDEBパッケージ化やブート イメージの生成などをワンストップで実行可能なツールです。YoctoにはSPDXの出力や、脆弱性検出の機能もオプショナルで含まれているので、それを紹介します。
YoctoでのSPDXの出力
YoctoでSPDXを出力する方法は主に2種類あります。
meta-spdxscanner
meta-spdxscannerは、富士通でメンテナンスしているSPDX出力のため仕組みです。
これは単独で動作させることはできないのですが、FossologyやScaCode Toolkitといったライセンス スキャナーと連携することで、ライセンスをクリアにしたうえでSPDXを出力します。ライセンス スキャナーを別途用意する必要はあるのですが、使用しているソフトウェア パッケージをよりクリアにするうえで役立ちます。
create-spdx
create-spdxはライセンス スキャナーを必要とはせず、設定ファイルに1行加えるだけでよいなど、非常に手軽に利用できます。
ただし、create-spdxで出力される情報はあくまでレシピ (Yoctoでビルドする上で必要なメタ情報を書き込んだファイル) を元にしているため、そのレシピ自体の正しさを保証しない限りは出力されるSPDXの正しさも保証されません。
Yoctoでの脆弱性情報の出力
Yocotoには'cve-check'という仕組みが標準で用意されています。これはNVDで公開されている情報をダウンロードし、Yoctoでビルドしたパッケージに該当するものをピックアップして出力する、といった仕組みになっています。脆弱性がパッケージに該当するか否かを判断するのはNVDの脆弱性レコードに含まれるcpeのパッケージ名やバージョンを元にしていますが、例えばその脆弱性 (CVE) に対するパッチがレシピの中に含まれている場合や、レシピに"この脆弱性は無視する"と記載されている (ignore listに記載されている)場合には、脆弱性が非該当であることを示すステータスを表示する仕組みになっています。
SW360を使用したSBOMと脆弱性情報の管理
SW360 はソフトウェア コンポーネント管理をするためのツールです。
ライセンスなどのソフトウェア パッケージにまつわるメタ情報管理や、輸出管理のための機能があります。
(この発表をした前日のOSSJにて、SW360のSPDX対応や脆弱性管理の機能を強化していることがアナウンスされていましたが、私がPoCで使ったのはそれらの機能が含まれていないものです)
PoCの内容としては、Yoctoで出力したSPDXのインポート、脆弱性 (cve) のインポートの方法です。
SPDXや脆弱性情報は、それ自体をインポートする機能があるわけではなく、REST-APIを利用してそれらのファイルのフィールドをSW360で管理できるフィールドに置き換える手法を紹介しました。
SPDX・cveとSW360の仕様の双方を理解する必要があるため実装するのに労力はかかるのですが、Web-UIによる人の目での閲覧性の良さであったり、REST-APIを利用することでCI/CD環境において自動化できるなどのツールの支援は重要で、DevSecOpsのサイクルを高速で回す・その情報を必要とする人が必要な時にアクセスできるようにする、といった要件を満たすためにはある程度イニシャルコストをかける必要があるのだろうなと思います。
終わりに
SPDXは生成ツールは充実してきたように見えますが、サプライ チェーンでの利用を想定した場合に、受け取ったSPDXをどう管理するのか？を支援するようなツール、特にOSSで実装されたツールはまだまだ手薄な気がします。今後もツールの調査は続けていき、実際使ってみた感想等も広くPRできたらいいなと思います。
ちなみに今回が初めてのOpen Compliance Summit参加で、しかもスピーカーとしての参加だったのですが、英語が喋れないくせに英語オンリーなカンファレンスで発表するのは結構骨が折れます。英語勉強しないと。