ご挨拶
OpenChain Japan Advent Calendar 2024 10日目担当の 小保田(KOBOTA) です。
日本のローカルコミュニティである OpenChain Japan では、明日の記事担当の @TakashiNinjyouji さんなど私の他に2名の方と共同で SBOM subgroup のリーダーを、また、グローバルコミュニティである OpenChain project では SBOM study group のリーダーをさせていただいています。
何故今更、SBOM study group?
SBOM study groupを立ち上げたのは今年7月末です。つい先日ですね。
既にSBOMの議論は世界中で多く行われていますし、また先月11月に発行された CRA は2027年に完全施行、その前年である2026年から一部対応が必要になるために、各社担当者が既にシステム構築などの議論を始めているタイミングなのではないでしょうか?
そんな中で、何故今更、SBOM study groupを立ち上げるのか、というイメージを持たれる方もいらっしゃるかもしれません。これは、SBOMの実運用にまだ多くの課題を抱えているからです。
SBOMとは?
SBOMは良く食品の原材料表示などを例にして説明されますが、今日は少しソフトウェアエンジニア向けに考えてみましょうか。
脆弱性が見つかった際に及ぶ影響の早期発見と言ったセキュリティ対応や、OSSライセンスコンプライアンスへの対応など、本来解決したい課題を考えた場合。
SBOMの本質とは、動作している製品やシステムにどのようなソフトウェアコンポーネントが含まれており、何か問題が起きた場合に素早くその原因を特定する為、それらソフトウェアコンポーネントをインベントリで管理しましょう、ということだと私は考えています。
これは、昨今のソフトウェアシステムの構成管理が自動化を前提に考えられつつある中で、一見簡単に解決できそうな課題に見えます。
例えば、自システム上の各ソフトウェアコンポーネントを管理するシステムを作成、それぞれ必要な情報をモデルとしてインベントリで管理、必要になった際、そのモデルのビューとしてSPDXやCycloneDXと言ったフォーマットでシリアライズを行う、といったように考えると分かりやすいでしょう。
(*OpenAI DALL-Eにて作成)
まだまだ課題を抱えているSBOM
しかし、様々なイベントやコミュニティで多くの方々と議論をさせていただいた過程で、まだまだ多くの課題があることが分かってきています。
まず、様々な仕様やガイドラインが出されている一方で、それぞれの仕様・ガイドラインに記載されている内容は抽象的に表現されている部分があり、詳細に定義されていない部分があります。また、特にSPDXは今年5月に新しいバージョンが策定され、その仕様が過去バージョンから破壊的変更を伴っているため、多くの関係者の間でその仕様解釈に違いが発生しています。つまり、modelからviewを生成する際に実装毎に違いが発生しますし、慎重なツール実装者はそもそも実装を進めません。
例えばはっきりしていない項目の1つに、SBOMに必要な項目として、一体何を記載すべきか？というものがあります。
AdventCalendar 2024 7日目 で渡邊さんも記載されていますが、NTIA minimum elements や CISA Baseline Attributes に対して、SPDX や CycloneDX ではどの項目が対応するのか、という点について以前からしばしば話題になっていました。
OpenChain Japan SBOM subgroupなどでも、SBOM element comparison として確認していたりしますし、後述の SPDX Lite で必要な項目を抽出する際に議論もしていました。
ここで、どの項目を対象とするか、という点では議論されているのですが、では、その項目に記述すべき内容は?となると途端に曖昧になります。
ここで、SPDXの仕様を見てみましょう。
例えば v2.3 の仕様で、NTIA minimum elementsに記載のあるComponent Name を記載するにはどうしたら良いでしょうか?
これは Annex K に、7.1章 Package Nameが該当すると記載があります。Package Nameの定義は以下の通りです。
Identify the full name of the package as given by the Package Originator (7.6). The metadata for the package name field is shown in Table 13.
そして例として、
PackageName: glibc
と記載されています。さて、果たしてこの通りに生成されるツールはどれだけあるでしょうか?
$ dpkg -l で出力される Name field を返してくれるSCA(Software Composition Analysis)ツールもあれば、解析に用いたファイル名を利用するツールも存在します。同じパッケージを扱っていたとしても解析に使うソースコードアーカイブのファイル名が違ったり、何種類かのツールを組み合わせて使う場合にこれらが同じ文字列になっている保証はなく、時に混乱を引き起こします。
これらは unique id の課題と合わせて、実際のパッケージをどのように特定すべきかと言った、名寄せ問題として未だに解決されていません。
続いて unique id の課題です。
同じく、SPDX v2.3 Annex K では、unique idに相当するものは、Document Namespace と SPDX Id である、と記載されています。
しかしながら、この unique id は単に特定の SBOM 内でコンポーネントを区別するためのものでしかなく、例えば別のツールで生成した SBOM を import した場合、完全に同じコンポーネントであったとしても、それらを別々のものとして認識してしまうという課題をはらんでいます。
更に、こういった問題を解決しようとして実装された purl や Software Heritage Id など外部のユニークなIDを考えてみましょうか。SPDXではこれらを External reference field として実装します。
しかしながら、External reference field は、そもそも Optional な定義であって、実装しているツール、実装していないツールが存在します。勿論、purl などで表すことのできないプロプライエタリなモジュールが含まれている場合も存在します。
結果として何を主キーとしてコンポーネントを特定すべきかということがまだ課題として残ってしまっている状態であり、簡単には解決できません。
他にも、動的リンクされるライブラリについてのSBOMはどのように受け渡されるべきか、運用が始まった後に第3者から依存ライブラリがアップデートされた場合、その間の依存関係はどのように記述されるべきなのかなど、解決しなくてはいけない課題がまだまだ多く存在しています。
私が皮肉だなと感じているのは、複雑なソフトウェアサプライチェーンに起因するソフトウェア構成管理の問題を解決しようとしているSBOMであったはずなのに、ソフトウェアサプライチェーンに起因する問題でモデルとビューの間の関係性を記述出来なくなっている点です。
OpenChain SBOM study group と OpenChain Japan SBOM subgroup
上記のような課題がまだまだ残っていると感じたため、OpenChain グローバルに SBOM study group を作りました。複雑なサプライチェーンを考えた場合に、どのような課題が残っているのか、またどのように解決したら良いのかなどを議論する場として。
また、Japan SBOM subgroupは、ローカルコミュニティの議論をグローバルコミュニティに持っていく手段として考えています。
多くの企業、多くの方がどのようにSBOMを実装したら良いのかを研究開発しており、またその過程で多くの課題を見つけていらっしゃると思います。
それら課題に対して、「こんなことに誰も気が付かないのか」「どうしてこれを直さないんだ？」こんな思いを持っていらっしゃる方もいらっしゃると思います。
是非、そういった意見を共有してください。SBOMは複雑なソフトウェアサプライチェーンを伴って配布、分割、統合されていくものですから、どこかの誰かだけがうまい実装をしていたとしても解決しないんです。
企業を超えて、オープンソースコミュニティが存在している価値がこういうところにもあるんだと、私は信じています。コード貢献だけでなく、技術的な実ユースケースの共有、ワークフロー設計などにおいて、エンジニアの皆様が活躍できる場がオープンソースコミュニティにもあるんだということをお伝えして、第10回を締めたいと思います。
ありがとうございました。