ソフトウェア部品表 (SBOM) とは何ですか?

ソフトウェア サプライ チェーンにおける SBOM: XZ Utils バックドアから学んだ教訓

CVE-2024-3094 として識別される XZ Utils バックドア ケースには、広く使用されている Linux ユーティリティに挿入された悪意のあるバックドアが関係していました。この脆弱性は、主要な Linux ディストリビューションに統合される直前に Andres Freund によって発見され、数百万台のサーバーが危険にさらされました。研究者はこの脆弱性を実稼働前に発見し、実際の被害を防止しました。この特定の事例では SBOM は役割を果たしませんでしたが、4 年の Log2021j で見られたように、この脆弱性が蔓延した場合には、SBOM は非常に重要になります。 Log4j のような広範囲にわたる脆弱性では、SBOM プラットフォームは爆発範囲を理解するのに効果的に役立つ可能性があります。そして影響分析を実施します。 XZ Utils の脆弱性が導入されていた場合、Scribe Hub のようなツールは企業に警告するのに役立ち、企業がソフトウェア インベントリを検索し、侵害されたバージョンの導入をブロックし、全体的なセキュリティ体制を強化できるようになった可能性があります。

ソフトウェア部品表の定義

ソフトウェア部品表 (SBOM) には、アプリケーションの開発と配信に関係するすべてのコンポーネント部品とソフトウェアの依存関係がリストされています。 SBOM は、サプライ チェーンや製造で使用される部品表 (BOM) に似ています。 IT 業界のすべてのベンダーに、アプリケーションを構築する基本的なコード コンポーネントを正確に記述する共通の機能はありませんでした。

一般的な SBOM には、ライセンス情報、バージョン番号、コンポーネントの詳細、ベンダーが含まれます。すべての事実の正式なリストにより、他の人がソフトウェアの内容を理解し、それに応じて行動できるようになるため、メーカーとユーザーの両方のリスクが軽減されます。 SBOM はソフトウェア業界にとって新しいものではありませんが、開発がより高度になり、コストが高くなるにつれて、その重要性はますます高まっています。最近では、多くのビジネスで基本的な要件となっています。

クラウドネイティブ アプリの保護: 強化された SBOM の力

クラウドネイティブ アプリケーションの台頭により、最新のソフトウェア環境のセキュリティ保護がますます複雑になっています。これらのアプリケーションは、動的で分散された性質を特徴とし、相互接続されたマイクロサービスと外部コンポーネントで構成され、攻撃対象領域が増加します。 SBOM はクラウドネイティブ アーキテクチャ内のすべてのコンポーネントと依存関係を詳細に可視化するため、この状況では SBOM の強化が重要になります。効果的な SBOM は、脆弱性を特定し、セキュリティ標準への準拠を確保し、迅速なインシデント対応を促進します。堅牢な SBOM を活用することで、組織はソフトウェア資産の包括的なインベントリを維持し、変更を追跡し、潜在的なセキュリティ リスクを早期に検出できます。クラウドネイティブ アプリケーションの時代において、セキュリティを強化し、複雑なソフトウェア エコシステムの整合性を維持するには、SBOM プラクティスの強化が不可欠です。

SBOM の利点

誠実性に対する脅威への対処

攻撃は通常のソフトウェア サプライ チェーンのどの時点でも発生する可能性があり、今日の世界では、これらの攻撃はより目に見え、破壊的で、費用がかかるものになっています。 SBOM を使用すると、そこに表示されるコンポーネントとファイルが意図したものと同じであることを検証することで、整合性を維持できます。たとえば、CycloneDX 形式のコンポーネントの 1 つは、ファイルとコンポーネントの正確な一致に使用できるハッシュ値です。 SBOM は静的なドキュメントではないため、記載されているソフトウェアまたはそのコンポーネントに変更があった場合は常に更新する必要があります。

製品コンポーネントの可視化を可能にします

企業はロイヤルティを生み出し、リピート購入を促進するために、顧客の信頼を築く必要があります。共有 SBOM は、保証や約束ではなく、使用するテクノロジーの品質に対する可視性を強化します。

脆弱性スキャンが容易になります

