FutureVuls Blog

  • Home
  • Blog
  • エンドユーザーが直面するSBOMの現状：現在のSBOMを取り巻く現実世界の課題と解決策
Blog Techカテゴリ SBOM

エンドユーザーが直面するSBOMの現状：現在のSBOMを取り巻く現実世界の課題と解決策

はじめに

本記事は、2024年10月22-23日に開催された SOSS・Fusion/24 で、Eddie Zeneski 氏（Defense Unicorns スタッフエンジニア）が発表した「The Current State of SBOMs for End Users」（YouTube動画）をもとに、技術者向けに深掘りした内容です。

この講演者はSBOMの専門家（理想論者）ではなく開発者の立場から、現在のSBOMを取り巻く現実世界の課題や現時点の解決策を発表しています。

「自分はSBOMの専門家というより、実際のツールが足りずに困ってメンテナとして関わるようになった開発者です。フォーマット論争を延々と続けるより、現場で役に立つ自動化ツールの整備と、一般開発者にも扱いやすいSBOMの実現が最優先です。」
– エディ・ゼネスキ (Eddie Zeneski)

本記事では、ソフトウェアエンジニアやインフラ運用担当者を想定し、SBOM（Software Bill of Materials）の技術的ポイントや利用シーン、ツール連携、FutureVulsでの解決策などを解説します。

eyecatch

SBOMが注目される背景

SBOM（Software Bill of Materials）に対する注目度が高まっている背景には、ソフトウェアサプライチェーンを可視化する必要性と、各国での規制強化が大きく影響しています。特に、米国大統領令やFedRAMP要件、EU Cyber Resilience Act などでSBOMの提出が義務化されつつあるため、多くの開発者や企業が対応を迫られています。

規制・法令上の要求 (動画 2:52 あたり)

  • 米国大統領令（Executive Order 14028）やFedRAMP要件、EU Cyber Resilience Act (CRA) などでSBOM提出が必須化。
  • 講演内では、「チェックボックス的にSBOMを要求される現状」や「米国防総省（DOD）のソフトウェア導入プロセスでSBOMが不可欠になっている」ことが強調されていた。

セキュリティ＆可観測性向上 (動画 3:45 あたり)

  • 例：Log4Shell のような脆弱性で「使っているLog4jのバージョンがどこに含まれているか」を即把握する手段としてSBOMが有効。
  • 「Ciscoが脆弱性把握に10日以上かかったエピソード」や「Spinachのトレーサビリティ例」などを挙げながら、SBOMがあれば大幅な時間短縮が見込めると語られている。

SBOMの基本：Build SBOMとRuntime SBOM

SBOMには大きく分けて2種類、ビルド時点での依存関係をまとめた「Build SBOM」と、本番実行環境で実際に使われているコンポーネントを示す「Runtime SBOM」が存在します。両方を活用することで、ソフトウェアの構成をより正確に把握できます。

Build SBOM (動画 1:24 あたり)

  • 開発（ビルド）工程で把握できる依存パッケージやライブラリの一覧。
  • たとえば Go言語のgo.mod、Javaのpom.xml、Node.jsのpackage.jsonといったソースコードレベルの依存関係が中心。
  • メリット: 依存リストが正確かつ詳細。
  • デメリット: ビルド後に発生する動的リンクや、OSレイヤーの追加パッケージは含まれない。

Runtime SBOM (動画 2:16 あたり)

  • 本番実行環境で最終的に使用されるコンポーネントのリスト。
  • 例：Dockerコンテナのベースイメージに含まれるOSライブラリやC/C++の動的リンクライブラリなど。
  • メリット: 追加インストールされたパッケージなど「実際に使われているもの」を追える。
  • デメリット: ビルド時点では生成しづらい。

Build SBOMとRuntime SBOMが両方必要な具体例

実際にビルド時とランタイム時で依存するライブラリが異なる例は少なくありません。以下に、講演内で取り上げられたシナリオを紹介します。

例1：チェインガード(Chainguard)のベースイメージ + 独自アプリ (動画 4:43 あたり)

  • 状況:
    • Chainguard製のセキュアベースイメージは高品質なSBOMが付属している。
    • 開発者がGoで書いた独自アプリをビルドするときに別途Go依存のSBOMを生成。
    • 問題: ベースイメージSBOMと自作アプリSBOMをどう結合するか、あるいは分割管理するか。
  • なぜ難しいのか:
    • 「単に2つのSBOMをマージしてしまうと細部の情報が消える可能性がある」
    • 「互いのSBOMをリンクで持つと参照が煩雑になる」などの課題がある。

例2：Zarfパッケージで複数のコンテナをバンドル (動画 6:13 あたり)

  • Zarfとは:
    • DoD環境など「完全エアギャップ（ネット接続不可）」に複数のDocker Imageを1つにまとめて持ち込む際に利用するパッケージ化ツール。
    • GitHub: https://github.com/zarf-dev/zarf
    • 1つのZarfパッケージに10個以上のコンテナを詰め込むケースもある。
  • SBOMの課題:
    • パッケージ内の各コンテナにSBOMが付属しているが、それをまとめてスキャンしようとしても、TrivyやSyft等の既存のツールがZarf構造を理解できない。
    • 「結局、すべてのコンテナSBOMを手動でスキャン＆結果を集約する」手間が発生。

