昨年2023年の今頃、米国証券取引委員会（SEC）はテキサス州オースティンに本拠を置くソフトウェア企業に対する訴訟に関するプレスリリースを発表しました。この訴訟は、世界中のソフトウェア企業を困惑させてきた懸念——ソフトウェアサプライチェーンのセキュリティ——を反映したものでした。サイバー脅威アクターは以前からソフトウェアのサプライチェーンを標的にしており、Log4jフレームワークの脆弱性のようなものを悪用してマルウェアをインストールしている。
このサプライチェーンセキュリティへの懸念の高まりが、ソフトウェア部品表（SBOM）がサイバーセキュリティに関する公式の行政規制の中で位置づけられつつある主な理由である。ソフトウェアサプライチェーンは複数のプロセスが関与するため複雑化しがちです。SBOMは、これらのプロセスが直接関与する様々なコンポーネントと依存関係をリスト化することで、サプライチェーンの可視化を支援します。したがって、ソフトウェアサプライチェーンのリスク管理を効率的に戦略化するには、SBOMとその範囲を理解する必要があります。
SBOM（ソフトウェア部品表）入門
ソフトウェア部品表（SBOM）とは、ソフトウェアを構成する様々な要素（オープンソースコンポーネント、ライブラリ、およびそれらの関係性を含む）の詳細なリストです。-ソースコンポーネント、ライブラリ、およびそれらの関係性を詳細に列挙したものです。その目的は、ソフトウェアがもたらすあらゆる要素をステークホルダーが徹底的に理解できるようにし、サイバーセキュリティの文脈における透明性を確保することにあります。ソフトウェアの開発・提供方法が変革する中で複雑性が増し、サイバー攻撃者が創造的な手法を考案する余地が生まれています。したがってSBOMは、アプリケーションに対する可視性を確保する不可欠な安全装置なのです。
なぜSBOMはサイバーセキュリティに不可欠なのか？
バイデン大統領がサイバーセキュリティ強化に関する大統領令でSBOMを強調したのは、悪意ある攻撃が標的とするサプライチェーンの脆弱性を認識していたためです。SBOMのようなネストされたリストは、ソフトウェアを構成要素に分解し、これらの脆弱性を特定するのに役立ちます。SBOMがサイバーセキュリティに不可欠な理由は以下の3点です：
- ソフトウェアの透明性: SBOMは、ソフトウェア内に古いコンポーネントやリスクの高いコンポーネントが存在するか否かを関係者が特定するのに役立ちます。例えば、古い暗号化ライブラリやLog4jのようなロギングフレームワークが存在する場合、セキュリティ専門家は関連するリスクを容易に特定できます。
- オープンソースコンポーネントの追跡：現代のソフトウェアソリューションの多くは、オープンソースコンポーネントやライブラリの統合を推奨しています。これらは必ずしもセキュリティ面が確認されているとは限らないため、SBOMは潜在的なリスクを追跡するのに役立ちます。
- 依存関係評価：一部のコンポーネント自体は目に見えるサイバーセキュリティ脅威をもたらさない場合でも、他のコンポーネントやライブラリへの依存関係が脅威となる可能性があります。したがって、SBOMはセキュリティ専門家がこれらの依存関係を調査し、セキュリティ上の脆弱性を特定するのにも役立ちます。
- サプライチェーンセキュリティ：サプライチェーン内における各種ソフトウェアコンポーネントのセキュリティ態勢に関する透明性は、潜在的な悪用に対する予防的なセキュリティ戦略の確立に寄与します。SBOMは、サプライチェーンセキュリティのためのこれらの戦略を可能にするために必要なすべての情報を購入者に提供します。
- コンプライアンス管理： SBOMはまた、ステークホルダーがソフトウェアソリューションとそのコンポーネントの規制コンプライアンスを評価するのに役立ちます。医療、フィンテック、防衛など、業界を問わず厳格な規制が存在する中、ソフトウェアコンポーネントのコンプライアンス違反は容易に検出されます。
SBOM（ソフトウェア部品表）の主要構成要素
- データフィールド: この要素は、正式なSBOM構造におけるソフトウェアコンポーネントの詳細を特定します。データフィールドには、サプライヤー名、コンポーネントバージョン、依存関係などが含まれ、潜在的なセキュリティ脆弱性の追跡を支援します。
- 自動化サポート: 自動化サポートは、SBOMデータの容易なナビゲーションとソフトウェアコンポーネントの機械可読性を可能にする必要なデータ形式を提供します。これはソフトウェアの迅速かつ自律的な監査を確保するための必須要素です。本報告書ではCycloneDX、SPDX、SWIDタグの3形式が許容されます。
- プロセス: これらは、SBOMの生成と管理をソフトウェアのセキュア開発ライフサイクルに組み込むのに役立つ必要な実践です。これらの実践は、SBOMの生成頻度、含まれるコンポーネントと依存関係の深さ、既知/未知の依存関係など、SBOMの様々な側面を規定します。
SBOM（ソフトウェア部品表）導入のメリット
A survey in 2022業界を問わず、53%の企業がSBOMを報告とコンプライアンスのための肯定的なツールであると報告しています。SBOMに対するこのような積極的な受け入れは、これらの法案が提供する本質的な細部への注意にのみ帰せられます。この細部への配慮こそが、SBOMによる多くの利点につながります：
- サプライチェーン全体の透明性：SBOMが記録するデータ項目と関連性は、ソフトウェアサプライチェーン全体の詳細な概要把握を支援します。ソフトウェアコンポーネントの異なるバージョン、ソフトウェア間の依存関係や互換性、セキュリティリスクをすべて容易に特定・分析できます。
- 一貫したセキュリティ態勢： SBOMが示す潜在リスクがあるにもかかわらず調達されたソフトウェアであっても、セキュリティ管理者は脆弱性に対してより備えることができます。SBOMに基づいて予防措置を講じ、セキュリティリスクを軽減することが可能です。
- コンプライアンス管理: SBOM自体が規制要件である一方、ソフトウェアの特定コンポーネントを対象とした厳格な規制への準拠を支援します。さらに定期的な監査により、コンプライアンス違反の特定にも寄与します。
- サードパーティ脅威: ソフトウェア内のオープンソースサードパーティコンポーネントがもたらすセキュリティリスクは、SBOMを活用することで容易に追跡可能です。ベンダーが意図的または無意識にセキュリティ脆弱性を見落とした場合でも、SBOMは原因となったサードパーティコンポーネントを特定するのに役立ちます。
SBOMの作成と管理方法とは？
必要な要素を全て含むSBOMを作成するツールが利用可能です。これらのツールは、ソフトウェアコンポーネントの分析結果を、SPDXやCycloneDXなど希望のSBOM標準形式に変換する本質的な機能を提供します。また、SBOM生成ツールは、セキュリティ脆弱性につながる可能性のある陳腐化した依存関係、ライセンスその他の要素を追跡する上でも関係者に役立ちます。これらのツールの動作手順は以下の通りです：
- ステップ1 – SBOMツールをCI/CDパイプラインに統合する：ソフトウェアコードの様々なコンポーネントを記録するため、SBOMツールはCI/CDパイプラインに統合する必要があります。これらのツールは、利便性に応じてオンプレミスまたはクラウド環境にインストールできます。
- ステップ2 – コードリポジトリのスキャン: 次に、ツールはコードをスキャンし、ソフトウェア内の様々なコンポーネント、ライブラリ、オープンソースフレームワークなどを特定します。
- ステップ3 – コード分析の変換: コードベースの全コンポーネントと依存関係のスキャンが完了すると、データは希望する標準SBOMフォーマットのいずれかに変換されます。
- ステップ4 – SBOMの生成: 変換されたSBOMデータは、最終的にXMLまたはJSON形式でエクスポートされ、さらなる検証が可能となります。NTIA報告書では、ソフトウェアコンポーネントの更新があるたびに新しいSBOMを生成することが義務付けられています。
SBOMの標準とガイドライン
SBOM生成の標準とガイドラインは、ソフトウェアコンポーネントやライブラリなどのネストされたリストを網羅しつつ、SBOM構造の統一性を維持するのに役立ちます。これらのガイドラインは、SBOMの自動生成と処理を促進するためにも必要です。
- システムパッケージデータ交換(SPDX): このオープン標準は、XML、JSON、YAMLなどのファイル形式に変換可能な可読性の高い言語構築を支援します。開発時および展開時に、作成情報、ファイル情報、パッケージ情報などの形式でデータを収集することで、異なるソフトウェアコンポーネントを効率的に概説できます。
- CycloneDX: このフォーマットは、セキュリティと自動化されたSBOM生成に特化してリリースされました。軽量な仕様により、ソフトウェアコンポーネント、外部サービスとの相互作用、およびそれらの間の関係を徹底的に分析できます。このオープンソース標準は、定期的に変更され再配布される動的なオープンソースコンポーネントにも適しています。
- ソフトウェア識別タグ（SWIDタグ）: ISOにより2012年に確立されたSWIDタグは、ソフトウェアコンポーネントのライフサイクル全体を追跡することを目的としています。これらのタグ（具体的にはプライマリ、パッチ、コーパス、補足タグ）は、ソフトウェアのインストール時に追加され、インストーラー、インストール、パッチ、およびソフトウェアコンポーネントのその他の側面に関する詳細情報を提供します。
SBOM（ソフトウェア部品表）の課題
SBOMの課題は、その高度に構造化され形式的な性質から、主に生成プロセスに起因します。具体的な課題は以下の通りです：
- SBOMツールの成熟度: 標準化されたSBOMフォーマットや構造に準拠するためツールは進化を続けていますが、依然としてギャップが存在します。さらに、優れたインターフェースや相互運用性の欠如などにより、これらのツールの操作は様々なステークホルダーにとって煩雑で困難な作業となっています。
- 導入と統合の遅れ： サードパーティベンダーの中にはSBOM義務を遵守していない企業も存在し、特にオープンソースソフトウェアにおけるSBOMリソースの導入・統合に遅れが生じている。
- SBOM生成の継続性：SBOM生成を継続的なプロセスとし、SDLCの異なる段階で発生させることは、依然として企業によって達成されていません。SBOMを扱うほとんどの企業にとってこれは目標ではありますが、多くの企業はまだこれを達成できていません。
- 追加のセキュリティ懸念:セキュリティ専門家の中には、包括的な脆弱性管理だけではデジタルエコシステムを外部脅威から保護できないと主張する者もいる。組織は対処すべき脆弱性を優先順位付けし、それに応じた戦略を立てる必要がある。SBOMを扱う際には複雑さが増すため、これを達成するのは困難な課題です。
効果的なSBOM活用のためのベストプラクティス
SBOMの生成自体は既に良い実践です。ベストプラクティスは、SDLC全体を通じて一貫して生成することです。これを実現し、サプライチェーンセキュリティにおけるSBOMの有用性を最大化するためのその他の実践例を以下に示します：&
- 早期生成と定期的な更新: 追加される依存関係を初期段階から記録するため、SBOMはSDLCのできるだけ早い段階で生成することが不可欠です。SBOMを定期的に更新することで、様々なソフトウェアコンポーネントのすべてのビルドとリリースが適切に明細書に記載されるようになります。
- SBOMの自動生成： 自動化サポートはSBOMの重要な要素であるため、SBOM生成のための自動化リソースを用意することは理にかなっています。自動化により、SDLC を通じて明細書を定期的に生成することも可能になります。
- 標準化されたフォーマット： SPDX や CycloneDX などのフォーマットは、セキュリティ上重要な SBOM データを確実に把握するために必要な深さを備えています。このような標準化されたフォーマットを使用することで、ビルの相互運用性と機械可読性が保証されます。
- バージョン管理：SBOMにおけるバージョン管理により、ソフトウェアコンポーネントで構築またはリリースされた新たな変更をセキュリティ評価のために容易に追跡できます。これにより、依存関係管理時のSBOMの説明責任も強化されます。
SBOMのユースケース
ソフトウェア脆弱性に関する重要な洞察を提供することが主な利点ですが、SBOMは多くのユースケースに対応可能です。その一部を以下に示します：
- ソフトウェアセキュリティ： SBOMはセキュリティチームがソフトウェアコードの脆弱な部分を正確に特定するのに役立ちます。チームはこれを利用して、サイバー攻撃者による悪用を受けやすいソフトウェアの箇所を探し出し、対処することができます。
- サプライチェーンセキュリティ： 米国や欧州の一部政府を含む多くの政府機関は、ソフトウェアサプライチェーンへのSBOMの組み込みを義務付けています。専門家は、間もなくエンドユーザーにも提供される可能性があると予測しています。&
- 調達容易性: サイバーセキュリティ事故を懸念する業界横断的な企業において、SBOMはソフトウェアソリューションを探す調達チームに確信感を与えます。提供される透明性により、両者間の信頼構築が促進されました。
- 開発の容易さ: SBOMにはソフトウェアコンポーネント間の依存関係と相互関係の詳細な内訳が含まれるため、開発者は既存の機能を妨げることなく新規コンポーネントの開発に取り組みやすくなります。
SBOMとSCAの違い
確かに、ソフトウェア部品表（SBOM）とソフトウェア構成分析（SCA）には、ソフトウェアの構成要素を理解するのに役立つ重複する機能があります。したがって、どちらを選択するかは、それらを使用したいソフトウェアライフサイクルの範囲によって決まります。
ビジネスリーダーがその選択を行うために知っておくべきことは以下の通りです：
| 観点 | SBOM | SCA |
|---|---|---|
| 焦点 | 多様なソフトウェアコンポーネントの記録と詳細なリスト生成に重点を置いています。 | コンポーネントの脆弱性管理と分析に重点を置いています。 |
| 提供内容 | コンポーネント、ライブラリ、依存関係の階層的なインベントリを提供します。 | リスクの高いコンポーネントに起因するセキュリティ脆弱性の特定と是正を提供します。 |
| 有用性 | 有用性の範囲はより広く、開発者、セキュリティチーム、調達チームなどをカバーします。 | 脆弱なコンポーネントに対処するためのSCAツールを必要とするセキュリティチームにほぼ限定されます。 |
BOMとSBOMの違い
BOMとSBOMは性質が非常に似ているため、混同されがちです。しかし、両者は全く異なる領域に属します。BOMが製造領域に関連する在庫管理であるのに対し、SBOMはソフトウェアエンジニアリング内で非常に特化した役割を担っています。意思決定者が両者を区別する方法は以下の通りです：
| 側面 | 部品表（BOM） | ソフトウェア部品表（SBOM） |
|---|---|---|
| 適用範囲 | ハードウェアや電子機器などの物理製品に適用される場合が多い。 | ソフトウェア製品とそのサプライチェーンに特化したアプリケーション。 |
| コンプライアンス | 製造または建設規制に焦点を当てたコンプライアンス。 | ソフトウェアライセンス、セキュリティ要件などに焦点を当てたコンプライアンス。 |
| ユーザー | 製造業者、サプライチェーン管理者。 | 開発者、セキュリティチーム、規制監査担当者。 |
結論
サイバーセキュリティに関する行政規制の一部として、SBOMはすでにソフトウェアライフサイクルにおいて重要な位置を占めています。ソフトウェアサプライチェーンのセキュリティは、SBOMが対応可能な多様なユースケースの一つです。分散型アーキテクチャ、コード化されたインフラ、広範なネットワークにより、ソフトウェアソリューションはこれまで以上に複雑なビジネスユースケースに対応しています。SBOMの主要コンポーネントと標準フォーマットは、UberやSolarwindsのようなインシデントを抑制する強力な味方となります。
本ブログでの議論に基づき、経営幹部やセキュリティ専門家はSBOM生成の自動化に関するベストプラクティスに従い、サプライチェーンセキュリティに活用できます。
SentinelOneは、SBOMなどの機能を活用してソフトウェアサプライチェーンを保護するお手伝いをします。当社の専門知識についてはこちらをご覧ください。
FAQs
ソフトウェア部品表（SBOM）とは、階層的なリスト形式で、様々なソフトウェアコンポーネント、ライブラリ、依存関係などを詳細に分解したものです。ソフトウェアコードの脆弱性のある部分（サイバー攻撃に悪用される可能性がある）を可視化することが重要です。
SBOMが提供する深い可視性により、セキュリティ専門家はソフトウェアサプライチェーン内の潜在的な脆弱性をより容易に発見し、効果的に対処できます。
行政規則に基づき、SBOMの主要要素にはデータフィールド、実践とプロセス、自動化サポートが含まれます。
効果的なSBOM戦略には、早期生成、定期的な更新、自動生成、CI/CDパイプラインとの統合といったベストプラクティスの遵守が不可欠です。
SBOMに最適な3つの標準は、SPDX、CycloneDC、およびSWIDタグです。
ソフトウェア部品表を生成するには、必要なフォーマットと出力に対応できる自動化ツールを活用できます。SentinelOneの専門家が支援いたします。