企業は SBOM を使用して、本番環境に到達する前に脆弱性を特定して排除する場合があります。実稼働ソフトウェアの新しい脆弱性はすぐに修正できます。 SBOM は最終的に、エンジニアがセキュリティ上の欠陥をより迅速に発見して解決するのに役立ちます。

製品のライセンス ガバナンスを活用

ソフトウェア部品表の導入は、ソフトウェア ライセンス ガバナンスの強化に役立ちます。すべてのソフトウェアには、合法的に使用および配布する方法を指定するライセンスが付属しています。完全なアプリケーションを構成するサプライ チェーンの構成コンポーネントには、さまざまな異なるライセンスが割り当てられている場合があります。プログラムを使用するすべての企業は、ライセンスに従うことが法的に義務付けられています。ソフトウェア部品表がなければ、ライセンスに何が必要か、またはライセンスに準拠する方法を判断する方法がない場合があります。

適切に形成された SBOM の原則

適切に形成された SBOM の最小限のコンポーネントは、次の 3 つのカテゴリに分類されます。

データフィールド

これらのフィールドの目的は、これらのコンポーネントを適切に識別することです。これにより、ソフトウェア サプライ チェーン全体でそれらを監視し、脆弱性やライセンス データベースなどの他の有用なデータ ソースに関連付けることができます。データ フィールドの例としては、サプライヤー名、コンポーネント名、コンポーネントのバージョン、その他の一意の識別子、依存関係、SBOM データの作成者、タイムスタンプなどがあります。

自動化サポート

SBOM コンポーネント データを常に監視したい組織は、一貫したわかりやすいスタイルでデータを提供する必要があります。これについては、「自動化サポート」の SBOM の基本要件セクションで説明されています。組織の境界を越えて SBOM を送信する場合、次の 3 つの標準から選択できます。

1. ソフトウェアパッケージデータエクスチェンジ（SPDX）
2. サイクロンDX
3. ソフトウェア識別 (SWID) タグ

これらについては、この記事の後半でさらに詳しく説明します。

実践とプロセス

最後に、「実践とプロセス」セクションでは、SBOM をいつどのように更新して提供するかについて 6 つの標準を示しています。それらは次のとおりです。

• ソフトウェア コンポーネントが新しいビルドまたはリリースでアップグレードされる場合は、新しい SBOM を作成する必要があります。
• SBOM の作成者は、トップレベルのコンポーネントとその推移的な依存関係を含める必要があります。
• SBOM が完全な依存関係ツリーを提供しない場合、SBOM 作成者は、その理由が (a) コンポーネントに依存関係がなくなったのか、または (b) 依存関係の存在が不明で不完全であるためなのかを説明する必要があります。
• SBOM は、「適切なアクセス権と役割が設定された」状態で、「タイムリーに」配布および提供される必要があります。
• SBOM の一部のコンポーネントを秘密にしたい企業は、アクセス制御パラメーターを指定する必要があります。これには、SBOM 関連情報をユーザーのマニュアルやツールに組み込むための特定のルールと手順が含まれます。簡単に言うと、組織のために秘密にしなければならない何かがある場合、それを秘密にしておくプロセスがこのセクションで定義されます。 
• SBOM の生成を制御する標準は新しいため、SBOM ユーザーは (意図しない) 障害や欠落を許容することをお勧めします。

さまざまな SBOM 形式

もちろん、作成したソフトウェア内の多くのコンポーネントをリストすることで、SBOM 請求書を手動で生成することもできます。ただし、数十、場合によっては数百の依存関係やサードパーティ コンポーネントを含む巨大なコードベースを維持することは、特に複数のサードパーティ コンポーネントや依存関係を含む大規模なコードベースを管理する開発者にとっては、面倒で時間のかかる作業です。開発者によっては、文書化せずにアプリケーションにサードパーティのコンポーネントを組み込んでいる場合があります。その結果、現在の開発者はコードベース全体に精通していない可能性があります。

導入を現実にするには、SBOM は、さまざまなセクターや組織間の相互運用性を可能にする業界で認められた標準を遵守する必要があります。組織は、いくつかの標準のおかげで、ソフトウェア コンポーネント データを開発、管理、配布するためのアーキテクチャをすでに導入しています。