例3：マルチステージビルドでのGoバイナリ (動画 5:01 あたり)

  • ビルドステージ:
    • Goモジュール依存はBuild SBOMとして正確に出力できる。
  • 最終ステージ:
    • 軽量ベース（Alpineなど）にバイナリをコピーすると、musl libc などのOSライブラリ情報がRuntime SBOM側にのみ現れる。
  • リスク:
    • Build SBOMだけだとOSレイヤーで追加された脆弱ライブラリに気付かない。

よくある課題：SBOM生成と活用の難しさ

SBOMは便利な反面、現在のエコシステムでは課題も多いと講演で指摘されています。以下はその代表例です。

課題1: 生成ツールやプラグインの不整備 (動画 7:00 あたり)

  • RubyやAndroidなど、言語によっては公式のSBOMプラグインが乏しい。
  • 「Google検索してもSBOMフォーマットの最新バージョンに追随していないSBOM生成ツールしか見つからない」という事例も語られていた。

課題2: チェックボックス的なSBOM提出 (動画 9:08 あたり)

  • 規制要件でSBOMが必要→とりあえず空ファイルや簡易レポートを提出→形骸化。
  • 空のSBOMファイル を提出してもOKという現状。
  • 実際のセキュリティ向上に寄与せず、運用担当者・エンジニアが後から苦労する。

課題3: ビルドからリリースまでの一貫した可視化

  • CI/CDでBuild SBOMを生成し、本番にデプロイ後にRuntime SBOMを取得するフローの構築が複雑。
  • 自動化でミスを減らそうとしても「作られたSBOMがどれとどれを含んでいるのか分からない」状態になるケースがある。

複数のSBOMを扱う：コンテナやアプリ層の結合問題

講演では、コンテナベースのアプリケーションを使う場合に特に問題が表面化すると紹介されました。ベースイメージとアプリのSBOMをどう結びつけるか、実務上の悩みが多いようです。

シチュエーション (動画 5:01 あたり)

  • ベースイメージ：既にSBOMが付属（例：AlpineベースにChainguardなど）
  • アプリ層：GoやJavaで作られた独自アプリSBOM
  • 結合における悩み:
    • 「1つのファイルにまとめてしまうと重複やメタ情報の欠損が起きやすい」
    • 「別々に保存すると参照・管理が面倒」
  • 講演者の見解: まだコミュニティ全体のベストプラクティスは確立しておらず、さまざまなアプローチが試されている。

フォーマット：CycloneDXとSPDX、そしてフォーマット変換

現在主流となっているSBOMの記述フォーマットは大きく2つに分けられ、CycloneDXとSPDXはいずれも幅広く使われていますが、相互変換時のデータロス問題が指摘されています。

CycloneDXとSPDX (動画 13:20 あたり)

  • CycloneDX：OWASP系プロジェクト。JSON/YAML/XMLで表現可能。
  • SPDX：Linux Foundation主体。もともとはソフトウェアライセンス管理が起源。
  • 変換ロスの問題:
    • CycloneDX ⇔ SPDX を相互変換すると、時間情報や階層構造が正しく伝わらない場合がある。

フォーマット変換

  • protobom (動画 14:42 〜 26:20 あたり)
  • OpenSSF配下のプロジェクトで、SBOMをProtocol Buffers形式で中立的に表現。
  • CycloneDXやSPDXに変換する際のメタ情報欠損を最小化する狙い。

ツールの現状

現時点では多様なツールが乱立しており、それぞれ得意分野が異なります。講演内でも多数のOSSやプロジェクトが挙げられていました。

syft (動画 11:00 あたり)

  • Anchore製のOSSツール。静的ファイル解析からSBOMを生成。
  • コンテナイメージを丸ごとスキャンする際に便利
  • GitHub: https://github.com/anchore/syft

Trivy

  • aqua製のOSSツール。静的ファイル解析からSBOMを生成。
  • この動画では言及されていないが広く普及している。
  • GitHub: https://github.com/aquasecurity/trivy

protobom (動画 14:42 あたり)

  • OpenSSFで開発中の、Protocol BuffersベースのSBOM管理ライブラリ。
  • CycloneDXやSPDXといった既存フォーマットへの入出力やフォーマット変換に対応し、変換時のデータロスを最小化する目的がある。
  • 追加ツールとしてbomctlと連携して利用可能。

bomctl

guac (動画 16:00 あたり)

  • OpenSSFが主導するメタデータ集約基盤。SBOMや署名データ、証明書など幅広く取り込みたい構想。
  • 大規模環境でのSBOM集約と可視化に期待が寄せられている。
  • GitHub: https://github.com/guacsec/guac

エンドユーザーが取るべきアクション

