CycloneDXとは？
SPDXとの違いを知りどちらを作成すべきか理解しよう

「CycloneDXとはどんなものなのか」

そんな疑問を持つ方に当記事ではCycloneDXの基本事項や作成方法、SPDXとの違いを解説します。CycloneDXはSBOMのフォーマットのうち、セキュリティ面の管理に特化しているという特徴があります。当記事を読んで、CycloneDXとSPDXの違いを理解し、適切なフォーマットを選択しましょう。

CycloneDXとは?

CycloneDXはソフトウェア開発時に、構成情報として用いられるドキュメント（SBOM）などで利用されるフォーマットです。SBOM（Software Bill of Materials）には複数のフォーマットが用意されていますが、ここではCycloneDXが持つ特徴や、登場した背景を解説します。

CycloneDXの概要

CycloneDXはソフトウェアの構成情報を管理するためのフォーマットです。 SBOMをはじめ、複数のドキュメントで利用されています。ソフトウェアの依存関係や、脆弱性を管理できるため、ソフトウェアの連携による管理の煩雑さから解放されます。

現代のソフトウェアは複数のソフトウェアが組み合わさって開発されることが一般的です。ソフトウェア同士の連携により、依存関係や脆弱性への対処が難しくなりますが、CycloneDXでこれらを管理すると原因の特定やトラブル時の対応がしやすくなります。

SBOMのフォーマット

CycloneDXは主に、SBOMで利用されますが、SBOMでは主に以下3つのフォーマットが利用されます。

上記のうちCycloneDXはセキュリティ面の情報管理に特化しているフォーマットです。

SBOMには主に下記の情報が含まれます。

CycloneDXの場合、上記のうち依存関係情報や、上記以外のソフトウェアの脆弱性情報が詳しく記載されます。

SBOMについては別記事で解説しているので、あわせてご覧ください。

CycloneDXが登場した背景

CycloneDXが登場した背景には、ソフトウェア管理におけるセキュリティリスクの増大があります。OWASP Dependency-Trackで使用するために2017年に登場したフォーマットです。

Dependency-Trackはコンポーネント分析プラットフォームで、ソフトウェアの脆弱性を特定し、リスク低減をする機能を持ちます。分析をするにあたり、ソフトウェア間の依存関係や脆弱性を管理できる統一されたフォーマットが必要だったため、CycloneDXが登場しました。

ソフトウェアの数が増えるほど、依存関係や脆弱性が増え、管理が難しくなります。難しくなる管理をDependency-Trackで簡略化するにあたり、フォーマットが必要になった、という流れです。

CycloneDXが利用されるドキュメント

CycloneDXは主にSBOMで利用されるフォーマットですが、SBOM以外のドキュメントでも利用されます。利用されるドキュメントは以下の通りです。

CycloneDXとSPDXの違い

CycloneDXはSBOMのフォーマットの一種です。SBOMによく利用されるもう1つのフォーマットとしてSPDX（System Package Data Exchange ）があります。

SPDXはLinux Foundationという機関のSPDX Workgroupというグループが開発したフォーマットです。よく比較される両者ですが、具体的にどのような違いがあるのか、下記の観点で比較してみましょう。

なおSPDXの簡易版として作成されるSPDX Liteについては別記事でまとめているので、あわせてご覧ください。

作成目的の違い

両者は作成目的が異なるフォーマットです。CycloneDXはセキュリティに特化した内容のSBOMフォーマットという特徴があります。一方でSPDXはライセンス管理やコンプライアンス管理がしやすくなることが特徴のSBOMフォーマットです。

CycloneDXは、コンポーネントの脆弱性や依存関係の管理をする際に優れたフォーマットになっています。これらを詳細に記載することで、リスク評価を効率よく行うことが目的です。

一方で、SPDXはライセンス情報やコンプライアンス情報の内容が詳細化されています。これらが詳細化されることで、ライセンス違反や著作権の問題をクリアにすることが目的です。

作成方法の違い

両者は作成方法にも違いがあります。どちらも手動、自動化ツールを用いた作成のどちらにも対応していますが、自動化ツールの場合は用いるツールが大きく異なります。

CycloneDXを自動化ツールで作成する場合、基本的に脆弱性スキャンツールの一機能で作成できることが多いです。情報を確認したいソフトウェアをスキャンし、レポートを出力することで作成できます。

一方でSPDXはソフトウェアのソースコードをスキャンして、ライセンス情報を抽出できる自動化ツールを用いて作成します。

またSPDXには簡易版のSPDX Liteが用意されています。SPDX LiteはSPDXのうち、必要最低限な情報のみを記載するフォーマットです。小規模なプロジェクトや、厳密でない要件の開発であればSPDX Liteの作成で十分というケースがあります。Liteの方であれば手動でも対応できることが多いです。

内容の違い

両者は作成目的の違いから、内容も異なります。CycloneDXは脆弱性の情報、SPDXはライセンス情報が詳細に記載されていることが大きな違いです。

CycloneDXの内容は主に以下があります。