SPDX: ソフトウェア パッケージ データ交換

この ソフトウェアパッケージデータエクスチェンジ（SPDX） SPDX ファイルには、ソフトウェア コンポーネント、著作権、ライセンス、セキュリティ参照がすべて含まれています。 SPDX 仕様は NTIA の提案と互換性があります。 SBOM最低基準 そしてユースケース。 SPDX Lite は SPDX 標準の圧縮バージョンであるため、組織は SPDX Lite を使用してデータを交換できます。 SPDX は、5962 年 2021 月に ISO/IEC XNUMX として正式な規格を取得しました。

SPDXドキュメント

SWID: ソフトウェア識別タグ付け

この 国際標準化機構 (ISO) は、10 年代が終わる前に、ソフトウェア コンポーネントに機械可読 ID をマークするための標準を確立し始めました。現在知られている SWID タグは、ソフトウェア製品の名前、バージョン、開発者、関係などの情報を送信する、ソフトウェアに組み込まれた構造化メタデータです。 SWID タグは、ソフトウェア資産管理と同様に、パッチ管理、ソフトウェア整合性検証、脆弱性検出、ソフトウェア インストールの許可または禁止の自動化に役立ちます。 2012 年に ISO/IEC 19770-2 が確認され、2015 年に修正されました。 ソフトウェア開発ライフサイクルのさまざまな段階で使用される SWID タグには、主に 4 つのタイプがあります。

1. コーパスタグ: これらは、インストールする準備ができていないソフトウェア コンポーネントを識別し、特徴付けるために使用されます。米国国立標準技術研究所によると、コーパス タグは「ソフトウェア インストール ツールおよび手順への入力として利用できるように設計されている」とのことです。
2. 主なタグ: プライマリ タグの目的は、ソフトウェア アイテムがインストールされた後にそれを識別し、コンテキスト化することです。
3. パッチタグ: パッチ タグは、(コア製品自体ではなく) パッチを識別し、説明します。パッチ タグには、他の商品やパッチとのパッチの関係に関するコンテキスト情報を組み込むこともでき、実際に組み込むことがよくあります。
4. 補足タグ: 補足タグを使用すると、ソフトウェア ユーザーやソフトウェア管理ツールは、ライセンス キーや関連当事者の連絡先情報など、有用なローカル ユーティリティ コンテキスト情報を追加できます。

どのタグと正確なデータを自社の製品とともに提供するかを決定する際、企業にはかなりの余裕があります。 SWID 標準では、必須データに加えて、多数のオプションのコンポーネントと特性が指定されています。 最後に、基本的な有効で準拠したタグには、ソフトウェア製品 (名前やタグ ID など) とそれを生成したエンティティを特徴付けるいくつかの特性が必要です。

サイクロンDX

2017 年、OWASP 財団は サイクロンDX オープンソースのソフトウェアコンポーネント分析ツールであるDependency-Trackの一部として。 CycloneDX は、脆弱性の検出、ライセンスのコンプライアンス、古いコンポーネントの評価などのユースケースを備えた、複数の業界で使用できる軽量の標準です。 CycloneDX 1.4 は 2022 年 XNUMX 月にリリースされました。 Cyclone DX は 4 つの異なるタイプのデータを処理できます。

• マテリアル フロー チャートのメタデータ: これには、SBOM に記述されているサプライヤー、製造元、コンポーネントなどのアプリケーション/製品自体に関する情報と、SBOM の作成に使用されるツールが含まれます。
• コンポーネント： これは、プロプライエタリ コンポーネントとオープンソース コンポーネントの両方とライセンス情報の包括的なリストです。
• サービス： エンドポイント URI、認証要件、信頼境界のトラバーサルはすべて、ソフトウェアが使用できる外部 API の例です。
• 依存関係： 直接接続と間接接続の両方が含まれます。

出典： サイクロンDX

SBOM はどのようなものですか?

リスクを特定するには、すべてのファーストパーティおよびサードパーティのコンポーネントの徹底的かつ正確なインベントリが必要です。すべての直接コンポーネントと推移コンポーネント、およびコンポーネント間の依存関係は、BOM に含める必要があります。 たとえば、次のタイプのコンポーネントは CycloneDX を使用して記述できます。

