SPDXかCycloneDXか、提出と脆弱性対応で正解が変わる

SPDXとCycloneDXのどちらでSBOMを作るかは、提出先の指定を先に確認し、その後で社内の用途を決める。指定がなければ、ライセンスの説明を重視する場合はSPDX、依存関係をたどる脆弱性対応を重視する場合はCycloneDXが有力だ。JPCERT/CCの講演資料も、両者の一般的な強みをそう整理しつつ、組織の事情に沿った選択や両形式の出力を挙げている。

この区別は、片方の規格ではもう片方の用途を扱えないという意味ではない。実際の選択を左右するのは、必要な項目を使う仕様の版で表現できるか、生成ツールがその項目を埋めるか、受け手のツールが読み取れるかだ。社内で管理する形式と取引先に渡す形式を分ける選択もある。

提出先の指定は、社内の好みより先に置く

発注者や納入先が形式を指定しているなら、それが提出物を決める最初の条件になる。SPDXかCycloneDXかだけでなく、受け付ける仕様の版、JSONなどのファイル形式、対象とする製品の範囲、必須項目まで確認したい。同じ規格名が指定されていても、版や必須項目が合わなければ、そのまま提出できるとは限らない。

要求が単に「SBOMを提出すること」なら、受け手の利用目的が次の判断材料になる。ライセンスや著作権表示を確認するための提出物と、脆弱性情報を受けて影響製品を探すための提出物では、必要な情報が異なる。部品名と版だけを並べたファイルでは、後者に必要な依存関係や部品の識別情報が足りない場合がある。

提出先が複数あり、指定も分かれるなら、外部向けの形式を一つに統一する必要はない。たとえば一方にはSPDX、もう一方にはCycloneDXを渡す運用は可能だ。ただし、それぞれを独立した台帳として更新すると、同じ製品版に対して部品の記載が食い違う。提出形式を増やす前に、共通して使う部品情報の収集元を決めておくほうがよい。

ライセンス説明を重視するなら、判断の根拠まで見る

ライセンス管理では、部品にライセンス名が付いているだけでは足りないことがある。配布時にどの条件が適用されると判断したか、複数のライセンスから選べるのか、例外や著作権表示をどう扱うかが、社内確認と取引先への説明につながる。SPDXを候補にする理由は、こうした情報を整理する用途との親和性にある。

SPDXの公式仕様一覧は、この規格をISO/IEC 5962:2021の国際標準と記し、3.0と過去の版を掲載している。標準化されていることと、提出先が任意の版や項目を取り込めることは別だ。ライセンス説明に使うなら、提出先が求める版に加え、自社のツールが判断結果や著作権情報をどこまで出力するかを確かめる必要がある。

確認したいのは、規格に欄があるかだけではない。自動検出したライセンス情報と人が確認した判断を区別して管理するのか、調査中の部品をどう示すのかによって、必要な記録は変わる。SBOMを更新した後も同じ判断を追えるよう、部品の識別情報と確認結果を結び付けておきたい。

CycloneDXにも、コンポーネントのライセンスや著作権を記載する仕組みがある。そのため、ライセンスを扱うという理由だけでSPDXを必須と決める必要はない。取引先が求める表現を、実際に使う生成ツールと受け取り側のツールで維持できるかが、最終的な判断になる。

脆弱性対応では、部品の一覧より関係が重要になる

脆弱性への対応を主目的にするなら、影響を受ける部品が製品のどこに入っているかをたどれることが重要だ。CycloneDXの仕様概要は、コンポーネントとサービス、直接・間接の依存関係、脆弱性情報を表現できると説明している。部品が別の部品を通じて取り込まれている場合にも、依存関係が記録されていれば調査の手掛かりになる。

たとえば特定のライブラリに脆弱性情報が出たとき、部品名だけの一覧では、どの製品版に含まれるか、直接使っているか、別の部品に伴って入ったかを判断しにくい。部品の版と識別子、依存関係がそろっていれば、調べる対象を絞りやすい。ただし、規格が依存関係を表現できても、生成時に収集していなければ出力には現れない。

