ソフトウェア部品表 (SBOM) は、ソフトウェア アプリケーションで使用されるすべてのコンポーネント、ライブラリ、およびその他の依存関係のリストです。 SBOM の標準形式には、SPDX、CycloneDX、CPE (Common Platform Enumeration) などがあります。これらの形式は、ソフトウェア アプリケーション内のコンポーネントと依存関係を表す構造化された方法を提供し、それらのコンポーネントに関連するセキュリティ リスクの理解と管理を容易にします。
この記事では、さまざまな SBOM の形式と標準とは何か、SBOM に何を含めるべきか、そしてすべての組織が SBOM を使用する必要がある理由について詳しく説明します。
SBOM規格とは何ですか?
現代のソフトウェア システムのサプライ チェーンの複雑さと動的な性質は、透明性に対して重大な課題を引き起こしています。この透明性の欠如はサイバーセキュリティのリスクの一因となり、開発、調達、保守に関連するコストを増加させます。この影響は広範囲に及び、企業だけでなく、相互につながった世界における公共の安全や国家安全保障といった集団的な問題にも影響を及ぼします。
ソフトウェア サプライ チェーンの透明性が高まると、次のようなサイバーセキュリティのリスクとコストの削減につながります。
- 脆弱なシステムの特定を改善し、インシデントの根本原因を特定する
- 計画外で非生産的な仕事の減少
- より多くの情報に基づいた市場の差別化とコンポーネントの選択が可能になります
- 複数の分野にわたるフォーマットの標準化により、重複した作業の削減につながります
- 疑わしいまたは偽造されたソフトウェア コンポーネントの検出
この情報を明確で一貫した形式で収集して共有することで、コストを削減し、信頼性を向上させ、デジタル インフラストラクチャに対する信頼を高めることができます。
その目的のために、 標準とフォーマットに関する NTIA ソフトウェア透明性ワーキング グループ ソフトウェア部品表の現在の形式を評価し、将来の用途を特定するために 2018 年に設立されました。このグループは、ソフトウェア製品で使用される外部コンポーネントと共有ライブラリの特定と、この情報を機械可読形式で伝達することに関連する既存の標準と取り組みを調査しました。このグループは独自のフォーマットを考慮していませんでした。元の調査は 2019 年末に発表され、2021 年に更新されました。この調査は、SBOM ツール エコシステムの利点と、技術的な SBOM の世界における調整と調和の重要性を強調することに重点を置いています。重要な点は、SBOM データはさまざまな形式で伝達でき、エコシステムはそれらの間の相互運用性をサポートする必要があるということです。
作業グループは、次の 3 つの形式が一般的に使用されていることを発見しました。
- Software Package Data Exchange (SPDX®)、Linux Foundation によって開発され、現在 ISO/IEC 標準となっているオープンソースの機械可読形式
- CycloneDX (CDX)、OWASP コミュニティによって開発されたオープンソースの機械可読形式
- ソフトウェア識別 (SWID)、さまざまな商用ソフトウェア発行元が使用する ISO/IEC 業界標準
これら 3 つの形式はいくつかの共通情報を共有していることに注意してください。ただし、これらは従来、ソフトウェア開発プロセスのさまざまな段階で使用されており、さまざまな対象者を対象としています。この記事では、これらの各形式について詳しく説明します。
SBOM には何を含めるべきですか?
NTIA の最小コンポーネント 要素と呼ばれる SBOM の要素は、相互に関連する 3 つの広範な領域で構成されます。これらの要素により、ソフトウェアの透明性に対する柔軟なアプローチが可能になり、テクノロジーと機能操作の両方に対応できます。将来的には、さらなる詳細や技術的進歩が追加される可能性があります。前述したように、これらは現時点での最小コンポーネントであり、組織によってはさらに多くのコンポーネントが必要になる場合があります。ソフトウェア サプライ チェーンの透明性の能力は、時間の経過とともに向上し、進化する可能性があります。
ボーマン SBOM に最低限必要な要素 通常、次の 3 つのカテゴリに分類されます。
- データ フィールド: SBOM には、コンポーネント名、サプライヤー名、バージョン、一意の識別子など、ソフトウェア コンポーネントに関する重要なデータが含まれている必要があります。また、サプライ チェーン全体にわたるすべてのソフトウェア コンポーネントの正確な識別と追跡を可能にする、コンポーネント間の依存関係に関する情報も含める必要があります。
- 実践とプロセス: SBOM ドキュメントには、SBOM の作成と更新、配布とアクセス、エラーの処理に関する標準的な実践方法と手順の概要も記載されている必要があります。
- 自動化のサポート: ソフトウェア部品表は、機械で読み取り可能であり、データを継続的に追跡するために自動的に生成できる必要があります。通常、SPDX、CycloneDX、SWID タグなどの標準形式であり、人間が読み取れるようになります。
SPDX SBOM 標準フォーマット
SPDX® (Software Package Data Exchange) 仕様は、ソフトウェア コンポーネント、ライセンス、著作権、セキュリティの詳細に関する情報を複数のファイル形式で共有するための ISO/IEC 標準です。このプロジェクトは、企業や組織が人間と機械の両方が理解できる形式でソフトウェア メタデータを共有できるようにする一連のデータ交換標準を開発し、改善を続け、ソフトウェア サプライ チェーン プロセスを簡素化しました。
SPDX 情報は、特定のソフトウェア製品、コンポーネントまたはコンポーネントのセット、個々のファイル、さらには小さなコード スニペットにリンクできます。 SPDX プロジェクトは、SBOM の一部として交換できるデータを記述する言語の作成と改良、およびこのデータを複数のファイル形式 (RDF/XML、XLSX、タグ値、JSON、YAML) で表示する機能に焦点を当てています。 、XML) を使用して、ソフトウェア パッケージおよび関連コンテンツに関する情報の収集と共有が容易になり、時間と精度が向上します。
SPDX 仕様では、有効なドキュメントに必要なフィールドとセクションの概要が説明されていますが、すべてのセクションが必須であるわけではなく、作成情報セクションのみが必須であることに注意することが重要です。ドキュメント作成者は、共有する予定のソフトウェアおよびメタデータ情報を説明するセクションとフィールドを選択できます。
SPDX は、ソフトウェアの開発と展開に含まれるすべてのコンポーネントを表すことにより、ソフトウェア部品表データを効果的に取得できます。これは、ディストリビューション .iso イメージ、コンテナー、ソフトウェア パッケージ、バイナリ ファイル、ソース ファイル、パッチ、さらには他のファイルに埋め込まれた小さなコード スニペットを文書化するために使用されます。 SPDX は、ドキュメント内および SBOM ドキュメント間でソフトウェア要素を接続するための包括的な関係セットを提供します。 SPDX SBOM ドキュメントは、National Vulnerability Database やその他のパッケージング システムのメタデータなどの外部ソースを参照することもできます。
SPDX ドキュメントを構成するコンポーネントはいくつかあります。作成情報、パッケージ情報、ファイル情報、スニペット情報、その他のライセンス情報、関係、および注釈です。
各 SPDX ドキュメントは完全なデータ モデル実装と識別子構文で表すことができ、異なるデータ出力形式 (RDF/XML、タグ値、XLSX) 間の交換とドキュメントの精度の正式な検証が可能になります。 SPDX 仕様のバージョン 2.2 リリースには、JSON、YAML、XML などの追加の出力形式が含まれており、元の SBOM 文書で特定されている「既知の未知のもの」にも対応しています。 SPDX の基礎となるデータ モデルの詳細については、SPDX 仕様の付録 III および SPDX Web サイトを参照してください。
CycloneDX SBOM標準フォーマット
CycloneDX プロジェクトは、完全に自動化された、セキュリティに重点を置いた SBOM 標準の開発を目的として 2017 年に設立されました。コアワーキンググループは、リスクベースの標準プロセスを使用して、不変で下位互換性のあるバージョンを毎年リリースします。 CycloneDX には、パッケージ URL、CPE、SWID、SPDX のライセンス ID と式などの既存の仕様が含まれています。 SBOM は、XML、JSON、プロトコル バッファー (protobuf) などのさまざまな形式で表現できます。
CycloneDX は、サプライ チェーンのコンポーネント分析とソフトウェア セキュリティでの使用を目的とした軽量の SBOM 仕様です。これにより、ソフトウェア コンポーネント インベントリ、外部サービス、およびそれらの間の関係の通信が可能になります。これは、OWASP (Open Web Application Security Project) によって開発されたオープンソース標準です。
CycloneDX は、ソース コードがアクセス可能、変更可能、再配布可能なオープンソース コンポーネントの動的な性質をキャプチャできます。仕様は、祖先、子孫、バリアントを含むコンポーネントの系統を表すことができ、あらゆる観点からコンポーネントの系統を記述するだけでなく、コンポーネントを一意にするコミット、パッチ、差分も記述します。
CycloneDX プロジェクトは、コミュニティによってサポートされている標準をサポートまたは互換性のある既知のオープンソースおよび独自のツールのリストを管理しています。
CycloneDX 仕様では、すべての実装間での一貫性を保証する詳細なオブジェクト モデルが規定されています。 XML スキーマと JSON スキーマを使用するか、CycloneDX コマンドライン インターフェイスを使用して検証できます。 XML および JSON のメディア タイプも、サポートされている形式の自動配信と利用のために提供されています。
CycloneDX SBOM には、BOM メタデータ、コンポーネント、サービス、依存関係、構成、および拡張機能の情報が含まれる場合があります。
CycloneDX は、アプリケーション、コンポーネント、サービス、ファームウェア、デバイスなどのさまざまな種類のソフトウェアを特徴付けることができる包括的な SBOM 標準です。ソフトウェア パッケージ、ライブラリ、フレームワーク、アプリケーション、コンテナ イメージを記述するために業界全体で広く使用されています。このプロジェクトは主要な開発エコシステムと互換性があり、GitHub アクションのようなソフトウェア ファクトリの実装を提供し、組織が SBOM 作成を完全に自動化できるようにします。
SWIDタグ
SWID タグ (ソフトウェア識別タグ) は、組織が管理対象デバイスにインストールされているソフトウェアを透過的な方法で追跡できるようにするために作成されました。この規格は 2012 年に ISO によって制定され、19770 年に ISO/IEC 2-2015:2015 として改訂されました。これらのタグには、ソフトウェア製品の特定のリリースに関する詳細情報が含まれています。
SWID 標準は、ソフトウェア追跡のライフサイクルの概要を示しています。SWID タグは、ソフトウェア製品のインストール中にエンドポイントに追加され、製品のアンインストール プロセスによって削除されます。特定の SWID タグの存在は、それが説明するソフトウェアの存在に直接対応します。 Trusted Computing Group (TCG) や Internet Engineering Task Force (IETF) などの複数の標準化組織は、標準に SWID タグを組み込んでいます。
ソフトウェア コンポーネントのライフサイクルを追跡するために、SWID 仕様にはプライマリ、パッチ、コーパス、補足の 4 種類のタグがあります。コーパス、プライマリ、パッチ タグは、ソフトウェア インストーラー、ソフトウェア インストール、ソフトウェア パッチなどのさまざまな種類のソフトウェアの存在と存在、およびソフトウェア製品の可能な状態を記述するという点で同様の目的を果たします。一方、補足タグは、コーパス、プライマリ、またはパッチ タグにはない追加の詳細を提供します。
補足タグを他のタグにリンクして、役立つ可能性のある追加のメタデータを提供できます。 SWID タグを組み合わせると、ソフトウェア検出、構成管理、脆弱性管理などのさまざまな機能を実行できます。
SWID タグは、ソフトウェア コンポーネントの識別情報、コンポーネントのアーティファクトのファイルと暗号化ハッシュのリスト、SBOM (タグ) 作成者とソフトウェア コンポーネント作成者に関する来歴情報を提供するため、SBOM として機能できます。タグは他のタグにリンクすることもでき、依存関係ツリーの表現が可能になります。
SWID タグはビルドおよびパッケージ化のプロセス中に生成でき、対応するソフトウェア コンポーネントをパッケージ化するときに SWID タグベースの SBOM を自動作成できます。
ソフトウェア部品表はなぜ重要ですか?
ソフトウェア部品表 (SBOM) は、使用するソフトウェアの管理とセキュリティ保護を目的とする組織にとって、ますます重要になっています。という質問に対する簡単な答えはありません SBOMとは何ですか。 SBOM は、バージョン番号、作成者、ライセンス情報などの情報を含む、ソフトウェア パッケージを構成するすべてのコンポーネントと依存関係の包括的なリストを提供します。この情報は、セキュリティとコンプライアンスにとって重要であるだけでなく、ソフトウェア コンポーネントの出所を追跡するためにも重要です。
規制対象業界を含む多くの組織は、一般データ保護規則 (GDPR) やペイメント カード業界データ セキュリティ基準 (PCI DSS) などの規制への準拠を確保するために SBOM を使用しています。 SBOM は、ソフトウェアの脆弱性の特定と管理、およびソフトウェア コンポーネントの出所の追跡にも役立ちます。さらに、SBOM はソフトウェア ライセンスの管理を支援し、組織がライセンスの条件に従ってソフトウェアを使用していることを確認します。
SBOM は、ソフトウェア開発においてますます一般的になりつつあるオープンソース ソフトウェアの使用状況を追跡するためにも使用できます。 SBOM は、ソフトウェア パッケージで使用されているオープンソース コンポーネントに関する詳細情報を提供することで、組織がオープンソース ライセンスに準拠していることを確認するのに役立ちます。
さらに、SBOM を使用してソフトウェアの開発と保守をサポートできます。 SBOM は、ソフトウェア パッケージで使用されているコンポーネントに関する詳細情報を提供することで、開発者がソフトウェア パッケージの依存関係を理解するのに役立ち、潜在的な互換性の問題を特定し、新しいコンポーネントの使用について情報に基づいた決定を下すのに役立ちます。