毎々お世話になっております、OSS・SBOMGグループの明石と申します（所属課の名前が変わりました）。 普段はSaaSの設計、開発、運用を行う傍ら、このような記事を書いたりしています。

2024年4月16日にようやくSPDX 3.0の正式リリースが出ていたので以前のような解説を書こうかと思っていたのですが、調べた結果今回は断念することにしました。 代わり...と言えるかはわかりませんが、今回は3.0の情報を軸に、直近のSPDXの使われ方とこれからを推察するという形で自分なりの所感を書いてみようと思います。

よろしくお願いします。

SPDX Specification（以降SPDX specと呼称します）とはソフトウェアの構成情報、すなわちSBOM（Software Bills of Material）を表現するため、どのような情報がどのようなファイルにどのような形で記載するかを定めたSBOMの仕様、フォーマットです。3.0より前の話は別の記事で解説してありますので、興味のある方はそちらをご覧ください。

SBOMのフォーマットとしてはほかにもCycloneDX、SWIDなどが存在します。その中でもSPDX specは主にOSSライセンスのコンプライアンス管理に用いる情報を記録することを想定したフォーマットでしたが、2021年5月の米国大統領令から発した一連の議論の中で推奨フォーマットの一つとして言及されたことを機に、デファクトスタンダードのような立ち位置となりました。 そうしてSBOMという概念とセットでSPDXが普及する中、SBOMが持つ構成情報すなわちソフトウェアコンポーネントの情報に脆弱性に関する情報を含め、SBOMをソフトウェアの脆弱性管理に用いようという動きが活発になっていき、SPDX spec側もそうしたニーズに応える形でフォーマットがアップデートされてきました。特に2024年12月には、広範に使われているOSSであるLog4Jの脆弱性が発見、広く周知されたことでソフトウェアの構成管理に対する関心が更に高まり、SBOMの有用性とともにSPDX specも認知がより大きく広がったのではないかと思います。

こうした情勢の変化を踏まえてか、新たにメジャーアップデートとして発表されたSPDX 3.0は2.3から仕様が根本的に変更される結果となっています。具体的な内容に入る前に、なぜそのような結果に至ったのか背景についても触れておきたいと思います。

すでに述べたように、SPDX specは元々ソフトウェアのライセンス管理における利用を想定して仕様が策定されていました。3.0からは、2.3まで部分的な対応に留まっていた脆弱性などセキュリティに関する情報をはじめ、ソフトウェアをビルドしたときの情報やAIに仕様されたデータセットの情報など、より広範な情報を構成情報として保持、利用することを対象領域として想定、仕様を拡大しています。

（なお、比較対象としてよく名前が上がるCycloneDXは策定団体であるOWASPがサイバーセキュリティのコミュニティということもあり、SPDX specより速い段階で脆弱性に関するユースケースを想定し情報を書き込むフィールドが用意されていたりします。）

一番大きな変化なのは、通称である「SPDX」の由来が変更された点です。「SPDX」自体はSPDX spec以外も含む全体、つまりプロジェクト名の略称なのですが、2.3までは「Software Package Data Exchange」であったものが3.0から「System Package Data Exchange」に変更されました。これは技術面に留まらずSPDXプロジェクトの思想的にも根本的な変更を意味しており、需要の変化に応えるため対象領域を意図的に拡大、再定義する必要があったことを感じさせます。 SPDX 技術チームの共同リーダーである Gary O'Neall氏も過去3.0の変更について、以下のような言及をしています。

「医療機器で使用されているソフトウェアについて考えると、その安全性を確かめたいものです。これは、3.0 で行っているビルドとセキュリティ環境の枠を超えています。医療機器とそのソフトウェアを安全にするには、その機器がどのハードウェアで実行され、そのハードウェアの構成がどうなっているかを知る必要があります。そのため、私たちはその分野でも作業を進めています。」 Gary O'Neall,https://fossa.com/blog/spdx-3-0/

上記は医療機器に対して向けたものですが、特定のユースケースでは発生する課題を解決するのにソフトウェアの構成情報だけでは限界があることを述べています。SPDXプロジェクトはそういった状況に追随し適応するために対象領域を広げることを決め、その流れでフォーマットであるSPDX specの仕様を大きく変更したのでしょう。