特に脆弱性について下記の情報が記載され、脆弱性の内容が詳細化されていることが特徴です。

一方でSPDXに記載される情報には以下があります。

ライセンス情報には以下が含まれます。

ユースケースの違い

両者はユースケースも異なります。

CycloneDXは脆弱性情報を筆頭にセキュリティの管理に特化したドキュメントです。よってサイバーセキュリティ関連のプロジェクトで用いられることが多くなります。

一方でSPDXはライセンスやコンプライアンスの管理に特化しているドキュメントです。ソフトウェア開発だけでなく、ソフトウェアを開発する企業を評価するために用いられるケースもあります。

CycloneDXの作成

CycloneDXを作成するために知っておくべき、以下の情報を確認しておきましょう。

CycloneDXのフォーマット

CycloneDXは以下のいずれかのファイル形式です。

書き慣れている、あるいは読み慣れているフォーマットを利用すれば問題ありません。ただし、ステークホルダが確認しやすくするためにはコミュニケーションを取り合い、どれを選択すべきか確認しておきましょう。

基本的にはフォーマットでCycloneDXを作成していくことになるため、最初の決定が重要です。

CycloneDXに含まれる内容

CycloneDXに含まれる内容として以下があります。

Metadata

SBOM自体のメタデータで、提供者や開発者、作成時に使用したツールなどの情報を示します。

Components

開発したソフトウェアに含まれるソフトウェアコンポーネントです。含まれている全てのソフトウェアを把握する必要があります。

Services

開発したソフトウェアが呼び出す可能性がある外部サービスAPIの情報を記載します。

Dependencies

ソフトウェアコンポーネント同士の依存関係です。記載があることで、依存関係があるコンポーネントに脆弱性が発生した場合に、迅速に対応しやすくなります。

Compositions

ソフトウェアコンポーネントやサービスの依存関係を踏まえた構成要素と、それらの完全性（ここでは依存関係が明確に把握されている状態）を示します。

Vulnerabilities

コンポーネントの脆弱性情報です。脆弱性情報の記載があることで、どのように対応すべきか、予測や検出方法が分かります。また脆弱性が悪用される可能性も記載します。

Formulation

開発されたソフトウェアが、どのようにテストをされたのかについての情報です。

Annotations

コメントや注釈などの追加情報です。

Extensions

拡張情報のことです。CycloneDXのフォーマットには記載されない情報を追加する際に記載する項目になります。

CycloneDXの作成方法

CycloneDXの作成方法は以下のどちらかになります。

CycloneDXを含むSBOMの作成は手動で可能ですが、コンポーネント数が多いほど作業負担が大きくなるため、現実的ではないことが多いです。よって後者の自動化ツールによる作成が主流となります。例として以下がCycloneDX作成に対応しているSBOM作成の自動化ツールです。

上記は脆弱性スキャンツールですが、一機能としてCycloneDX（SBOM）の作成ができます。

CycloneDXとSPDX、SPDX Liteのどれを作成すべきか

CycloneDXとSPDXはそれぞれSBOMのフォーマットであり、よく比較されるため、どちらを作成すべきか迷う場面が出てくるでしょう。またSPDXには簡易版のSPDX Liteも用意されています。それぞれを作成すべきケースを解説します。

CycloneDXを作成すべきケース

CycloneDXを作成すべきケースの例として以下があります。

DevSecOpsは開発プロセスに利用するケースです。開発プロセスの中にセキュリティを組み込む必要があります。またサプライチェーンセキュリティ管理や脆弱性管理プラットフォームでは、すでに提供済みのソフトウェアのセキュリティを管理するケースです。

SPDXを作成すべきケース

SPDXを作成すべきケースの例として以下があります。

SPDXは大規模なソフトウェア開発や、ライセンス、コンプライアンスの管理をする際に利用されるドキュメントです。また開発した製品が企業の評価につながるケースもあります。

SPDX Liteを作成すべきケース

SPDX Liteを作成すべきケースは小規模なプロジェクトのケースです。

CycloneDXのように詳細なセキュリティ関連の情報や、SPDXのような詳細なライセンス情報が不要な場合にSPDX Liteを利用します。特にSPDXは大規模プロジェクトやコンプライアンスが厳しいプロジェクトに用いられますが、SPDX Liteは厳密なルールが求められないケースで利用可能です。

CycloneDXやSPDXは不要でも、SBOMを作成しておきたいケースにSPDX Liteを作成しましょう。

まとめ

CycloneDXはSBOMなどのフォーマットのうち、セキュリティ関連の情報を詳細化したものです。SPDXと対比されることが多いですが、それぞれ異なる特徴を持つため場面ごとに使い分けましょう。

SBOMの作成は手動でやるにはハードルが高い作業です。開発や運用に時間をかけるべきで、作成にはあまりコストを割きたくない企業が多いでしょう。Labrador Labsは分かりやすいインタフェースかつ、低コストで利用できるSBOM対策ツールです。

SBOM関連でお困りの企業の担当者は下記リンクからお問い合わせください。