CycloneDXはライセンス情報も扱い、ソフトウェアの部品表に加えて暗号資産や運用構成などを対象とするBOMも表現できる。これらが必要な組織には検討材料になる一方、通常のSBOM提出でその機能をすべて使う必要はない。対象を広げるかどうかも、受け手が必要とする情報に合わせて決める。

SPDXを選んでも、脆弱性情報を扱えなくなるわけではない。SPDX仕様の適合要件には、脆弱性の深刻度、ソフトウェア要素への影響、修正の有無を表すSecurity Profileがある。ただし、Core Profile以外は任意であり、SPDX形式のファイルなら必ずその情報が入っているとはいえない。脆弱性対応に使う場合は、採用する版とツールが必要なプロファイルや関係情報を扱えるかを見たい。

社内の正本と外部出力を分けて設計する

複数形式を使うなら、最初に決めるべきなのは、どの情報を社内の正本とするかだ。正本はSPDXまたはCycloneDXのファイルでも、依存関係の収集結果とライセンスの確認記録を管理する別の仕組みでもよい。大切なのは、部品の変更や判断の修正があったとき、どこを直せば各出力に反映されるかが明確なことだ。

社内の脆弱性対応にはCycloneDXを使い、顧客提出にはSPDXが必要、という条件付きの例を考える。この場合、両方のSBOMが同じ製品と版を指し、共通する部品名、版、識別子に矛盾がないことが前提になる。ライセンスの判断結果を別に管理するなら、その記録がどの部品を指すかも結び付けておく必要がある。

反対に、社内の主な作業がライセンス確認で、取引先の一部がCycloneDXを要求する場合もある。そのときはSPDXで管理している情報を外部出力へ移せるかに加え、受け手が求める依存関係を元の収集工程で確保しているかが問題になる。形式を変えても、収集していない情報は増えない。

正本を決める際には、生成のタイミングもそろえたい。開発中の依存関係から作ったSBOMと、配布する製品から作ったSBOMでは、対象が異なる場合がある。どの製品版の、どの時点の構成を示すのかを管理しておけば、提出物と社内の影響調査を同じ対象に結び付けられる。

両形式を出すなら、変換後の意味を照合する

一方の形式からもう一方へ変換する方法はあるが、変換できたことだけでは情報の維持を保証しない。CycloneDX CLIの説明は、SPDXとCycloneDXの変換で一部の情報が失われ得ると明記している。変換後のファイルを開けるかどうかに加え、提出や運用に必要な項目が残ったかを確認する必要がある。

照合する項目は用途から決める。共通の部品名、版、識別子に加え、脆弱性対応に使うなら依存関係と影響を受ける部品への関連付けを見る。ライセンス説明に使うなら、条件の組み合わせ、例外、著作権表示、確認済みの判断結果が出力先でも区別できるかが重要になる。件数が一致していても、こうした関係や判断が消えていれば同じ用途には使えない。

また、変換元と変換先で仕様の版を指定し、提出先がその版を受け付けるかを確かめたい。変換ツールが対応する版と、規格そのものが公開している版は一致するとは限らない。必要な項目が変換で欠けるなら、変換結果を正本にせず、共通の収集元からそれぞれの形式を出力する構成を選べる。

選択の順序は、提出先の条件、社内で重視するライセンス説明または脆弱性対応、正本にする情報、外部出力で維持すべき項目となる。この順で決めれば、形式の一般的な強みを生かしながら、受け手が使えるSBOMと社内で更新し続けられる情報を両立できる。

関連記事：

• インボイス登録で手取りはどう変わる？個人クリエイターの判断軸
• SmartHRかfreee人事労務か、給与計算の内製で選択が変わる
• Gemini 3.8 Liveは会話中も推論、実装では「終了」の判定が変わる