KubeCon + CloudNativeCon Japan 2025 - 参加レポ: 『Your SBOM Is Lying To You – Let’s Make It Honest』

developers.freee.co.jp

こんにちは！freee のSREをやっているのyamaです。普段は主にコスト統制をメインに担当しています。

今回は少し毛色が違いますがKubeCon + CloudNativeCon Japan 2025から「Your SBOM Is Lying To You – Let’s Make It Honest」について紹介させていただきます。

概要

SBOMについての基本的な解説と、SBOMがどのように私達に嘘をついているか、そしてその解決を行うSBOMitの紹介という興味深い内容でした。信頼しているはずのSBOMが嘘をつくというのは非常に心配になる内容かと思います。本記事では以下について紹介します。

SBOMについて
どのようにSBOMが私達に嘘を付くのか
SBOMitの紹介

SBOMについて

SBOM（Software Bill Of Materials: ソフトウェア部品表）は製品を構成するソフトウェアやコンポーネント、ライブラリなどの要素と依存関係を可視化する手法を指します。食品で言うところの「原材料表示」や「成分表示」にあたります。 SBOMによって複雑化するソフトウェアサプライチェーンを可視化し、透明性を確保することが期待されています。

ソフトウェアに何が含まれるかを知ることは困難

利用するソフトウェアに何が入っているかを本当に知った状態で利用する、といったことはあまりないと思います。少なくとも私は意識しながらOSSやソフトウェアを利用したことはないと思います。例えばOpenSSLは現在では必須のソフトウェアの1つですが、OpenSSLの中にはliblsp.so、libc.so、libcrypto.so、libdl.so、ld-linux-x86-64.so、libssl.soといったライブラリに依存しています。しかも、これらのライブラリはシステム環境から動的に読み込まれるため、OpenSSLに何が含まれているかをブラックボックス化している一因になります。

多くのエンジニアによって絶え間ない努力が行われていますが、ソフトウェアに脆弱性はつきものです。 libcrypto.so、libssl.soには2023年にそれぞれ脆弱性（1,2）が報告されています。

OpenSSLは多くのライブラリ用いてブラックボックス化されて利用されていることを示す図。 — OpenSSLはブラックボックス化されているが多くのライブラリに依存している(スライド 2 ページより引用)

Log4jShell

Log4jShellとして知られるCVE-2021-44228はリモートコード実行が可能な非常に危険な脆弱性でした。しかし最も問題だったのは多くの組織がLog4jを利用しているということを知らなかったことにあります。

Log4jは「推移的依存関係」として多くのフレームワークやサービスなどに直接埋め込まれない形を含めて、様々なパッケージに隠れていました。SBOMのない環境では「影響がない」かどうかを迅速に判断できませんでした。私自身も発生当時は他社に居ましたが、当時はSBOMなどは導入されておらず対応に苦労した記憶があります。

しかし攻撃者が待ってくれることは無く、脆弱性の報告から12時間後には4万件の攻撃が、72時間後には83万件の攻撃が行われました。これは、SBOMが無いことによる大きな失敗の一例となりました。

Log4j Shellでは脆弱性の公開後12時間で4万件、24時間で12万件、36時間で40万件、72時間で83万件の攻撃が観測された — Log4j Shellでは脆弱性情報の公開から短時間のうちに多数の攻撃が観測された(スライド 3 ページより引用)

SBOMがあれば安心？

Log4jShellのインシデントでは以下のような課題がありました。しかし、SBOMはそれらを解決してくれます。

Log4jインシデントにおける課題	SBOMがどのように役立つか
「Log4jは推移的な依存関係として埋もれていることが多かった」	SBOMは、推移的な依存関係を含む完全な依存関係グラフを表示できるため、直接使用されていなくてもチームはLog4jを発見できます。
「多くの組織は、自らが脆弱であるかどうかを把握していなかった」	SBOMは、自動化されたスキャンとクエリを可能にします。「私はlog4j-core:2.14.1を使用していますか？」をすべてのソフトウェア成果物にわたって確認できます。
「組織全体で影響範囲を評価することが困難だった」	SBOMは一元管理が可能で、大企業がシステム全体を検索して、影響を受けるパッケージとバージョンを特定できます。
「パッチの適用が遅れ、一貫性がなかった」	SBOMを使用すると、バージョンを固定し、古くなった、または脆弱なコンポーネントをより迅速に特定し、更新をより体系的に管理できます。
「ベンダーは証拠なしに『影響なし』と主張した」	SBOMは透明性を提供します。顧客は、脆弱なコンポーネントが含まれているかどうかに関するベンダーの主張を検証できます。

