KubeCon Japan 2025、SBOMの課題を解説するSBOMitのセッションを紹介

連載 [第6回] :

KubeCon＋CloudNativeCon Japan 2025レポート

2025年10月23日(木)

KubeCon＋CloudNativeCon Japan 2025にて発表された、SBOMの課題を解説したSBOMitのセッションを紹介する。

KubeCon＋CloudNativeCon Japan 2025の2日目、最後の枠で行われたSBOMitのセッションを紹介する。プレゼンテーションを行ったのはNew York University（NYU）の教授Justin Cappos氏と、教え子であるYuchen Zhang氏だ。Cappos氏はNYUのComputer Science＆Engineering学部の教授であるが、TUF（The Update Framework）やin-totoなどのCNCFのプロジェクトのリーダー／コントリビュータとしても知られている。こちらのほうがクラウドネイティブなシステムに関わっているエンジニアにとっては意味が大きいだろう。

Cappos氏は2024年秋にソルトレークシティーで開催されたKubeCon North America 2024のキーノートにも登壇しているので、お馴染みのプレゼンターと言える。

●参考：KubeCon North America 2024から、ソフトウェアサプライチェインの基礎を解説する2つのセッションを紹介

またCappos氏は日本で開催されたカンファレンスでもプレゼンテーションを行っている。Cappos氏が2023年12月に東京で行われたOpenSSF Dayで解説したSBOMitの記事は以下を参照して欲しい。

●参考：OpenSSF Day Japan開催。中国からの脅威から新しいOSSプロジェクトの紹介までを総括

今回は研究室に所属する中国からの留学生Yuchen Zhang氏を招いて前半をZhang氏、後半をCappos氏が担当して解説を行った。プレゼンテーションのタイトルは「Your SBOM is Lying to You - Let's Make It Honest」というもので、SBOMにおける課題とそれを解決するSBOMitについて解説する内容となった。

●動画：Your SBOM Is Lying To You ? Let’s Make It Honest

プレゼンターのJustin Cappos氏。後ろにいるのがYuchen Zhang氏だ

まずはZhang氏がソフトウェアを開発し、稼働させるまでに多くの見えない依存関係やライブラリーが存在していることを解説。ここではOpenSSLを例にとって、その中身がさまざまなライブラリーによって構成されていることを示した。

OpenSSLを例にさまざまな依存関係やライブラリーが存在していることを説明

そしてOpenSSLが使っているライブラリーに脆弱性が発見されたことを例に挙げて、現代のソフトウェアがさまざまなライブラリーを土台にして構成されていることから、ユーザーが書いたソフトウェアの下のレイヤーに何が含まれているのかを知っておく必要があることを説明した。

Log4Jの脆弱性によって引き起こされた攻撃が3日間で約80万回も繰り返された

そしてLog4Jの脆弱性によって引き起こされた攻撃が3日間で約80万回も繰り返されたことを指摘して、攻撃者は常に脆弱性をきっかけにシステムへの侵入を試みていることを説明。ここでもソフトウェアに何が含まれているのかを認識する必要性を訴えた。

SBOMは食品に含まれる原材料を確認するための「栄養成分表示」

ここではアメリカらしくアップルパイを例に挙げて、原材料として何が含まれているのか？をソフトウェアに適用したものがSBOM（Software Bill of Materials）であると説明。

SBOMは作成後に生成されることで虚偽の内容となり得ることを説明

現在のSBOMの課題を整理するスライドでは、SBOMはソフトウェアがビルドされた後に生成されること、実行時に使われるライブラリーなどが含まれないために偽造や改ざんが容易であることなどを挙げた。生成後にSBOMが作られることについては、アップルパイが焼けた後にその匂いから原材料を同定することと同じであると説明。

oxipngというRustで書かれたpngファイルの最適化ツールを例に挙げて説明

ここではRustで書かれたpngファイルの圧縮ツールoxipngのビルドで使われる依存ライブラリーに、ツールには直接関係のないライブラリーを追加してビルドすることで依存関係にあるライブラリーが増えてしまうことを指摘。たった一つのライブラリーを追加するだけで、依存関係が48から54に増えてしまうという。

そしてソフトウェアのソースコード編集からビルド、パッケージング、配布のそれぞれの段階に攻撃者が付け入る隙があることを示して、単にパッケージされたソフトウェアからSBOMを生成する発想が不十分であることを解説した。

ソフトウェア開発のさまざまな段階で攻撃されてしまう危険性を解説

ここからはJustin Cappos氏にバトンタッチしてSBOMitの解説に移った。

Justin Cappos氏がSBOMitを解説。「SBOMit = SBOM + in-toto」が命名の由来

ここでもアップルパイを作ることを例にして、キッチンでのすべての作業をカメラで撮影することがSBOMitの機能であると説明。in-totoはCappos氏がコントリビュータであるCNCFのプロジェクトだが、2025年4月23日にCNCFからはGraduationしたプロジェクトでもある。in-totoはソフトウェア開発の各ステップに暗号による署名と属性であるAttestationを追加することで、攻撃から保護するためのフレームワークである。

in-totoによって各プロセスで行われたことをAttestationとして暗号署名によって保護

ソフトウェアに含まれるライブラリーなどに署名、署名した日時やID、利用したコマンド、環境などが属性として保持されることで、そのプロセスで行われたことをスナップ写真のように記録することが可能になる。

in-totoの記録（Attestation）を追跡することでそのソフトウェアがどのようにビルド、パッケージ、署名されたかが明らかになる

このスライドにあるように、すべてのAttestationを追跡することでソフトウェアがどのようにビルドされパッケージ化され、誰が署名したか？が明らかになる。

SBOMとSBOMitによる「ソフトウェア開発のさまざまな段階で攻撃されてしまう危険性」への対応を説明

ここでは表を用いて、SBOMと署名されたSBOM及びSBOMitがどのように危険性に対応しているのかを説明。現行のSBOMではすべての項目でバツ印が付けられ、機能として不足していることを示している。SBOMitについては2つのバージョンで実装を目指しているとして、より簡易なフェーズ1ではハックされたコンパイラーへの対応とSBOM生成の際に不足する情報によって発生する脆弱性には対応できないが、より強化されたフェーズ2ではハックされたコンパイラーによる脆弱性以外は対応可能となる予定であることを説明。

コンパイラーそのものがハックされることで、ソフトウェアに悪意のあるコードが侵入してしまうことに対して、外部から対応するのは困難だろう。コンパイラーの開発プロジェクトにSBOMitの使用を推奨するのが遠いようで近道かもしれない。

SBOMを作業後のチェックリストとして使うのではなくプロセスに組み込むことを推奨

最後にSBOMをソフトウェア開発プロセスの最後に行うチェックリストのように使うのではなく、開発のプロセスに組み込んで防御の一環として扱うことを推奨した。

最終日の最後に行われたセッションだけあってやや参加者に乏しい状況ではあったが、SBOM生成をソフトウェア開発プロセスの最後に行われる儀礼的なプロセスではなく積極的にプロセスの中に組み込んで使うことで、よりセキュアなソフトウェアが開発できることを示した良いセッションだった。デモで使われた動画がややわかりづらかったことが残念であった。