抜本的な変更があっただけあり、3.0の仕様は2.3からページ数自体が増加しています。 また、これが今回詳細な解説を諦めるに至った原因なのですが、2024年8月時点では仕様で提示される実例や公式サンプルが少なく確認手段に乏しいことがわかりました。なので今回は踏み込まず、変更点について簡単にご紹介する形にしたいと思います。

※執筆時点でGitHubリポジトリの開発ブランチなどで内容が一部更新されているものもありましたが、あくまで2024年8月時点のこちらに記載されている内容が正規のものとして解説しています。

3.0ではフォーマットはJSONに絞られました。JSON-LD形式でスキーマが提供されます。 2.3以前に準拠して作られたSBOMファイルとの互換性は意識されておらず、フィールド名はそのまま引き継いでいるものもありますが、構成が大きく変更されています。2.3でできたJSONと3.0でできたJSONを差分で比較、理解するのは難しいでしょう。

2.3まで対応していたJSON以外のフォーマットについては完全に捨てたわけではなく、3.1以降で検討するとのことです。今回はリリースすることを優先したのだと思います。

全体で見るとどの程度影響がある変更かはわかりませんが、2.XではSPDX独自のファイルフォーマットとして規定されていた「tag:value」形式も、当然3.0でオミットされました。 自分は過去この形式を元にこういうものを作ってたりしまして、この形式の復活を望んでいたりします。

とは言うものの、広く使われることを考えるならJSONがちゃんと使えるようになって需要を満たすことが優先なのは当然ですし、今回はなるべくしてこのような形になったのだろうと納得もしています。独自フォーマットを整備する労力は相当なものだと思いますし、元々3.0リリースを予定していた時期から相当遅れていましたから本当に余裕はなかったのでしょう。

ただ、その需要がJSONでほとんど賄えてしまう可能性も考えるとtag:value形式は労力が見合わず、このままフェードアウトしてしまう可能性が高いような気もしています...この先どうなるか、行く末を見届ける所存です。

3.0からSBOMのメンタルモデルはオブジェクトモデルとなっています。つまり「継承」のような、プログラミングにおけるオブジェクト指向で使われている概念が仕様の中に登場するようになり、SPDX specを理解する前にそれらの概念を把握していることが前提となりました。例えば仕様中の文章ではinheritという表現が使われていますが、「PackageというクラスはArtifactという抽象クラスを継承したものである」という文章があるならそこから「PackageクラスはArtifactクラスが持つプロパティを暗黙的に含んでいる」といった解釈をしながら読む必要があります。これまでのSPDXはどのフィールドにどんな値を埋めればいいかだけが指定されていたのに対し、単純に対象スコープが拡大したうえにこのような変更がなされたことで3.0からはプログラマーの素養がないと仕様の把握が難しくなった形となりました。

元々難解だった面もあるのですが、今回そのハードルはさらに上がってしまったという印象です。

SPDX specで書かれたSBOMファイルをよりソフトウェアで操作しやすくする、情報量に比例して上がった難読性を緩和するべく導入されたのがこのプロファイルになります。 ざっくり言うとそのSBOMが持つ情報の性質、言い換えれば対応可能なユースケースを記載するプロパティです。プロファイルのタイプごとに埋めるべきプロパティや要素の個数などが決まっており、各SBOMは自身が持つプロファイルのタイプに準拠した情報をもつ必要があります。

このSBOMが持つ情報の性質を示すプロパティの導入により、3.0からはそのSBOMがユーザーにとって必要な情報を持つか詳細を確認せず判断ができるようになりました。 例えば、あるSBOMのプロファイルにsecurityと書いてあったら脆弱性に関する情報があるので読む必要がある、逆にsoftwareはないから依存関係の情報は記録されていないので中身は確認しなくて良い、といった具合にプロファイルだけを見て判別することが可能です。

3.0ではプロファイルとして以下が規定されています。

プロファイルごと準拠すべき条件は、2024年8月時点だと仕様にまだすべて記載されていないようです。もうしばらく待ちましょう。

2.3までRelationshipsはSPDXドキュメント内部、つまりSBOMファイルの内容の中での関係性に関する情報を記載するフィールドでしたが、3.0からは別のSBOMファイル、またはその内部情報に対してRelationshipsを記載することができるようになりました。この変更によって単一のSBOMファイルがすべての情報を集約して持つ必要がなくなり、SBOMファイル同士が参照し合うことで互いを補完し合うことができるようになる、とのことです。IDもSPDXドキュメント内でのみ有効な値（SPDXRef-DOCUMENTなど）以外に、任意の名前空間を指定して記載することが可能になりました。

