SPDX Documentを理解する

毎々お世話になっております、株式会社 日立ソリューションズの明石と申します。本日は今年からSBOMフォーマットの国際標準として認定された、SPDXに準拠して作成されたSBOM、SPDX Documentについてご紹介したいと思います。

免責事項

当記事の内容については、できる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではなく、筆者独自の解釈も含むことをご了承ください。 掲載しているリンク先についても確認などは行っていますが、遷移先で提供される情報、サービスなどについては一切の責任を負いません。

また、掲載内容の活用は読者自身の自由と主体性の元に行うものとし、万が一損害が発生したとしても一切の責任を負いかねます。ご了承ください。

そもそも、SPDXって何？

SPDXという単語の由来は「Software Package Data Exchange」の頭文字から来ており、直訳すると「ソフトウェアパッケージのデータ交換」になりますが、これだけでこのSPDXがどういう意味を持つのかを理解するのは少し厳しいと思います（少なくとも筆者はそうでした）。なので、まずはこのSPDXの意味について、背景を交えて簡単に解説します。

背景として、近年のアプリケーションソフトウェアは、多くの部分（一説によると8～9割）がOSS、つまり自前成果物ではない部品で構成されています。これはソフトウェア開発において、OSSの使用がさまざまなメリットをもたらしていることが認知された結果であり、現在のソフトウェア開発はOSSなしに成り立たないといってもよいでしょう。しかしながら、こういった外部の成果物を取り込んで使用するという行為にはリスクを伴います。OSS利用に関するリスクとして最も典型的な例が、ライセンス違反に関するリスクです。OSSには、それぞれ固有のライセンスが適用されています。ライセンスには、そのOSSを利用する際の条件が記されており、これに違反した場合、利用者に対して何らかの法的な措置が取られるケースがあります。他にも脆弱性、信頼性といったさまざまなリスクがあり、ソフトウェア開発ではOSSの利用に伴って発生するこれらのリスクに対応する必要性が増しています。

ここでそのリスク対応において必要となってくるのがソフトウェア部品表、SBOM（Software Bill of Materials）です。SBOMにはアプリケーションに含まれるソフトウェア部品が何であるかを特定する情報、その出所やライセンス、セキュリティについて情報を詳細に記録します。こういった情報を持つSBOMを作成、管理しておくことで、ソフトウェアが抱えている問題やリスクを事前に把握し、どう対処するか判断材料として参照、活用できる、という訳です。また、サプライチェーン全体でソフトウェアの構成部品を追跡する場合にもこのSBOMを使用することができるといったメリットもあります。

このSBOMを標準的な規格で作成し、業界内の異なるチームや企業間での情報交換をやりやすくしよう、というのがSPDXプロジェクトの目的であり、そこで策定されたSBOMの規格、フォーマットがSPDX Specificationと呼ばれています。 （つまり、SPDXという単語はプロジェクトを指す時と仕様を指す時があります。本記事では前者を示す際はSPDXプロジェクト、後者を示す際はSPDX Specと呼称することにします）

SPDXプロジェクトは、具体的な成果物としては以下を提供しています。

• SPDX License List

  SPDXプロジェクトが一般的に適用されるライセンスをリスト化したもの。本文や参照先などのライセンスに関する情報がまとめてある。「GPL」や「MIT」などのよく見るライセンスは概ねカバーされている。

• SPDX Specification

  SPDXプロジェクトが提供するSBOMフォーマット。これに準拠したファイルをSPDX Documentと呼び、本記事で概要を解説する。なお、執筆時点での最新版はv2.2.1。

• SPDX DocumentやSPDX License Listに関するツール、ライブラリ

  SPDXプロジェクトが提供している、SPDX Specificationに対応したファイルに関するツール、ライブラリ。代表的なものとしてSPDXファイルを操作する「spdx-tools」が上げられる。

