KuberCon NA 2021、Kubernetesリリースチームが解説するSBOMのセッションを紹介
![](https://thinkit.co.jp/sites/default/files/styles/main_image_730x/public/main_images/19378_main.jpg?itok=yhwz69Uh)
KubeCon/CloudNativeCon NA 2021から、Kubernetesのリリースチームが実践しているSoftware Bill of Materials(SBOM)に関するセッションを紹介する。これはSIG ReleaseのテクニカルリードであるAdolfo Garcia Veytia氏によるセッションで、Kubernetesをマイナーバージョンごとにリリースする仕事を受け持つグループにおいて、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氏が共同プレゼンターとして講演を行っている。
動画:Hardening the Kubernetes Software Supp...
本題に戻ろう。今回紹介するセッションのプレゼンターであるAdolfo Garcia Veytia氏はMattermostのDevOpsエンジニアでリリースチームの中核のエンジニアであり、SBOMについてもチームをリードする役割を担っているという。
Veytia氏はSIG-Releaseの役割を簡単に紹介し、OSの違いやプロセッサーのアーキテクチャーごとに生成されるリリースのプロセスを実行するだけではなく、その改善も含まれることを解説し、具体的に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を生成するツールであるbomの実行例を紹介した。ここではGitのリポジトリーからSBOMを生成する例と、既存のSBOMに対して新たに要素を追加する例を紹介している。
またCI/CDの中で使われるyamlファイルをベースにSBOMを生成する例も紹介し、すでにCI/CDのパイプラインが出来上がっているのであれば、その中に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の動向に注目したい。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- Open Source Summit Japan 2023から、組込系システムにおけるサプライチェーンに関するセッションを紹介
- OpenSSFを拡大・支援するため1,000万ドルの新規投資を調達、「The 2021 Open Source Jobs Report」を公開、ほか
- KuberCon/CloudNativeCon NA 2021開催、3日間のキーノートを紹介
- KubeCon NA 2021、ソフトウェア開発工程のタンパリングを防ぐSLSAを解説
- 米国のバイデン大統領が署名したことで話題となった「国家のサイバーセキュリティ改善に関する大統領令」とは
- Open Source Summit NA 2022の2日目のキーノートからSBOMの事例などを解説
- CNSC 2022、SBoMの概要と未来を展望するセッションを紹介
- OpenSSF Day Japan開催。中国からの脅威から新しいOSSプロジェクトの紹介までを総括
- RHEL互換LinuxのAlmaLinuxがセミナーを開催。サイバートラストのセッションを主に紹介
- Open SSFがOSSのセキュリティ体制を改善する「Alpha-Omega Project」を発表。マイクロソフトとグーグルが主体的に参画、ほか