もっとも、SPDXが難解とされる理由の一つでもあったこのRelationshipsのタイプ（contains、dependsOn、etc...）は相変わらず細かく、とっつきにくさ自体も変わっていないので3.0以降この仕掛けが普及するかは何とも言えません。

変更点は一応こちらにまとめられています。根本的な変更だけあって2.3から3.0の分だけめちゃくちゃ長いです。

このようにSPDXには大きな変更が入りました。ただそれによってSBOM界隈や実運用に大きな影響があったかと言われるとそうでもありません。今回の変更がSPDXかCycloneDXどちらが良いかに代表される技術的な課題に対して何の影響も及ぼさないということではないのですが、そもそも運用におけるベストプラクティス的な指針がまだ見当たらないことでSBOMの本格導入に足踏みしていてそこまで行けていない印象をもっています。そんな現状について、軽くまとめてようと思います。

※当社の公式見解ではなく、いち個人の意見としてお読みください。

SBOMを運用する際、ファイルフォーマットの筆頭候補はJSONと言えるでしょう。SBOMファイルをソフトウェアで操作することにより、ソフトウェアの構成情報へのアクセスを簡素化しようというのがそもそもの目的の一つでもあります。現状SPDXとしてファイルを操作するライブラリは少ないものの、あくまでJSONとして扱うのであれば既存のエコシステムの恩恵を受けられるので、当然の傾向と言えるでしょう。SBOMを取り扱うツールやライブラリもまずJSONをサポートすることが多く、当社で取り扱うツールについても同様です。

なお、SBOMのフォーマットという面から見た場合、SPDX specのJSONに関するリソースの信頼性が低い時期があったせいかCycloneDXに少し流れてしまったように見えるところがあり、恒例のSPDXかCycloneDXか議論は去年と今年とでは状況が変わっている気がしています。

筆頭は間違いなくJSONなのですが、ほかがまったく見向きもされていないかと言われるとそうでもありません。特に日本においては、SPDXのサブセットであるSPDX-Liteを用いてスプレッドシートで作成する層が一定数存在します。要は日本の企業であれば大体使っているエクセルで操作できること、仕様が簡素でとっ付きやすくなっていることの2点が合わさって選択されている印象です。SBOMの運用におけるベストプラクティス的な指針がない以上、このように企業や組織の事情を優先して選択することもあるのではないかと思います。 （補足しておくと、SPDX-LiteはSPDXを扱う敷居を下げるために策定された仕様なので、まさに目論見通りに機能していると言えると思います。）

繰り返しになりますが、現状SBOM運用のベストプラクティスがありません。これは「どこまで依存先のコンポーネントを構成情報に含めれば良いか？」「”コンポーネント”＝バイナリ？」といった、記録すべき情報の範囲に関する模範的なアンサーが存在しないということを意味します。現状この範囲はSBOMの作成者に完全に委ねられており、人によってパッケージマネージャで明示的に指定するものだけを含める場合から、Dockerのランタイムコマンドで出せるものはすべてを含めるというように幅広い解釈の余地を生む状態となっています。結果として、SBOMに含まれている情報量や"Material"、つまりソフトウェアコンポーネントの単位そのものがSBOMごとにバラバラです（SPDX specではファイル、スニペット単位でも情報を記述できるような仕様になっていますが、「必ずファイル単位で情報を記載すべし」としているわけではなく、あくまで記述できる選択肢を用意している形です）。

正直なところ、この問題はSBOMの対象がWebアプリなのか組み込みなのか、またSBOMでやりたいことで必要な情報は変わるので、ケースバイケースとしか言いようがないというのが今の自分の意見です。共通認識ができ上がるまで、かなり時間を要するのではないかと思われます。 いつしか「2階層下まで記録すればOK」的な基準がNTIA、EUのような権威ある団体、法規から示されたらそれが共通認識となり皆そこまで迷わなくなるかもしれません。

情報を含めるべき範囲の話題に大きな影響を及しているのがセキュリティ面でのユースケース、具体的にはSBOMが持つソフトウェアコンポーネントを脆弱性管理における情報源として用いるような使い方です。コンポーネントの情報としてmavenリポジトリのidやpURLなどの識別子を持たせ、これと脆弱性の識別子であるCVEと紐付けることでSBOM単位での脆弱性を管理する、という仕掛けを効率よく行えないかさまざまな努力がなされています。