一見完璧に見えますが、SBOMにはまだ課題があります。

どのようにSBOMが私達に嘘を付くのか

SBOMはどの様に生成されるか？

SBOMは食品の成分表示に例えることができます。つまり、パイの中身に何が利用されているかを教えてくれます（パイには甘いものもあればしょっぱいものもありますが見分けるのは困難です）。しかし、現在のSBOMには以下のような問題があります。

ビルド後にSBOMが作成される
- これではまるで「パイを焼き上げた後に匂いで中身を判断する」ようなものです
静的解析または依存関係ファイルに基づく
ランタイムの成果物や推移的な依存関係を見逃す可能性
偽造や改ざんが容易

これはoxipngにて観測されました。 oxipng内に誤ってserdeという依存関係がcargo.tomlファイルに追加されたものの、実際のコードでは使用されていませんでした。しかし、従来のツールでSBOMを生成すると、serdeとその5つの推移的依存関係がSBOMに表示され、合計で54のコンポーネントが宣言されているとされましたが、実際には12の直接依存関係と36の推移的依存関係しか使用されていませんでした。これは、宣言されたものと実際にコンパイルされたものの区別ができないことで、SBOMが「膨張した依存関係グラフ」「誤ったリスク認識」を引き起こし、無駄な労力や信頼の喪失につながることを示す例です。

oxipngのSBOM作成時に実際には利用されていないライブラリを利用しているとSBOMが嘘をついた例。実際には48のライブラリを使用しているにもかかわらず、SBOMは54のライブラリを利用していると検知した。 — SBOMが嘘をついたpxipngの例(スライド 8 ページより引用)

SBOMの限界と攻撃経路

SBOMは有用ですが、「銀の弾丸」ではありません。ソフトウェアサプライチェーンのプロセスにおいて、SBOMが生成される前後に多くの脆弱性があります。

A: 攻撃者がバージョン管理システムを侵害し、悪意のあるコードを挿入する (例: Keydnap、backdoored-pypi)。SBOMは、何が宣言され、ビルドされたかに依存するため、誰が作成し、どのように検証されたかまでは捕捉しません。
B: テストプロセスが失敗している、または存在しない。SBOMはコンパイルされたものを記録しますが、テストや検証が行われたかどうかは記録しません。
C: コンパイラ自体が侵害される (例: SolarWinds、XcodeGhost)。SBOMは正しい「材料」を示すかもしれませんが、汚染された隠された動作を検出しません。
D: 異なるベンダーやツールによってSBOMが不整合に生成される。これにより、ブラインドスポット、メタデータの欠落、可視性のギャップが生じます。
E: SBOM自体が偽造される。暗号的に署名され検証されていない場合、攻撃者は偽のSBOMを作成し、信頼できるものとして提示できます。

ソフトウェアサプライチェーンの中でSBOMを標的とした攻撃がどの様に行うことができるかを示す図。ソースコードからビルド、パッケージ化、SBOMの作成の手順の中でAからEの5つの攻撃例が示されている — 従来のSBOM不十分である(スライド 9 ページより引用)

これらすべての攻撃に対して、従来のSBOMは何の保護も提供しません。署名されたSBOMでも、署名後の偽造は防げますが、署名前の改ざんには対応できません。

これらの問題の多くを克服し、SBOMを信頼できるものにするために提案されたのが、OpenSSFのサンドボックスプロジェクトであるSBOMitです

SBOMitの紹介

SBOMit = SBOM + in-toto

in-totoは、ソフトウェアサプライチェーンのアテステーション（attestation）を生成するシステムです。アテステーションは、サプライチェーンの各ステップで何が起こったかの「スナップショット」と考えることができます。これは「パイを焼くすべてのステップを記録するキッチンカメラ」のようなものです。

in-totoアテステーションの仕組みは以下の4つからなります。

スナップショット：アテステーションは、ソフトウェアサプライチェーンの特定のステップで何が起こっているかを示すスナップショットです。
ハッシュの追跡：ビルドプロセスに入力されるすべてのファイルのセキュアハッシュを追跡し、ビルドプロセス自体でエラーが返されていないか、正しいバイナリが実行されているか、正しい環境で実行されているかなどを確認します。
出力の追跡：コンパイラから生成されるバイナリなど、プロセスから生成されるものを追跡します。
レイアウトによる接続：各ステップの個々のアテステーションを「レイアウト」と呼ばれるものによって接続し、サプライチェーン全体の流れを形成します。