{ "bomFormat": "CycloneDX", "specVersion": "1.4", "serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79", "version": 1, "components": [ { "タイプ": "ライブラリ"、"名前": "nacl-library"、"バージョン": "1.0.0" } ] }

XML形式：

 nacl-ライブラリ1.0

SBOM に署名する理由

デジタル署名とは何ですか？

A デジタル署名 これはまさにその名の通り、従来の紙とペンによる署名の電子バージョンです。 高度な数学的アプローチを使用して、デジタル通信とドキュメントの有効性と完全性をチェックします。これにより、メッセージの内容が転送中に改ざんされないことが保証され、デジタル通信におけるなりすましや改ざんの問題を克服するのに役立ちます。デジタル署名は時間の経過とともに採用が増加しており、暗号化の標準となっています。 

デジタル署名のしくみ

デジタル署名は、公開キー暗号化 (非対称暗号化とも呼ばれます) を使用して作成されます。次のような公開鍵アプローチ RSA (リベスト・シャミア・エイドルマン) 秘密キーと公開キーの 2 つのキーを生成し、数学的に関連するキーのペアを生成します。 デジタル署名の背後にある中心的なメカニズムの 1 つはハッシュです。入力のサイズに関係なく、データを固定サイズの出力に効果的に変換します。これは基本的にアルゴリズムであるハッシュ関数を通じて行われ、生成される出力はハッシュ値と呼ばれます。暗号化ハッシュ関数は、デジタル指紋として機能するハッシュ値を生成し、誰にとっても一意なものとします。指紋が人それぞれ異なるのと同様、入力メッセージが異なれば、生成されるハッシュ値も異なります。 公開キー暗号 (PKC) の 2 つの相互認証暗号キーは、主にデジタル署名に使用されます。デジタル署名の作成者は秘密キーを使用して署名関連データを暗号化し、そのデータは署名者の公開キーを使用しないと復号できません。これにより、受信者は、送信者が侵害されておらず、受信したデータが正しいことを知ることができます。現在、公開鍵インフラストラクチャの取り扱いはコストがかかり、複雑です。 秘密鍵を失う 物理的な鍵を紛失してしまうようなものです。 認証局 (CA) は信頼できる第三者として機能し、デジタル証明書の受け入れ、検証、発行、維持を行うことでデジタル署名を発行します。 CA は、偽のデジタル証明書が作成されるのを防ぐのに役立ちます。また、 トラストサービスプロバイダー (TSP)。 TSP は、企業に代わってデジタル署名を検証し、検証結果を伝達する個人または法人です。

デジタル署名された SBOM の利点

署名付き SBOM はチェックサムを提供します。チェックサムは、デジタル データの正確な桁の合計を表す文字と数字の長い文字列であり、欠陥や変更を見つけるために比較できます。チェックサムはデジタル指紋に似ています。定期的に冗長性 (CRC) をチェックします。デジタル ネットワークやストレージ デバイス内の生データへの変更は、エラー検出コードと検証機能を使用して検出されます。 デジタル署名は、取引における信頼性を証明する検証済みの安全な方法として機能することを目的としているため、つまり、一度署名すると、人は別の主張をすることができなくなります。これにより、法案に定められた手順と措置に対するすべての署名者が拘束されます。 

署名されていない SBOM の問題

デジタル署名の主な目的の 1 つは検証であるため、署名されていない SBOM は検証できません。これを契約と考えてください。参加当事者が契約に署名していない場合、それを強制する実際の方法はありません。同様に、署名されていない SBOM は単なる署名されていない文書であり、顧客はあなたに責任を追及することはできません。  署名されていない SBOM は組織のセキュリティにリスクをもたらす可能性があるため、これは将来さらなる問題につながる可能性があります。署名された SBOM によって保護されていた可能性のあるものはすべて保護されなくなるため、データや情報はどこにでも送信または複製される可能性があります。署名された SBOM の主な目的の 1 つである説明責任は、SBOM が署名されていない場合、作成者またはクライアントの側からの影響なしに変更を加えることができるため失われます。 

SBOM を使用したサイバーセキュリティの強化