個人的に、この試みが目論見通りに行えている所は少ないのではないかと考えています。理由は複数思い当たるのですが、長くなるので一つだけ言及すると、一律の基準を以てAとBが同じソフトウェアであると判断するのは非常に難しい点が挙げられます。 例えば、社内ルールに従って作った製品XのSBOMにコンポーネントA、コンポーネントBが含まれていたとします。あるとき、著名なOSSに危険な脆弱性が含まれていることが発覚、製品XのSBOMを使って影響範囲を調査していたところ、コンポーネントBはコンポーネントAのソースコードをZipファイルとして圧縮しただけで、製品XにおいてコンポーネントAとBは"同じもの"であることが判明する、というようなケースです。これは非常にわかりやすいパターンで、現実的にはもっと判断しにくいケース（「Zipファイルとして圧縮しただけ」の部分が「テスト用にログを出力するような改変を施して開発中は使用していたが製品には含まれていない」に変わるなど）が多数、それも高頻度で発生すると思います。くわえて、誤ったIDが付与されていたり、SBOM作成方法の変更によって過去作成したSBOMとこれから作るSBOMの比較が難しくなったりする、変更が入りやすい製品はSBOMが大量にできてしまうなど、別の問題もあわせて発生します。 そうしてSBOMが持つ構成情報だけでは判断がつかない状況に陥り、結局はソフトウェアそのものであるバイナリ、ソースコードをみて判断するしかなくなります。こうなると、効率性を上げるという目的からどんどん離れてしまい、仕掛けを維持する意義そのものが問われかねません。

以上から、ソフトウェアの構成情報から脆弱性の管理を行うという試みは、何を持ってソフトウェアを同一と見做すかのような、SBOMというよりソフトウェアに対する認識そのものに共通見解が生まれない限り、なかなか進展しないのではないでしょうか。組み込みソフトウェアのように更新頻度が少ない範囲ではノウハウが早期に確立するかもしれませんが、更新頻度の多い分野までカバーできるようになるのはかなり先と考えています。

ソフトウェアを開発した場合、その構成情報にはOSSだけでなく自分たちで開発したソフトウェアコンポーネント、ソースコードが幾分か含まれているはずです。また、有償でソフトウェアの使用権を得て製品に組み込んで使う、COTS（Commercial Off-the-Shelf）と呼ばれる類のソフトウェアを含むこともあるかと思います。 すでに述べた通り何をしたいかでSBOMに含めるべき情報が変わるので、こういったコンポーネントに対しても、揃えるべき情報の目安となる基準がありません。むしろ、組織や企業ごとに文化や重視したいポイントが異なることから、OSSより基準が定まりにくい面があるかと思います。 しかし、組織全体でSBOMの管理を行うとなれば何らかの基準を定める必要が出てきます。この基準をどうしたらいいか、自分も含め色んな方が悩まれている印象です。

また、情報はそのソフトウェア利用者が多ければ多いほど広まりやすく、WindowsやLog4jのような利用者の多いものについては脆弱性とその対策情報なども広まりやすい傾向にあります。対して多くの自社開発、COTSコンポーネントは利用者が比較的少ないので、公知に出回る情報には余り期待できず、どちらかというと社内の情報を集約、管理する性質が強くなるかと思います。そうなると、この基準をどう定めるかの重要度がより増してしまい、一度動き出すと後戻りしづらいような組織、規模の大きい企業ほど運用に踏み切りづらくなるのではないかと思います。

後半はSPDXというよりSBOMの運用視点の話になってしまった気はしますが、たぶん同じような課題感は皆持っているだろうと思い込むことにし、残りはSBOMのこれからについて少し考えてみます。

まず確実に言えることは、これまでSPDXを使っていた人たちが今すぐSPDX 3.0への移行を検討する必要は皆無で、今は様子見が正解だということです。すでに述べた通り3.0に対応したライブラリが存在しない、サンプルのSBOMはおろか仕様のドキュメントも参照するにはまだ記載が不足している箇所が散見されるなど、今は準拠しようとしても情報に辿り着くこと自体にハードルがあるというのが自分の見解です。 こういった状況なので、少なくとも2024年中は3.0のことを考えなくて良いのではないかと思います。仮に今すぐ情報が出揃って移行に対応したとしてもSPDX 3.0でできたSBOMファイルを操作できるソフトウェアがないので、活用できないでしょう。