アテステーションは、パイ作り工場で、リンゴがトラックで届けられ、洗われ、切られ、パイに入れられるまで、すべての材料のすべてのプロセスで写真が撮られるようなものです。これにより、サプライチェーンで発生する各アクション（依存関係の取り込み、ビルド、テストプロセスなど）について、詳細な記録が得られます。

in-totoをSBOMと組み合わせたのがSBOMitです。

SBOMitによるSBOM生成

BOMitは、これらのin-totoアテステーションを収集し、そこから情報を抽出してSBOMを生成します。これは、すべて個々に署名された安全な「写真」を使ってSBOMを作成するようなものです。これにより、そのソフトウェアが使用されたことを確実に知ることができます。例えばリンゴがパイに入ったことが写真で確認できるように、誰かが何かをこっそり入れようとした場合でもin-totoがそれを検出して停止させます。 SBOMitのプロトタイプはSPDXバージョン2.3を生成でき、in-totoアテステーションによって必要なすべてのフィールドが埋められ、SPDXがサポートする関係性（例：ビルドプロセスから最終製品が生成された場合の関係）も提供されます。

SBOMitの動作1の図解。ソフトウェアに含まれるライブラリのアステーションがスナップショットを撮影していることと等価であることを示す。パイの例においては「キッチンカメラがパイを焼く際にすべての工程を撮影している」と例えられる — SBOMitの動作1(スライド 12 ページより引用)"

in-totoで作成されたアステーションがSBOMになる過程を示す。まず全てのアステーションを収集し、解析、ソースとビルドの関係を判定。その後、SPDCパッケージとファイルオブジェクトの作成し、関連性の定義を行い、再度にSPDX SBOM（jsonファイル）を生成する。パイの例においては「キッチンカメラがパイを焼く際にすべての工程を撮影している」と例えられる — SBOMitの動作2(スライド 13 ページより引用)

SBOMitがは2つのPhaseを計画しています。Phase1では非常に簡単な導入で一部の保護機能を提供します。Phase2ではポリシーチェックを統合した際にコンパイラ自体のハッキング以外からの強力な保護を提供します。

A: 攻撃者がVCSを侵害し、悪意のあるコードを挿入：SBOMit Phase 1では限定的な保護、Phase 2ではより強力な保護を提供します。
B: テストプロセスが失敗しているか存在しない：SBOMit Phase 1では限定的な保護、Phase 2ではより強力な保護を提供します。
C: 攻撃者がコンパイラをハック：SBOMitはコンパイラの内部ハックには対応しませんが、再現可能なビルドなどの他のプロジェクトと組み合わせることで対応可能です。
D: SBOM情報が不足している：SBOMit Phase 1では限定的な保護、Phase 2ではより強力な保護を提供します。
E: SBOMが偽造される：SBOMit Phase 1とPhase 2の両方で強力な保護を提供します。

SBOMitは、SolarWindsのような改ざんを防ぎ、Log4jのような脆弱性への迅速な対応を可能にし、「設計によるセキュリティ」（Secure by Design）を推進し、ゼロトラスト原則をサポートします。

SBOM,署名済みSBOM,SBOMit フェーズ1、SBOMit フェーズ2によりどの脆弱性に対応するかを示した図。純粋なSBOMでは先に示されたAからEまですべてに対して脆弱であるが、証明されたSBOMであれば、Eのみに対応することができる。SBOMit フェーズ1では限定的にA,Bにも対応できる。SBOMit フェーズ2ではA,B,D,Eに対応できる。 — SBOMit導入により対応できる脆弱性(スライド 16 ページより引用)

SBOMitも銀の弾丸ではありません。あくまで含まれるライブラリが何であるかを認識することのできるツールであり、実際の問題を解決するツールではないことに注意が必要です。検出と対応のセットを組むことが重要です。

最後に

KubeCon + CloudNativeConは初参加でしたが、社内インフラへの理解だけではなく、より先端のトレンドなどに触れることができ非常に有意義でした。私自身はだいぶ英語に自身がなかったのですが、KubeCon + CloudNativeCon Japan 2025では文字起こし＆翻訳ツールも提供されており、ある程度の雰囲気を理解することはできました。皆さんも機会があれば是非参加してみてはいかがでしょうか？