SBOMは規制要件を満たすだけでなく、ソフトウェアのセキュリティレベルを高める上でも重要です。以下は講演で言及された主な推奨事項です。

  1. 言語やフレームワーク別のSBOM生成プラグインを確認する

    • Go, Java (Maven/Gradle), Node.js (npm), Python (pip)などでサポートレベルが異なる。
    • 講演で指摘されたように、古いバージョンしか対応していないプラグインも多いので注意。

  2. ビルドSBOMとRuntime SBOMの両方を取得するフローを設計

    • 例：GitHub ActionsやGitLab CIでビルド時にSBOM、デプロイ後にコンテナスキャン。
    • いずれか一方では、OSレイヤーや動的リンクの脆弱性を見落とす可能性が高い。

  3. SBOMの貯蔵・検索基盤を整える

    • Zarfのように複数のイメージをまとめるケースや、マルチステージビルドなど、SBOMが分散しやすい。
    • guacのような集中管理ツールを使うと、後から依存関係を追いやすい。

  4. フォーマット変換に注意しつつ、protobomやbomctlを活用

    • CycloneDXとSPDXを行き来する際、タイムスタンプや階層構造の損失リスクがある。
    • protobomは中立フォーマットとして、この問題を回避する取り組み。

FutureVulsでのSBOMの課題の解決策

FutureVulsでは、SBOM管理を含むソフトウェアの脆弱性対策を継続的に行うためのプラットフォームを提供しています。
特に以下のページで解説しているように、FutureVulsは SBOMスキャン／管理の仕組みを強化し、ビルド時／実行時両方のSBOMを組み合わせた脆弱性管理を支援します。

1. Build SBOM／Runtime SBOMの一元管理

2. フォーマット変換

  • CycloneDXやSPDXなど、複数フォーマットのSBOMを取り込み・出力可能。
  • SBOM管理ドキュメント で言及されいている通り、複数ツール/フォーマットのSBOMをインポート可能です。

3. Zarfのような複数コンテナバンドル環境への対応

4. 継続的な脆弱性モニタリングと通知

  • Build／Runtime SBOMのデータに基づいて、脆弱性情報(CVE)を定期的に照合。
  • 新たな脆弱性が発見された際には、Slackやメールなどで即時に通知し、運用担当者が迅速に対処可能。
  • SBOMと脆弱性管理を一体化することで、リスク可視化と対策スピードが大幅に向上します。

5. SSVCによる優先度判断とタスク管理

  • FutureVulsでは、脆弱性の深刻度だけでなく、システムへの影響度や攻撃可能性などを総合的に評価する SSVC (Stakeholder-Specific Vulnerability Categorization) を活用しています。
  • SBOMで把握した対象コンポーネントの脆弱性がSSVC上で自動優先度付けされ、最も対処が必要なタスクを効率的に洗い出し可能。
  • 緊急に対応が必要な脆弱性は、担当者に対応指示が通知され、詳細情報、対象、対応優先度、対応期限日などが自動設定される。
  • さらに、ダッシュボード上で対応タスクを作成・管理できるため、チーム全体で修正作業をスムーズに進められます。

6. チーム内共有や自動レポート生成

  • WebダッシュボードでSBOMと脆弱性ステータスを可視化し、チーム内で情報を共有。
  • 各種レポートを自動生成し、社内コンプライアンスや監査にも対応しやすくなります。

まとめ

SBOMはソフトウェアサプライチェーンを可視化し、脆弱性管理を加速させる手段として強く期待されていますが、現状以下のような課題が散見されます。

  • Build SBOMとRuntime SBOMのギャップ
    • 講演ではChainguardやZarf、マルチステージビルドを例に、OSレイヤーのライブラリや動的リンクを見逃す危険性が示唆された。
  • フォーマット変換（CycloneDX ↔ SPDX）時のメタ情報損失
    • 動画中でも言及されているように、相互変換ツールにはまだ不備が多い。
  • ツール連携の未成熟
    • 「Zarfのような1つに固められたDockerイメージ群をそのままスキャンできない」「どのSBOMが最新か分からない」などの悩みが依然としてある。

一方で、protobom/bomctl や guac といったOSSツールが活発に開発され、より高精度かつ自動化されたSBOMワークフローが少しずつ形になりつつあります。

FutureVulsではSBOMを使った脆弱性管理を重視しており、Build SBOM／Runtime SBOMを一元管理しながら、SSVCによる自動優先度判断やタスク管理など、実運用に即した機能を継続的に拡張・改善しています。また、SBOMのフォーマット標準化や法規制への準拠、お客様からの要望を柔軟に取り入れながら、よりスムーズなSBOM運用を支援していく方針です。
今後もSBOMツールの進化や法的要件の変化に対応しつつ、お客様が抱える*問題を解決し、脆弱性対応を円滑にするSBOMプラットフォームとしての価値を高めていきます。

SBOM管理にお困りの方は、ぜひ一度FutureVulsからお問い合わせください。

お問い合わせはこちら

目次

カテゴリー