今回はこのSPDX Specification、SPDX Specが今年国際標準として認定されたということで、それにしたがって作成されるSBOM、SPDX Documentはどういう構造をしており、どのような情報を持つのかについて簡単に解説したいと思います。

SPDX Documentとは

SPDX Specificationにしたがって作成された、ソフトウェアパッケージに関連するコンポーネントやライセンス、コピーライトなどの情報が記された文書のことを指します。具体的には以下の形式かつ、SPDX Specificationが規定した情報が記載されたファイルです。

• Tag:Value(txt)
• RDF
• xls
• json
• YAML
• xml

情報は属性（keyやTag）に対応する値（Value）を記述することで表現します。最初の3つは具体例も示されているので、気になる方は直接こちらをご覧になってください。

特徴、何がうれしいか

冒頭で説明した通りですが、他にも特筆すべき点があります。SPDX Specificationの策定にあたって、SPDXプロジェクトが念頭に置いていることの一つに「ソフトウェアで読み書きできること」というものがあります。つまり、SPDX Documentは、ソフトウェアを介して操作されることを想定しているのです。この仕様に準拠してさえいれば、例えばあるソフトウェアパッケージが依存しているソフトウェアパッケージのそのまた先が依存しているソフトウェアのライセンスを確認したい、といった状況でも手段としてひたすら目で参照先を追いかける以外に、ソフトウェアで参照先を抽出するという選択肢を取ることが可能になるわけです。

当然、ソフトウェアによってこのSPDX Documentそのものが作成されることも想定されています。最終的な確認は人の手によって行う必要がありますが、近年の複雑化しているソフトウェア開発において自動でSBOMを生成、取得できるというのであれば、非常にありがたいことです（残念ながら現段階では「SBOM生成するならコレ！」といった立ち位置のソフトウェアはまだ存在しないようですが）。

また、デファクトスタンダードとして仕様が広まれば広まるほど、お互いの情報交換がしやすくなるというメリットがあります。この状況の実現をめざしSPDXプロジェクトがこのSPDX Specの普及に尽力してきた結果、国際標準としての地位を得ることとなりました。

対象スコープ

SPDX Documentは作成時点のソフトウェアパッケージにおけるSBOMです。あくまでファイルの作成時点なので、この文書は基本的に作成された当時のソフトウェアパッケージについての情報のみを保持しています。逆に、一度作ったSPDX Documentを作成した後、時間が経ってからそれを編集することは想定されておらず、編集履歴を記録することを前提とした属性は存在しません。したがって、SPDX DocumentをSBOMとして使用していく際は、都度必要性が生じる（例：バージョンアップして構成が変更された）たびにSPDX Documentを生成して保管するという運用になります。

構造

この文書がどのように構成されているかを見ていきましょう。細かく見てしまうと筆者側は仕様の日本語訳をした上に大量の注釈をつけることになり、読む側の労力もあまりに大きくなるので、今回はざっくり解説するに留め、あくまでSPDX Documentがどのように構成されているのかを把握することをを目標にしたいと思います。

SPDX Documentは、セクションという関連する属性のまとまりで構成されています。公式ではイメージとして、以下のような図が提示されています。

SPDX Specをある程度読み込むと図の意味は理解できるのですが、個人的にはこの図で構造をイメージするのは難しいと思いましたので、より構造的に解釈した図を以下のとおり用意しました。こちらの図を理解していただくことが今回のゴールになります。

この図は公式イメージ図に対し、以下のような点を意識して作成しました。

• Annotationは他のセクションに付随する形を取っている。
• Relationshipは一方向の矢印（何かを示す文字列付き）、他のセクションを結び付けている。
• Other Licensing Informationの矢印はRelationshipと異なる。Package Informationにしか伸びていない。

上記は、SPDX Specificationについて理解していくことでこうした形での解釈、表現ができることに納得していただけるかと思います。

それではなぜこのような解釈となるのか、これから各セクションが持つ情報や役割とともに説明していきます。