SBOMを活用するには、開発したソフトウェアとその関連情報を元にSBOMを作って揃えるところがスタートラインです。多くの場合ではmaven、npmなどのパッケージマネージャを使って開発を行なっているでしょうから、その情報を使ってSBOMを作成するのが良いでしょう。パッケージマネージャがない場合は明示的、つまり開発者がソースコード上で使用したOSS、ライブラリ群だけでもリスト化しそれをSBOMとして仕上げるのが良いでしょう。依存しているコンポーネントが更に依存しているコンポーネントのようないわゆる暗黙的な依存コンポーネントの情報も揃えたいと思うかもしれませんが、記録するコンポーネントが増えれば増えるほどノイズとなる情報も増え、構成情報を確認する際の妨げとなります。 役に立つかわからない細かい情報よりも、まずは選択したうえで依存しているのが確実なコンポーネントに絞って整理したSBOMを揃えるのが情報の信頼性から見ても良いかと思います。OSSについては後から暗黙的な依存先も辿ることが可能ですし、後からSBOMを追記するという選択肢も取りやすいです。

これを決めるには先に「SBOMの情報でしたいこと」を具体化するのが大前提ですが、SBOMに揃えるべき情報としてNTIAからThe Minimum Elements For a Software Bill of Materials （SBOM）として以下の要素が挙げられています。自分たちでSBOMを作成する場合、まずは下記を埋めていくのが今後しばらくはベターでしょう。

ただし、「依存関係」については埋めなくて良いかと思います。この「依存関係」がどういう影響を及ぼすのか理解するにはソフトウェアエンジニアの素養や経験が必要であり、この情報はそういう経験を持つ人材が確認して初めて価値を持ちます。くわえて技術的に見てもこの情報を同じ基準で判断して生成するのが難しいせい信頼性にも乏しく、そういう人材がいたとしてもSBOMファイルの情報だけ見て何かが判断できるとは限りません。結局ソースコードを見て判断する方が早く済むことすらあります。こうした効率性の面から見ると、「依存関係」の情報は持つ意味がほぼありません。今後SBOMの中にある情報の精度が高まる、情報を十全に扱えるようなソフトウェア、サービスが登場するなどすれば話は変わってくるかもしれませんが、今頑張ってこの情報を埋めたとしても活用できないでしょう。ほかの情報を揃えることに注力する方が有意義だと思います。

これを機にSBOMの運用を始めようという場合は、極力JSONで作成し情報を揃えるところをめざすのがいいのではないかと思います。世の中の汎用的なライブラリの恩恵を受けられますし、こちらを利用すればスプレッドシートに変換して提出することもできます。 逆に、スプレッドシートに書き起こしてJSONという順序はあまりお勧めしません。個人的な観測範囲だとこの"ハードルが低いからスプレッドシート"パターン、基本的にスプレッドシートがエクセルで扱えるから採用されることがほとんどだと思っているのですが、エクセルで何かファイルを操作されたことのある方は内容が「いつの間にか」変わっていたという経験、ないでしょうか。よく聞く話だと思うのですが、そういう事が起こり得る可能性の高いこの組み合わせは、長期的な情報の保管という観点で見ると情報を損なうリスクが高いと考えています。大元はJSONで作る方が無難だと思います。

これもすでに述べましたが、SBOM内で自社製品を管理する場合はSBOM以前に自社製品をどう管理する・しているかが密接に関わってきます。例えば自社製品をSBOMで一元管理する際は識別子、つまりIDをなんらかの形で付与する必要がありますが、このIDをSBOMの中だけで用いるならばSBOMを管理する主体がIDも管理すれば事足りるものの、すでに存在する社内システムと紐付けたいような場合はIDの要件がかなり複雑になるかと思います。自社製品を管理する際はやりたいことをしっかり揃えたうえで踏み切ることを推奨します。

なお、当社のSBOM導入支援 / SBOM活用支援、SBOMガイドライン策定支援ではこのような運用面も含めた課題についてもご相談・支援が可能です。お困りごとがございましたらこちらのサービスのご利用を是非ご検討ください。

今年になってようやくSPDX 3.0が正式リリースされ、少し時間が空いたので色々と調査しました。結果として3.0の情報にかこつけ、自分が現状について考えている所を色々書いた形になってしまった気がしますが、後から見返すのも面白いかと思い記事にすることにしました。こちらの内容が誰かの参考になったのであれば幸いです。 技術的な深掘りは断念しましたが、実例が揃った段階で再度チャレンジできればと思います。それでは。