KubeCon/CloudNativeCon NA 2021から、Kubernetesのリリースチームが実践しているSoftware Bill of Materials（SBOM）に関するセッションを紹介する。これはSIG ReleaseのテクニカルリードであるAdolfo Garcia Veytia氏によるセッションで、Kubernetesをマイナーバージョンごとにリリースする仕事を受け持つグループにおいて、SBOMがどのように生成されているのかをデモを交えて解説し、将来の計画などについても触れたセッションである。
「我々はK8sのSBOMを実装した。次はあなたの番だ」という意味のタイトル
動画：We Built the Kubernetes SBOM and Now You Can Write Your Own!
このセッションは「We Built the Kubernetes SBOM and Now You Can Write Your Own!」と題されているように、Kubernetesのリリースチームが先行してSBOMを導入した経緯を解説している。そしてクラウドネイティブなシステムの中核と言っても良いKubernetesがどのようにビルドされ、リリースされているのかの一部分を垣間見られる内容となっている。このセッションが特徴的なのは、KubernetesをビルドするエンジニアにとってSBOMはビルドプロセスを改善するためのツールであり、CNCFがホストするIn-totoやSigstoreなどのプロジェクトのユーザーという立場からの視点に立っていることだろう。つまり他のソフトウェア開発プロジェクトにとってみれば先行事例という形で、CNCFの他のプロジェクトも追従して欲しいということを明確に語っていることだ。
実際にKubernetesのビルド及びリリースエンジニアリングでは多くの改善が行われており、別のセッションではこれまでBashのスクリプトで実装されていたリリースツールanagoの使用を止め、krelというGoで書かれたツールに移行したこと、Googleが開発しているオープンソースのビルドツールBazelの使用を止めたことなどが解説されている。Bazelを止めたのは、不具合などの対応のためにどうしてもGoogleのエンジニアの協力が必要になることがGoogleへの依存となるので、それを避けたいという意図があったことなどが解説されている。興味があれば、そのセッション、「Hardening the Kubernetes Software Supply Chain Through Better Transparency」を参照されたい。このセッションでもVeytia氏が共同プレゼンターとして講演を行っている。
anagoがビルドプロセスから完全に排除されたことを知らせるPRの一部
動画：Hardening the Kubernetes Software Supp…
本題に戻ろう。今回紹介するセッションのプレゼンターであるAdolfo Garcia Veytia氏はMattermostのDevOpsエンジニアでリリースチームの中核のエンジニアであり、SBOMについてもチームをリードする役割を担っているという。
Adolfo Garcia Veytia氏の自己紹介。自転車好きらしい
Veytia氏はSIG-Releaseの役割を簡単に紹介し、OSの違いやプロセッサーのアーキテクチャーごとに生成されるリリースのプロセスを実行するだけではなく、その改善も含まれることを解説し、具体的にKubernetesのリリースの内容を紹介した。
Kubernetesのリリースに含まれる内容物を紹介
特にSIGのミッションとして「リリースの自動化のためのツールとガイドを作成すること」を挙げ、リリースのためのツールがいくつも存在することを紹介した。
リリースプロセスで使用されるツールの一部
この中から、今回デモでも紹介される「bom」というコマンドラインのツールを紹介した。これはディレクトリーやGitリポジトリーに存在するソースコードなどをベースに、Software Package Data Exchange（SPDX）に準拠したSBOMを生成するツールである。ちなみにSPDXはThe Linux Foundationがホストするオープンソースプロジェクトだが、2021年9月にISOの標準として採用された。
参考：SPDX Specification is now an ISO Standard
その上でSBOMについて「ソフトウェアリリースにおけるコンポーネントの関係性を明確に示したもの」であると解説した。そして喩えとして野菜を販売する商店を挙げ、それぞれの作物はそのままではなく料理に適した形態で販売されるべきであるとして、単にリストにするだけではなくその関係性を開示することが重要だと解説した。
SBOMの紹介
野菜を売っている商店を例に成果物に適した形で内容を提供するのがSBOMであると解説
そして単にリスト化するだけでは十分でないことの例として、ソースコードの他にバイナリイメージ、コンテナーイメージ、パッケージなどによってリストがわかりづらくなっていることを解説した。
単にリスト化しただけでは、かえってわかりづらくなってしまう例を紹介
「SBOMはその内容物に適した方法で表現するべき」というのが戦略であると語り、ここから単なるリストではない部分の解説を始めた。
SBOMの戦略を紹介
ここではユーザーの立場というよりもSBOM自体の解説に近い内容となっており、ユーザーである反面、同じようにソフトウェアやスペックを開発するエンジニアとしての気持ちが現れていることを感じさせる場面となった。
そして具体的にSBOMの特徴として「関係性を明らかにする」という部分の説明を行った。
SBOMで定義する関係性とパッケージとは
前のスライド説明されたように単なるリスト、羅列ではなく、ソフトウェア開発に使われるそれぞれの要素をその特性にあった記述で定義し、その関係性（例えばそのバイナリイメージがどのソースコードから作られたのかという親子関係）を記述することが必要であると解説した。
関係性を明確に定義するSBOM
ここで、実際にSBOMを生成するツールであるbomの実行例を紹介した。ここではGitのリポジトリーからSBOMを生成する例と、既存のSBOMに対して新たに要素を追加する例を紹介している。
bomの実行例を紹介
またCI/CDの中で使われるyamlファイルをベースにSBOMを生成する例も紹介し、すでにCI/CDのパイプラインが出来上がっているのであれば、その中にSBOM生成というプロセスを挿入するのは難しくないことを解説した。
yamlファイルからSBOMを生成
ここからはデモタイムとして、ローカルのディレクトリーからSBOMを生成する例を実際に行って見せた。ソースコードやライブラリーだけではなく、そのソースコードに記述されているライセンスの種類なども要素として処理されることなどから、単に部品表という位置付けではなくコンプライアンスの面からもSBOMの有用性が示されている。
SBOMを作る部分をデモとして実行
最後に今後の予定としてrpm/debパッケージのサポート、Java、Python、Go以外の言語のサポートなどを挙げてセッションを終えた。Q＆Aの際に他のプロジェクトにもSBOMの利用を薦めるのか？ という質問に対しては「そうするつもりだが、最終的な決断はコミュニティにある」と回答して、あくまでもコミュニティの意思を尊重することを語っている部分に、コミュニティを重視する姿勢が現れていた。
またキーノートでも触れられていたが、SBOMの実装例としてはLFが支援するSPDX以外にもOWASP（Open Web Application Security Project）が支援するCycloneDXや商用のソフトウェアも多数存在する。多数の実装例がこれからしのぎを削るという状態だが、LFの強力なバックアップとCNCFの中核であるKubernetesが使っているという実績から、CNCFのエコシステムの中ではSPDXが一歩抜け出ているという状況だ。今後もSPDX、SBOMの動向に注目したい。