セクションのうち、以下のセクションは実際のディレクトリだったり、ファイルやスニペットに対応しています。したがって、他のセクションに関係なく独立して存在することができます。

• SPDX Document Creation Information
• Package Information
• File Information
• Snippet Information

また、これらは実際のディレクトリ、ファイルやスニペットに関する以下の情報を持ちます。

対して残る3つのセクションは、上記4つのセクションのインスタンスの存在を前提として存在するようになっています。その中でも、SPDX Documentの構造を理解するうえで一番重要なのが次のセクションになります。

残る2つは、これまで説明したセクションのインスタンスに対し情報を補完するセクションとなります。SPDX Documentによっては存在しない場合もあり、またインスタンスに対する関係性も決まっているのでRelationshipsのインスタンスで関係性を示す必要もありません。

これですべてのセクションの役割について説明が終わりました。ここでゴールとして提示した画像を再度確認してください。

これまで説明してきた通り、図では複数の「Package Informationが存在」していたり、「Annotationは他のセクションに付随」していたり、「Relationshipがインスタンス同士を結び付けて」います。

SPDX Documentの構造イメージがこのように表現できることがお分かりいただけたでしょうか？

SPDX Documentとして成立するには

では最後に、何をもってファイルがSPDX Documentであると判断するのかについて説明します。SPDX Documentとしての成立性を確認したい場合は、SPDXプロジェクトが提供しているOSS、spdx-toolsを使用します。このspdx-toolsのVerifyというコマンドが構造のところで説明した規則のすべてを機械的に確認してくれるので、人力で確認する必要はありません。

このあたりで「よし、それでは早速SPDX Documentを作ろう！」という気持ちになった方がいらっしゃいましたら、この記事を書いた身としては非常にうれしい限りなのですが、現状では作成するにあたって考慮すべき点があることを喚起しておきます。

そもそも、昨今新しく開発したソフトウェアパッケージにはさまざまなOSSソフトウェア、コンポーネントが含まれていることがほとんどです。つまり、これに対応したSPDX Documentを作成しようとするとそれなりの数のPackage、File、Snippetと大量のRelationships（そして場合によってはAnnotationとOther Licensing Information）を記述しなければならなくなる場合がほとんどだと思います。したがって、手作業でSPDX Documentを作成するのは現実的ではありません。 しかしながら、冒頭で述べたようにSPDX Documentを自動生成できるスキャンツールとしてデファクトスタンダードにあたるものは、残念ながらまだ存在しません（仕様を普及している段階なので当然と言えば当然ではありますが）。SPDXを扱えるツール自体はいくつか存在しますが、どれもまだ発展途上といった状態です。こういったSPDXを取り巻く状況はしっかり踏まえたうえで検討した方がよいでしょう。

参考として、いくつかSPDXに関連したOSSのリンクを貼っておきます。もしSPDX Documentの運用を検討されている場合は、こちらについても調査してみるとよいかと思います。

• FOSSOlogy
• SW360

（これらの詳細はこれまた長くなるので割愛します。）

まとめ

• SPDXとはSPDXプロジェクトが策定しているSPDX Specificationのことであり、SPDX Documentとはそれにしたがって記述された文書ファイルのことを指す。
• SPDX Documentはあるソフトウェアパッケージに対するSBOMであり、ソフトウェアパッケージに関する包括的な情報を記載した文書である。単なる情報を集約した文書ではなく、ソフトウェアによる操作を前提としている。
• 手作業で作成する場合はより簡略化されたSPDX-Liteというフォーマットも存在する。

終わりに

いかがでしたでしょうか？自分がSPDXについて調査したとき、まったく分からない状態で参照するのに適した情報源がなかったので、それならばと思い書いてみました。この記事が何かの一助になりましたら幸いです。

参考

• SPDX Becomes Internationally Recognized Standard for Software Bill of Materials
• SPDX.dev
• SPDX Specification
• SPDX Examples
• SPDX Specification v2.1 非公式日本語訳
• spdx-tools