SBOM は、組織がデータと手順の安全性と信頼性を維持するための最良の方法の 1 つです。また、開発者、ソフトウェア サプライヤー、クライアント間のオープン性を高めることで、業界の前例を作りました。標準が整備されていれば、組織は契約プロセスを通じてパートナーに業務の詳細を安全に伝えることができます。 SBOM がさらに普及するにつれて、組織は欠陥、脆弱性、ゼロデイ脅威の特定に成功するようになるでしょう。ソフトウェア部品表の採用は、世界中のソフトウェア サプライ チェーンのセキュリティにとって明らかにメリットとなります。

VEX を使用して SBOM をさらに使いやすくする

Vulnerability Exploitability eXchange (VEX) は、脆弱性が見つかった製品のコンテキストにおける脆弱性の悪用可能性を暴露することを目的としたセキュリティ アドバイザリーです。最新のアプリケーションで脆弱性スキャンを実行すると、数百、数千の脆弱性が結果として得られる可能性があります。発見された脆弱性の総数のうち、実際に悪用可能な脆弱性はわずか約 5% のみです。また、悪用可能性が単独の問題であることはほとんどないことを覚えておくことも重要です。多くの場合、脆弱性を実際に悪用可能な問題に変えるのは、オープンソース ライブラリ、モジュール、およびそれらを連携して使用するコードの複雑なユースケースです。アプリケーションを変更し、それを記述するために新しい SBOM を実行するまで、BOM に記述されたインベントリは通常、静的なままになります。脆弱性に関する情報はより動的であり、変更される可能性があります。 VEX 情報をスタンドアロン リストとして利用できるようにすると、追加の BOM を生成および管理することなく VEX データを更新できるようになります。 CISA は以下のリストを提供しています。 推奨される最小限のデータ要素 それは有用な VEX アドバイザリーまたは文書に含める必要があります。これらは：

VEX メタデータ: VEX フォーマット識別子、VEX ドキュメントの識別子文字列、作成者、作成者の役割、タイムスタンプ。 

製品詳細: 製品識別子または製品ファミリー識別子 (確立された SBOM ガイダンス 3 に規定されている、一意の識別子またはサプライヤー名、製品名、およびバージョン文字列の組み合わせなど)。 

脆弱性の詳細: 脆弱性の識別子 (CVE またはその他の識別子) および脆弱性の説明 (CVE の説明など)。 

製品ステータス 詳細 (つまり、その製品の脆弱性に関するステータス情報): 

• 影響なし – この脆弱性に関して修正は必要ありません。
• 影響あり – この脆弱性を修復または対処するためのアクションが推奨されます。
• 修正済み – これらの製品バージョンには、脆弱性の修正が含まれています。 
• 調査中 – これらの製品バージョンがこの脆弱性の影響を受けるかどうかはまだ不明です。アップデートは今後のリリースで提供される予定です。

SBOM 導入の課題を克服する

SBOM を組織のソフトウェア開発ライフサイクル (SDLC) に組み込むと、いくつかの課題が生じます。まず、正確な SBOM の生成と維持には時間と費用がかかり、ツールとプロセスに多大な投資が必要になります。 SBOM の課題には、SBOM 管理と既存の CI/CD パイプラインの統合も含まれており、これには CI/CD パイプライン統合の合理化が含まれる場合があります。さらに、SBOM の完全性と正確性を確保するには、サードパーティの依存関係を含むすべてのソフトウェア コンポーネントを注意深く追跡する必要があります。もう 1 つの大きなハードルは、開発チーム間で透明性とセキュリティ意識の文化を育むことであり、これは SBOM プラクティスの導入を成功させるために不可欠です。これらの SBOM の課題を克服するには、ソフトウェア サプライ チェーンのセキュリティを強化するための堅牢なツール、効果的なトレーニング、強力な組織的取り組みを組み合わせた戦略的アプローチが必要です。

まとめ

結論として、SBOM はほとんどの組織にとってまだ斬新なアイデアですが、SBOM を作成できる機能は将来的にはより重要になると予想されます。 SBOM 作成をまだソフトウェア配信プロセスに組み込んでいない場合は、この機会に組み込んでください。