脅威アクターがITのサプライチェーンを狙うなか、サイバーセキュリティの強化が、近年、ソフトウェア部品表（SBOM）フレームワークの業界導入を促す原動力となっている。
ソフトウェア製品を構成する部品をシンプルに一覧化するSBOMは、ソフトウェアの買い手と売り手の透明性を高め、脆弱性を特定するために必要な可視性を提供し、迅速なインシデント対応を可能にする。SBOMは、ソフトウェアの機能に依存する顧客と、その構築方法やソースコンポーネントに関する開発者またはサプライヤーの知識との間に可視性のギャップを生む、ソフトウェア開発プロセスの非効率性に直接対処する。
SBOMは、ソフトウェアコンポーネントの詳細なインベントリによって、SLAに関連するライセンスおよびコンプライアンス上のリスクからも保護する。SBOM導入の潜在的な有効性を考えると、重大なIT、ビジネス、第三者リスクを軽減し、組織の収益を改善できるのであれば、ソフトウェア・サプライチェーンの慣行を標準化することにデメリットはない。
本記事では、ソフトウェア部品表、ファイルデータ、既存の標準規格、メリット、ユースケース、そしてSBOMがサイバーセキュリティにとって何を意味するのかを解説する。
ジャンプ先：
- ソフトウェア部品表（SBOM）とは？
- SBOMファイルには何が含まれるのか？
- 標準化の必要性
- 脆弱性・悪用可能性交換（VEX）
- SBOM導入のメリット
- SBOMの作成方法
- 概念実証：医療分野のSBOM
- SBOMがサイバーセキュリティに意味すること
ソフトウェア部品表（SBOM）とは？
ソフトウェア部品表（SBOM）とは、特定のソフトウェア製品に含まれるコンポーネント、依存関係、メタデータ、および階層関係を機械可読形式で一覧化したものだ。オープンソースやプロプライエタリなコンポーネントが混在するなか、SBOMは、リスクの高い要素や、後に攻撃に対して脆弱だと判明した要素を特定することで透明性を提供する。
SBOMフレームワークでは、開発者やサプライヤーが識別するソフトウェアの単位をコンポーネント、関連データを属性と呼ぶ。ソフトウェア製品全体はプライマリコンポーネントであり、多くの場合、複数の上流コンポーネントを含む。各コンポーネントのSBOMエントリを作成することで、1つの集合ファイルが形成される。
ソフトウェア購入者の栄養成分表示
食料品店で栄養成分表示を見るのと同じように、組織は購入前にSBOMを使って製品のソースコードを評価できる。食料品を購入した人が、後になって医師から新たなアレルギーや健康上の問題を告げられた場合、その食品を振り返って廃棄するのは患者自身だ。
ソフトウェアコンポーネントの場合、悪用可能な脆弱性が定期的に特定され、優先的な修正が必要となる。使用中のソフトウェアに栄養成分表示に相当するものがなければ、組織は脆弱なシステムへの対処が難しくなる。脅威インテリジェンスは、IT環境をスキャンして最新のマルウェアを探すのに役立つが、ゼロデイ脅威に対するセキュリティレイヤーの1つにすぎない。
関連記事： Pythonパッケージリポジトリでサプライチェーンの欠陥が発見される
ソフトウェア・サプライチェーンの問題
すべてのソフトウェアには脆弱性が存在するため、購入、使用、または構築するコードのコンポーネントを理解することは、IT環境の完全性を維持するうえでますます重要になっている。
リスクを完全に排除できるソフトウェア管理戦略など存在しない。したがって、組織はリスクを認識した運用を目指さなければならない。新しいミレニアムに入り、アジャイルプログラミング手法の台頭によって開発サイクルは短縮し、アプリケーションのデプロイ頻度は高まった。その結果、不安定なリリースのリスクも増大している。さらに、オープンソースとプロプライエタリなソフトウェアコンポーネントをソリューションに混在させることで、ソフトウェア・サプライチェーンは当然ながら複雑になる。
開発が膨大な規模で行われるなか、組織は第三者リスクの管理に、より積極的に取り組まなければならない。
SBOMのユースケース
SBOMの主なユースケースは、サプライチェーンの脆弱性管理と、製品の完全性を保証するプロセスへの適用である。
脆弱性管理
脆弱性は存在し、発生し、残存するため、下流の組織はソフトウェアサプライヤーのリスクを考慮しなければならない。SBOMのコンポーネントインベントリにより、特定の脆弱性をはるかに容易に特定できる。VEXファイルを導入すれば、組織は脆弱性が悪用可能かどうかを正確に確認し、重大な脆弱性を速やかに修正できる。
製品の完全性
透明性が高まれば、買い手と売り手はより多くの情報に基づいて判断でき、製品の有効性に対する確信も高まる。ソフトウェアコンポーネントの出所と完全性を保証することは、サイバーセキュリティエコシステムの改善に不可欠であり、SBOMはソフトウェアライセンスと利用権の追跡に関して、組織の可視性と管理能力を高める。
関連記事： 一般的なITセキュリティ脆弱性への対処法
SBOMファイルには何が含まれるのか？
いくつかの形式が普及しつつあるものの、世界的に受け入れられたSBOM構造はまだ存在しない。National Telecommunication and Information Administration（NTIA）は、現在提案されている基本コンポーネント属性は意図的に基本的なものにとどめられており、今後の発展の余地があるほか、業界によって具体的な変更が加えられる可能性があると認めている。NTIA Software Component Transparency Framing Working Groupは次のように述べている。
“これは、最初から収集・維持により多くの時間とリソースを要する、より強固な属性セットを求めるのではなく、出発点としてこのような基本的な情報セットを確立する大きな原動力の1つである。「
提案された基本コンポーネント属性
| 作成者名 | SBOMの作成者（開発者、サプライヤー、GRC、第三者など） |
|---|---|
| タイムスタンプ | 初回作成日時および最終更新日時 |
| サプライヤー名 | コンポーネントの開発者およびサプライヤーを識別する情報 |
| コンポーネント名 | コンポーネント名、または複数のコンポーネント名の一覧 |
| バージョン文字列 | バージョン体系に基づくコンポーネントのバージョン情報 |
| コンポーネントハッシュ | コンポーネントデータの暗号学的ハッシュまたはデジタル署名 |
| 一意識別子 | 一意の階層におけるコンポーネントの位置に関する追加データ |
| 関係 | 上流または下流の依存関係の存在を列挙する |
一部の属性データでは、サプライヤー名のように複数の入力が必要になる場合がある。一方、作成者が把握できる範囲によっては、SBOMファイルの作成者が入力できないフィールドもある。後者の場合、作成者はフィールドデータが不明なのか、存在しないのか、部分的にしか把握できていないのか、または把握済みなのかを明示すべきである。
検討すべきその他の属性には、利用情報、ライセンス、サポート終了日、第三者通知、コンポーネントのクラスター、コンポーネントが下流システムに及ぼす影響などがある。いずれの場合も、SBOMの真正性を検証するには、SBOMの暗号学的認証が不可欠である。
コンポーネント間の関係の重要性
オープンソース、プロプライエタリ、あるいはその組み合わせであるかにかかわらず、今日のソフトウェアに統合されるコンポーネントとその関係は、組織の収益に影響を及ぼす。開発者とサプライヤーは、プライマリコンポーネントを起点に、製品のサプライチェーンの履歴に関わる上流コンポーネントとの関係を定義できる。
関連記事： 複数当事者によるサイバー攻撃が大きな損失を招く
次の図で、NTIAはソフトウェアアプリケーションの関係を図式化した概念例を示している。この例では、SBOMに4つのコンポーネントが含まれる。プライマリコンポーネントと、3つの上流コンポーネントだ。この4つ以外にもコンポーネントが存在する可能性はあるが、SBOMの作成者は既存の知識に基づいて作業しなければならない。フローチャートと表に示すように、SBOMはコンポーネントの詳細と、ソフトウェア・サプライチェーンにおける相互関係を捉えた全体像を記録できる。
標準化の必要性
SBOMの導入を現実のものにするには、異なる業界や組織間の相互運用性を可能にする、業界で受け入れられた形式に従う必要がある。すでにいくつかの標準規格が整備されており、組織はソフトウェアコンポーネントのデータを迅速に作成、維持、共有するためのフレームワークを得ている。
SPDX：Software Package Data Exchange
Linux Foundationが2010年に開発したSoftware Package Data Exchange（SPDX）は、SBOM形式の主要なオープン標準である。SPDXファイルには、ソフトウェアコンポーネント、著作権、ライセンス、セキュリティリファレンスが含まれる。
SPDX仕様は、NTIAが提案するSBOMの最小標準と、脆弱性スキャン、ライセンスコンプライアンスなどのユースケースに適合する。SPDX Liteを使えば、組織はデータ交換のためにSPDX標準のコンパクトなサブセットを利用できる。2021年8月、SPDXはISO/IEC 5962として正式な標準規格になった。
SWID：Software Identification Tagging
2010年代の終わり頃、International Organizations for Standards（ISO）は、機械可読のIDでソフトウェアコンポーネントにタグ付けする標準の開発を開始した。現在Software Identification（SWID）Tagsとして知られるものは、ソフトウェアに埋め込まれた構造化メタデータであり、ソフトウェア製品名、バージョン、開発者、関係などを伝達する。
ソフトウェア資産管理（SAM）と同様に、SWID Tagsはパッチ管理、ソフトウェアの完全性検証、脆弱性検出、ソフトウェアインストールの許可またはブロックを自動化するのに役立つ。ISO/IEC 19770-2は2012年に承認され、2015年に更新された。
OWASPのCycloneDX
OWASP Foundationは2017年、オープンソースソフトウェアのコンポーネント分析ソリューションであるDependency-Trackの一部としてCycloneDXを設計した。脆弱性の特定、ライセンスコンプライアンス、旧式のコンポーネントの分析などのユースケースに対応するCycloneDXは、複数の業界で利用できる軽量な標準規格である。CycloneDXの第4版（1.3）は2021年5月にリリースされた。
関連記事： OWASP、数年ぶりに新たな重大脆弱性を選定
脆弱性・悪用可能性交換（VEX）
NTIAが開発した脆弱性・悪用可能性交換（VEX）は、ソフトウェア製品における特定の脆弱性の状態についての表明を提供する。VEXを発行することで、ソフトウェアサプライヤーは、悪用できない可能性がある特定の脆弱性について顧客に知らせる。悪用不可能な脆弱性の状態には、次のようなものがある。
| 脆弱性の状態 | 説明 |
|---|---|
| 修正済み | 製品バージョンによって特定の脆弱性が解消されている |
| 既知・影響あり | この脆弱性に対処するための措置が必要 |
| 既知・影響なし | 措置は不要 |
| 調査中 | 脆弱性の影響は不明で、脆弱性はなお評価中 |
SBOMと同様に、VEX形式はソフトウェア関係者間の透明性を高めるためのフレームワークを提供する。エンタープライズ組織にとって、VEXは機械可読であり、ソフトウェアコンポーネントの脆弱性管理における大量取り込みと自動化も可能にする。
SBOM導入のメリット
ソフトウェア部品表は、追加のリスクの軽減と、サイバーセキュリティのベストプラクティスを重視するあらゆる組織にメリットをもたらす。脆弱性管理、第三者リスク管理、ソフトウェア構成分析のベンダーは、組織の移行を支援するため、すでにSBOMサービスを統合している。
- ソフトウェアコンポーネントと脆弱性に関する情報共有を効率化する
- 共通のデータファイル（json、xml、html、pdf、またはtxt）を介して、製品のSBOMを容易に共有する
- 開発者、ベンダー、顧客がより多くの情報に基づいて判断できるようにし、サプライチェーンの完全性を高める
- 重要なパッチと修正措置の迅速な展開およびロールバックを促進する
- ソフトウェア監査と規制コンプライアンス基準における記録管理を改善する
- 運用中のソフトウェア、コンポーネント、システム間の関係に対する可視性を高める
SBOMの作成方法
ソフトウェア部品表は、使用されているソースコードコンポーネントを最も正確に可視化できるよう更新される、生きた記録であるべきだ。SBOMを管理するために、組織はまず、安全でない情報、脆弱性、ライセンス、バージョンなど、関連するソフトウェアインベントリ項目を特定しなければならない。
- コンポーネントデータを収集し、属性データを列挙して、SBOMを作成する
- 主要なコンポーネントファイルを作成する前に、初期の調整を完了する
- 関係者および見込み顧客向けにリリースする前に、ファイルを確認して完成させる
- ファイルの完全性を監視し、特定された変更に対処して、ファイルを更新する
米国の連邦政府請負業者がSBOMの作成を最初に義務付けられることになるが、推進者たちはソフトウェア開発プロセスにSBOMを組み込むことを世界的なビジョンとして掲げている。既存の標準規格が普及するにつれ、新たなソフトウェアコンポーネントごとに対応するSBOMを作成することがベストプラクティスになるだろう。その結果、透明性に基づく、より堅牢なエコシステムが実現する。
関連記事： 攻撃者が数百万台のルーターやIoTデバイスに影響を及ぼす欠陥を悪用
概念実証：医療分野のSBOM
2019年10月、NTIAはソフトウェアコンポーネントの透明性に向けたSBOM概念実証を開発する取り組みのフェーズIを公開した。医療提供組織（HDO）が利用するSBOMを作成する医療機器メーカー（MDM）が主導し、その成果は継続的な開発の基盤となった。
2年後、NTIAはフェーズIIを完了した。今月初めに公開された調査結果で、フェーズIIは、受け入れられたベースライン要素とSPDXを検証し、標準ソフトウェアコンポーネントと実践ガイドを生産者向けに列挙するとともに、VEXのユースケースを検討した。フェーズIIIの目標には、医療分野全体での導入促進、SBOM交換の自動化、サポート終了となった製品やサービスの非効率性への対処が含まれる。
SBOMがサイバーセキュリティに意味すること
情報セキュリティの目標（機密性、完全性、可用性）のうち、ソフトウェア部品表が最も効果的に対応するのは、組織のデータとシステムの完全性の保全である。使用中または開発中のソフトウェアに関する正式な文書として、ソフトウェアコンポーネントファイルは、専有情報を保護する際のリスクを高める可能性がある。同様に、SBOMがデータの可用性に直接影響することもない。
SBOMは、開発者、ソフトウェアベンダー、顧客間の透明性を高める業界の先例となる。標準規格が整備されれば、組織は契約プロセスにおいて、ソースコードの詳細をパートナーに安全に知らせることができる。SBOMがより一般的になるにつれて、組織はバグ、脆弱性、ゼロデイ脅威を特定するため、より積極的な姿勢を取れるようになる。世界中のサイバーセキュリティ専門家にとって、SBOMの導入は明らかに大きな成果である。