この時代に安全なソフトウェア製品やアプリケーションを構築するには、構築しているアプリケーションの正確なコンポーネントについての完全な知識が必要です。ソフトウェア パッケージを構成する依存関係、ライセンス、ファイル、その他の資産は潜在的な脆弱性ポイントとなり、悪意のある攻撃者がソフトウェアやサプライ チェーン上の他のアプリケーションに対して攻撃を開始できる可能性があります。
最近の頻度と影響の増加に対処する取り組みの一環として、 ソフトウェアサプライチェーンへの攻撃、連邦政府はNTIAと連携して、サイバーセキュリティを向上させ、ソフトウェアパッケージで使用されるサードパーティコンポーネントの完全性を保証するためのさまざまな措置を詳述する大統領令を発行しました。そのような対策の 1 つが、 ソフトウェア部品表。
これは、ソフトウェア パッケージのすべてのコンポーネントと、これらのコンポーネント間のサプライ チェーンの関係を含む正式な文書です。包括的なソフトウェア部品表の作成は標準的な慣行であるだけでなく、法律でも義務付けられています。この投稿では、ソフトウェア部品表の範囲を定義します。 最小限の要素 それは包括的な部品表に含める必要があります。
NTIA の SBOM の最小コンポーネントは何を提供しますか?
SBOM は、ソフトウェアを構築、購入、または運用する企業向けの正式なガイドとして機能し、ソフトウェア サプライ チェーンの理解を深めるために必要なすべての情報を提供します。また、新たな脆弱性が発生した場合にそれを簡単に追跡するのにも役立ちます。 ソフトウェアサプライチェーンのリスクを軽減する。ただし、SBOM が連邦政府の規定された要件を満たすためには、SBOM に含めるべき基本的な要素がいくつかあります。これらの要素は、多くの場合、次の 3 つのカテゴリに分類されます。
- データ フィールド: SBOM は、コンポーネントの名前、サプライヤーの名前、ソフトウェアのバージョン、その他の一意の識別子など、ソフトウェア コンポーネントに関する重要なデータを提供することが期待されています。また、依存関係間の関係についても詳しく説明する必要があります。このデータにより、すべてのソフトウェア コンポーネントを正確に識別し、ソフトウェア サプライ チェーン全体で追跡することが可能になります。
- 自動化のサポート: ソフトウェア部品表は機械可読であり、自動生成もできる必要があります。これにより、SBOM に含まれるデータの継続的な追跡が可能になります。通常、これらのドキュメントは SPDX、CycloneDX、SWID タグなどの標準形式であるため、人間が判読できるようになります。
- 実践とプロセス: SBOM の文書には、SBOM を準備および更新するための標準的な実践方法とプロセスについて詳しく説明することも期待されています。また、SBOM の配布とアクセスの実践方法、および偶発的なエラーの処理方法も含める必要があります。
NTIA の SBOM ドキュメントの最低限必要な要素は、脆弱性の管理、ソフトウェア コンポーネントのインベントリの作成、ソフトウェア ライセンスの管理など、ソフトウェア部品表の基本的な使用例に対して SBOM ガイドラインで期待されることの明確な基準を提供します。フレームワークは更新されており、近い将来、使いやすさを拡張する追加要素が含まれる可能性があります。このページの後続のセクションでは、ソフトウェア部品表のこれらの主要コンポーネントについて詳しく説明します。ソフトウェア部品表の最低限必要な要素には、以下に指定されている 7 つのデータ フィールドが含まれます。
データフィールド: 最小要件
ソフトウェア部品表の目的は、ユーザーやその他の関係者がソフトウェア コンポーネントを簡単に識別できるようにする情報を提供することです。予想されるとおり、SBOM の最初の最も重要な要素の 1 つは、ドキュメント内で詳述されているすべてのコンポーネントに含める必要があるデータです。このデータは、個々のコンポーネントの識別に役立つだけでなく、ソフトウェア サプライ チェーン内のさまざまな場所で使用されるコンポーネントを追跡することも容易にします。
- サプライヤ名： サプライヤーは、問題のソフトウェア コンポーネントの作成者または製造者です。これは、ソフトウェア コンポーネントを作成、定義、識別する個人または組織の名前です。
- コンポーネント名: これは、元のサプライヤーまたは製造元によって定義された、ソフトウェアに割り当てられた指定名を指します。ソフトウェアに複数の名前や別名がある場合は、それらも記載される場合があります。
- コンポーネントのバージョン: SBOM には、サプライヤーまたはメーカーが指定したリリース番号またはカテゴリ番号を含める必要があります。バージョン データは、ソフトウェアの後続リリースの以前に識別されたバージョンからのソフトウェアの変更を指定する識別子として機能します。
- その他の一意の識別子: これは、コンポーネント名とバージョン以外の追加の識別子を指します。これらの追加の識別子は、コンポーネントの追加の識別層を提供し、関連するデータベースでコンポーネントを見つけるための検索キーとしても使用できます。
- 依存関係: SBOM はソフトウェア コンポーネントがどのように組み合わされるかを詳述することを目的としているため、これはソフトウェア部品表の最も重要なデータ コンポーネントの 1 つです。依存関係は、アプリケーション内で使用されるソフトウェア X とその上流コンポーネントの間の関係を指定します。
- SBOM データの作成者: SBOM データを作成した個人を指します。場合によっては、ソフトウェアの供給者が作成者を兼ねることもあります。ただし、多くの場合、著者は別の個人またはグループです。
自動化サポート: 最小要件
ソフトウェア部品表の使用は、多くの場合、組織の境界を越えて行われます。これは、SBOM に含まれるデータが組織内の複数の部門や複数の組織によって使用されることが多いことを意味します。このドキュメントを使いやすくするために、NTIA は SBOM が機械可読かつ人間可読の両方の形式であることを推奨します。このように SBOM を標準の自動化フォーマットで準備して送信することにより、この文書のさまざまな意図された目的に対する相互運用性が向上します。
NTIA は、SBOM を生成および送信するための 3 つの配信形式を認識します。ソフトウェア部品表は、によって定められた標準に準拠するために、これらの形式のいずれかに一致する必要があります。 政府のサイバーセキュリティ大統領令。これらの標準形式には次のようなものがあります。
- ソフトウェアパッケージデータエクスチェンジ（SPDX）
- ソフトウェア識別 (SWID) タグ
- サイクロンDX
ソフトウェアパッケージデータエクスチェンジ（SPDX）
SPDX は、SBOM データを配信するためのオープン スタンダードです。これには、コンポーネント、出所、ライセンス、著作権など、ソフトウェアに関する重要な情報が記録されます。セキュリティに関するリファレンスも提供します。の SPDX バージョン 2.2 が最新バージョンで、YAML 1.2 ファイル タイプ、JavaScript オブジェクト表記、およびリソース記述フレームワーク (RDF/XML) をサポートしています。タグ: 値のフラット テキスト ファイルと .xls スプレッドシート
ソフトウェア識別 (SWID) タグ
SWID タグは、ソフトウェア製品のコンポーネントを識別し、コンテキスト化するのに役立つように設計されています。ソフトウェア識別タグ プロジェクト (SWID タグ) は、ソフトウェアの識別タグを生成および検証するためのツールのセットです。これらの Java ベースのツールは、ISO/IEC 19770-2:2015 で定義されている標準化形式に基づく XML SWID タグと Concise Binary Object Representation (CBOR) をサポートします。の NISTにはウェブサイトがあります 以下の役立つリソースのリストが含まれています。
- SWID タグと CoSWID タグの構築
- 特定のスキーマ要件とベスト プラクティス ガイドラインに基づいた SWID タグと CoSWID タグの検証
- Java アプリケーション サーバーにデプロイできる SWID タグ検証サービスを提供する Web アプリ
- National Vulnerability Database にタグを投稿するための SWID リポジトリ クライアント
サイクロンDX
サイクロンDX 「軽量のソフトウェア部品表 (SBOM) 標準」であると主張しています。サプライ チェーンのコンポーネント分析とアプリケーションのセキュリティに役立ちます。 CycloneDX を採用する組織は、SBOM の最小要件をシームレスに満たし、時間の経過とともに SBOM ドキュメントのより洗練されたユースケースに成熟することができます。
CycloneDX SBOM は通常、XML、JSON、またはプロトコル バッファー形式で表示されます。多くの場合、仕様には次の 5 つのフィールドが含まれます。
- 部品表メタデータ: これには、アプリケーションまたはソフトウェア製品自体に関する一般情報が含まれます。
- コンポーネント: これは、ソフトウェアのすべての独自コンポーネントとオープンソース コンポーネントをカバーする包括的なインベントリです。
- サービス情報: アプリケーションが動作中に呼び出す可能性のあるすべての外部 API の詳細が記載されています。これには、すべてのエンドポイント URL、認証要件、信頼境界のトラバーサルが含まれます。
- 依存関係: このドキュメントでは、ソフトウェア パッケージ内のすべてのコンポーネントとサービスについても詳しく説明します。これには、直接的な関係と推移的な関係の両方が含まれます。
- 構成: これは、個々のコンポーネント、サービス、依存関係を含むすべての構成部分の完全性を指します。通常、各構成は、完全か、不完全か、不完全なファーストパーティのみ、不完全なサードパーティのみ、または完全に未知であるかどうかという観点から説明されます。
実践とプロセス: 最小要件
ソフトウェア部品表の最後の要素は、SBOM の使用自体の仕組みに焦点を当てています。実践とプロセスは、SBOM の生成と使用に関する運用の詳細をカバーしており、それを要求するポリシーまたは契約に含める必要があります。以下は、ソフトウェア部品表の「実践とプロセス」セクションで詳しく説明する必要がある主要な要件です。
- 対応周波数： このセクションでは、組織が新しいソフトウェア部品請求書を作成する頻度について詳しく説明します。一般に、NTIA は、ソフトウェア コンポーネントが更新されるか、新しいバージョンがリリースされるたびに、新しい SBOM を生成することを推奨します。また、サプライヤーは、元のバージョンでエラーを見つけた場合、または初期ドキュメントに含まれていなかったソフトウェアのコンポーネントに関する新しい詳細を知った場合には、新しい SBOM を生成することも期待されています。
- 深さ： SBOM の深さは、ドキュメントに含まれる内容によって異なります。準拠するために、SBOM にはすべてのトップレベルのコンポーネントとすべての推移的な依存関係が含まれることが期待されます。作成者がすべての推移的な依存関係を含めることができない状況では、ドキュメントは消費者にそれらを見つけることができる場所を指示する必要があります。
- SBOM 作成者が何らかの理由で完全な依存関係グラフを提供できない場合があります。これは、コンポーネントにそれ以上の依存関係がないか、これらの依存関係が存在するかどうかがわからないことが原因である可能性があります。 SBOM 作成者は、この理由を指定する必要があります。
- 配布と配送: この要件の目的は、SBOM が迅速かつ理解しやすい形式で配信されるようにすることです。この要件では、SBOM を納品する日数または週数は指定されていませんが、できるだけ早く提出する必要があります。また、SBOM には、配信時に適切な役割とアクセス許可が設定されている必要があります。最後に、この要件では、SBOM が製品の各インスタンスとともに配布されるか、公開 Web サイトなどの他の簡単にアクセスできる方法で利用できるようにすることが規定されています。
- アクセス制御： サプライヤーが SBOM データへのアクセスを特定のユーザーまたは顧客に制限することを決定した場合、作成者はアクセス制御の条件を指定する必要があります。また、SBOM データを独自のセキュリティ ツールに統合したい消費者に特別な許可を提供する必要もあります。
- 間違いへの対応: SBOM はソフトウェア保証と ソフトウェアサプライチェーンのリスク管理。ただし、まだ完璧には程遠いです。したがって、消費者は、SBOM の作成時に偶発的に発生する可能性のある意図しないエラーや省略を許容する必要があります。
NTIA の最小要件を超えて考える
ここまで、ソフトウェア部品表に必要な最小限の要素について説明してきました。これらの最小要素は、特にこのドキュメントの最も基本的な使用例に対して推奨される要件を表しています。これらはソフトウェアの来歴とセキュリティの優れた基盤を築きますが、これらの要件の先に目を向ける必要があります。以下は、より高度な SBOM の使用例で考慮すべきいくつかの推奨事項です。
追加のデータフィールド
最小要件ドキュメントで取り上げられているデータ フィールドに加えて、より高いレベルのセキュリティが必要な場合に推奨される追加のデータ フィールドがあります。これらの追加データ フィールドには次のようなものがあります。
- ソフトウェアコンポーネントの暗号化ハッシュ
- ソフトウェアライフサイクルフェーズデータ
- 他のコンポーネント間の関係
- ライセンス情報
クラウドベースのソフトウェアとサービスとしてのソフトウェア
SBOM 要件が基本を超える可能性があるもう 1 つの潜在的な領域は、Software-as-a-Service (SaaS) 製品の管理です。この種のソフトウェア製品には、SBOM データに関する限り、特有の課題があります。まず、クラウドのコンテキストにおけるセキュリティ リスクは独特です。また、それらのリスクに対処する責任はサービスプロバイダーにあります。クラウドベースのソフトウェアはリリース サイクルが短い傾向にあるため、SBOM ドキュメントの準備もより複雑になります。
SBOM の完全性と信頼性
注目に値する可能性のあるもう 1 つの問題は、SBOM データ自体のソースを認証するプロセスです。現在、署名と公開鍵インフラストラクチャは、今日のデジタル世界でソフトウェアの整合性を検証するための頼りになるソリューションです。 SBOM の作成者とサプライヤーは、SBOM データの信頼性を向上させるために、これらの既存のソフトウェア署名を活用する必要がある場合があります。
依存関係における脆弱性と悪用可能性
SBOM の目的は脆弱性の検出を容易にすることですが、依存関係のすべての脆弱性が、SBOM に依存するソフトウェアにとって重大なリスクを構成するわけではないことに注意することが重要です。時間とリソースの無駄を避けるために、ソフトウェアサプライヤーは、ダウンストリームを使用するソフトウェアに対する依存関係の脆弱性の潜在的な影響を判断し、リスクレベル（この場合はリスクの欠如）をSBOMのユーザーに伝えるための対策を講じる必要があります。データの下流。
実装における柔軟性と均一性
ソフトウェアのセキュリティが議論されるとき、常に柔軟性と均一性の問題が浮上します。これは、SBOM の高度な使用例にも当てはまります。 SBOM の導入を成功させるには、柔軟性が必要な特定のケースだけでなく、すべての分野に適用される広範なポリシーが必要になります。