SBOM (Software Bill of Materials) は、ソフトウェアを構成するコンポーネントの一覧表です。ソフトウェアサプライチェーンのセキュリティ強化に不可欠なSBOMについて、その定義、作成方法、フォーマット、活用方法、導入メリット・デメリットなどを解説します。
SBOM（Software Bill of Materials）とは？
SBOM（Software Bill of Materials）とは、ソフトウェアに含まれる構成要素を詳細に記載したリストのことです。いわばソフトウェア部品表であり、各コンポーネントの名称やバージョン、依存関係などを明確に把握するために作成されます。
2021年のColonial Pipeline社への攻撃の後、2021年5月に米国政府が発表した大統領令14208号では、『ソフトウェア開発者は製品に含まれるオープンソースやサードパーティーのソフトウェアが最新でかつ、脆弱性がないことを確認できる』方法として、この考えを提唱しました。
ソフトウェアの開発・運用プロセスにおいて不可欠な情報源であり、特にセキュリティやコンプライアンスの観点から重要性が高まっています。使用しているオープンソースやライブラリを正確に把握できるため、脆弱性の特定やライセンス管理の効率化に有効です。
業務システムにおけるセキュリティ対策としても、SBOMは欠かせない要素です。ソフトウェアの透明性を高めサプライチェーン全体のリスクを可視化する手段として、SBOMの導入が企業に求められています。
ここでは、SBOMの定義や目的、SBOMが必要な理由を詳しく解説します。
SBOMの定義と目的
SBOMはソフトウェア製品に含まれるすべてのコンポーネントをリスト化したものであり、各コンポーネントのバージョンや依存関係、ライセンス情報などを含みます。
SBOMを導入する意味は、ソフトウェア構成の可視化により、透明性を確保することでセキュリティリスクを低減する体制を整えることです。SBOMを用いることで脆弱性のあるコンポーネントを迅速に特定し、必要な対策を講じることが可能になります。
また、ライセンス違反のリスクを回避し、コンプライアンスを維持するためにも役立ちます。企業におけるセキュリティ対策の一環としても、SBOMは業務の安定性やサービス品質の維持に直結する重要なツールだといえるでしょう。
ソフトウェアコンポーネントのリスト
運用技術（OT）ソフトウェアは、デジタルデバイスの制御を自動化します。簡単なソフトウェアでスイッチのオン・オフができます。さらに多くのスイッチを切り替えたり、モーターを動かしたり、サーボを制御したりするには、ソフトウェアモジュールを連動させて、より強力なプログラムを構築します。下流のモジュールは上流のモジュールに依存しているため、このチェーン（連鎖）が依存関係ツリーを形成します。
依存関係ツリー
プログラミング言語では、開発者はアプリの構築に必要なあらゆる依存関係のリストを要件ファイルに含めておく必要があります。理論的には、この依存関係リストがSBOMになります。実際には、要件ファイルは、詳細情報の欠落、要件の他のリストへの参照、および一貫性のないフォーマットが原因となり、解読が困難になる場合があります。
SBOMが必要な理由
SBOMが必要とされる背景には、ソフトウェアの複雑化とサイバー攻撃の増加があります。
現代のソフトウェアは多くのオープンソースコンポーネントを含んでおり、管理が不十分だと脆弱性が生じる可能性があります。さらに、サイバー攻撃が高度化する中でソフトウェアの透明性を確保することは、サイバーセキュリティ対策におけるリスク管理の基本です。
SBOMを導入することで、脆弱性のあるコンポーネントを迅速に特定し適切な対策を講じることができるため、サイバーセキュリティの強化に繋がります。また、SBOMはコンプライアンス遵守の観点からも重要であり、ライセンス違反を未然に防ぐことで法的リスクを軽減できます。
企業の運営において、SBOMはサイバーセキュリティとコンプライアンスの両面から不可欠な要素だといえるでしょう。
「SBOM」を活用したサプライチェーンの脆弱性リスク管理の必要性
サプライチェーンへの攻撃の防御手段になるであろうと最近広く注目を集めているセキュリティツールの1つ、#SBOM（Software Bill of Materials）をご存じですか？
SBOMの作成方法
SBOMはソフトウェアの構成要素を明確にし、セキュリティリスクに対応するための重要な手段です。SBOMの導入は、ソフトウェア開発における透明性を高め、脆弱性の特定や管理を容易にします。
ここでは、SBOMを作成・導入するための具体的な方法を紹介します。
ツールを利用した作成
専用のツールを利用すると、SBOMを効率良く作成可能です。ツールを使用することで手動での作業を大幅に削減し、正確かつ迅速にSBOMを生成できます。多くのツールはソフトウェアのコードベースをスキャンし、自動的に構成要素をリスト化します。これにより、依存関係やライセンス情報、既知の脆弱性を含む詳細な情報を提供できるのです。
なお、SBOM作成ツールを導入する前に、対象となるソフトウェアについて基本的な情報を整理しておくことが重要です。たとえば、使用している開発言語（Java、Pythonなど）、コンポーネントの形態（ライブラリ、アプリケーションなど）、開発環境（Visual Studio、Eclipseなど）、ビルドツール（Jenkins、Mavenなど）などを把握することで、ツールとの対応状況や適用可能な範囲を正しく見極めることができます。
さらに、SBOMのカバー範囲を明確にするためには、ソフトウェア構成を俯瞰できる図を作成することが効果的です。自社開発分、取引先による開発分、オープンソース利用分といった区分を整理しておくことで、SBOMに反映すべき要素やリスク管理の対象が明確になります。
例えば、オープンソースのSBOM作成ツールとしては、SyftやCycloneDX CLIが広く利用されています。これらのツールは、コマンドラインインターフェースを通じて簡単に操作でき、CycloneDXをはじめとしたさまざまなフォーマットでSBOMをエクスポート可能です。
ツールを利用してSBOMを作成する手順は次の通りです。
- ツールをインストールする
- 対象のソフトウェアプロジェクトのディレクトリを指定してスキャンを実行する
- SBOMをJSONやXML形式で出力する
上記の手順で生成されたSBOMは、JSONやXML形式で保存され、他のシステムやプロセスと連携できます。
このようなツールを活用することで、SBOMの作成はより効率的かつ正確になります。特に大規模なプロジェクトにおいては、手動での作成に比べて時間と労力を大幅に削減できるため、ツールの導入を検討する価値があるでしょう。
手動での作成
SBOMを手動で作成する方法は、特に小規模なプロジェクトや特定の要件に応じたカスタマイズが必要な場合に有効です。手動での作成は、プロジェクトの詳細を深く理解し、必要な情報を正確に反映させることが可能です。
手動でSBOMを作成する際は、まずソフトウェアの構成要素をすべてリストアップします。この際、各コンポーネントのバージョン情報、ライセンス、依存関係を明確に記載することが重要です。次に、これらの情報を整理し文書化します。スプレッドシートやExcel、ドキュメント形式でまとめるのが一般的です。
手動作成の利点として、ツールでは検出できないカスタムコンポーネントや特殊なライセンス条件を詳細に記録できる点があります。しかし、手動での作業は時間がかかることに加え、人的ミスのリスクも伴います。そのため、手動での作成を行う際は、定期的なレビューや複数人での確認作業を行うとよいでしょう。
ツールでは対応しきれない細部にまで注意を払うことができるため、特定のニーズに応じた詳細なSBOMを必要とする場合には手動での作成が適しています。
SBOMのフォーマット
SBOMのフォーマットには複数の種類があります。いずれもSBOM Fileとして出力される形式であり、それぞれの特徴と利点を知っておくことで、自社に合うフォーマットの選定が可能です。ここでは、代表的なSBOMフォーマットであるSPDX、CycloneDX、SWIDについて詳しく説明します。
SPDX
SPDX（Software Package Data Exchange）は、SBOMの主要なフォーマットの一つであり、主にソフトウェアのライセンス情報を中心に設計されています。オープンソースコミュニティによって開発され、ライセンス情報の共有を容易にすることを目的としています。
SPDXは、ライセンスの互換性やコンプライアンスの確認を効率化し、法的リスクを軽減するのに有効です。JSONやYAMLなどの形式で記述され、機械可読性と人間可読性を両立しているフォーマットでもあります。
3 The SPDX Team, “spdx-examples / example1 / spdx / example1.spdx”, SPDX, Aug 26 2021, アクセス日 2022年5月9日
CycloneDX
CycloneDXはセキュリティに特化したSBOMフォーマットで、脆弱性管理を重視しています。CycloneDXにはソフトウェアの構成要素だけでなく、脆弱性情報やリスク評価も含めることができます。
JSONやXML形式で提供され、他のツールとの連携が容易である点も特徴です。
SWID
SWID（Software Identification）は、ISO/IEC 19770-2で規定された国際標準フォーマットで、ソフトウェア資産管理を目的としています。ソフトウェアのインストール情報を詳細に記録し、資産管理やライセンスコンプライアンスを支援します。
SWIDは企業や組織がソフトウェアの使用状況を正確に把握し、ライセンス違反を防ぐための重要な手段です。XML形式で提供され、他の管理ツールとの統合が容易なのも特徴です。
SBOMツール
SBOMを作成するためのツールは多岐にわたりますが、代表的なものとしてSyft、FOSSA、Black Duckなどがあります。これらのツールはソフトウェアの構成要素を自動的に解析し、SBOMを生成する機能を備えています。
Syftは、オープンソースのSBOM生成ツールで、軽量かつ高速な解析が可能です。FOSSAは、ライセンスコンプライアンスに特化しており、企業の法令遵守を支援します。Black Duckは、脆弱性管理に強みを持ち、セキュリティリスクの早期発見をサポートします。
SBOM作成に専用ツールを導入することで作業の効率が高まり、同時にセキュリティ対策やコンプライアンス対応の精度向上が期待できるのです。
SBOMの活用方法
SBOMを導入することで、セキュリティ関連の管理業務が効率化されます。ここからは、SBOMの活用方法を具体的に紹介します。
脆弱性管理
SBOMを活用することで、ソフトウェアに含まれるすべての構成要素を正確に把握することが可能です。そのため、SBOMをもとに脆弱性情報と照合することで、各コンポーネントに既知の脆弱性が含まれていないかを迅速に確認し、必要な対応を速やかに実施できます。
オープンソースを多用する環境においても、SBOMの導入により脆弱性を含むコンポーネントを迅速に洗い出すことが可能です。脆弱性が発見された際には、即座にパッチを適用するなどの対策を講じることもできるようになります。そのため、システム全体のセキュリティを強化し、安定した業務運用を維持できます。
ライセンス管理
ソフトウェアに関連する法的リスクを防ぐためには、SBOMを用いたライセンスの適正な管理が重要です。SBOMには、各構成要素のライセンスに関する詳細な情報が記録されています。SBOMを用いて各コンポーネントのライセンス条件を確認し、使用条件に違反していないかをチェックすることでライセンス違反を未然に防げます。
例えば、GPLやMITライセンスなど多様な条件のライセンスが共存している場合には、SBOMを活用することでそれぞれの条件を正しく理解し、必要な対策を実施できるでしょう。これにより、ライセンス違反による法的トラブルを回避し、安心してソフトウェアを利用することが可能になります。結果として、企業の運営における法的リスクを低減し、信頼性の高い製品を提供することができます。
セキュリティリスク評価
SBOMを活用すれば、システムに内在するセキュリティ上のリスクを効率よく把握・評価することが可能になります。各コンポーネントのセキュリティ状況をSBOMに基づいて分析することで、リスクの高い箇所を特定し、潜在的な脅威を可視化できます。
例えば、過去にセキュリティ上の問題が確認されたコンポーネントが含まれている場合でも、SBOMを用いることで現在の使用状況を確認し、必要であれば代替手段の検討が可能となるのです。つまり、SBOMを活用する事で、潜在的なセキュリティリスクを事前に評価し適切な対策を講じることが可能です。そのため、企業全体のセキュリティレベルを向上させ、安心して業務を遂行できます。
SBOM導入のメリット・デメリット
SBOMの導入には多くのメリットがありますが、一方でデメリットも存在します。
まず、SBOM導入のメリットとして挙げられるのは、セキュリティの向上です。SBOMを活かすことでソフトウェアに含まれる脆弱な要素を迅速に検出し、適切な対応を行うことが可能となります。そのため、サイバー攻撃のリスクを大幅に低減できるでしょう。また、ソフトウェアに適用される各ライセンスを整理・管理するためにSBOMは有用であり、企業の法令遵守体制を支える仕組みとしても機能します。さらに、SBOMはソフトウェアのアップデートやメンテナンスを効率化し、生産性の向上にもつながります。
一方で、SBOM導入にはデメリットが存在するのも事実です。まず、SBOMの作成や管理には時間とコストがかかります。特に、既存のシステムにSBOMを導入する際には初期設定やデータの整備が必要なため大きな負担となる場合があります。また、SBOMの情報が外部に漏洩した場合、逆にセキュリティリスクを増大させることにもなりかねません。そのため、SBOMの管理には厳重なセキュリティ対策が求められます。
総じて、SBOMの導入はセキュリティ対策において多くの利点をもたらしますが、導入に際してはコストや管理の手間を考慮する必要があります。適切な計画と管理体制を整えることでSBOMのメリットを最大限に活用し、セキュリティを強化可能です。
SBOMでの課題
1. ソフトウェアの命名基準
ソフトウェア開発で最も難しいタスクの1つが、ソフトウェアの命名です。統一された命名基準がない場合、依存関係をどのように比較すればよいのでしょうか？CVEやNVDなどの脆弱性データベースと依存関係をどのようにマッピングすればよいのでしょうか？問題は、ソフトウェアの基準が多すぎることであり、統一された基準を作る場合にもコンセンサスが必要になります。
2. ソフトウェアの依存関係
ソフトウェアの依存関係の検出においては、多くの問題が潜んでいます。オープンソースソフトウェアは公開リポジトリで公開されており、プログラミング言語ごとに異なるリポジトリが存在します。独自開発のソフトウェアは、一般に公開されていないことが多く、一部のコードは動的に生成されています。SaaSやクラウドベースのソフトウェアは、データの取り込みや共有においてはAPIに依存しています。
3. アンチSBOMの脅威
SBOMでは防げない脅威モデルがあります。たとえば、攻撃者がソース・コード・リポジトリを破損させた場合（2020年のSolarWinds攻撃で見られたように）、破損したSBOMが生成されてしまいます。SBOMがあっても、未承認のアップデートを防止し、現場に入ってきたデバイスをスキャンできるOTネイティブな防御は、施設をセキュアに保つための基本要件です。
まとめ
ソフトウェアに含まれる構成要素を明確にし、セキュリティとライセンスの問題を把握する上で、SBOMは欠かせないツールです。企業はSBOMを活用することで脆弱性への迅速な対応やコンプライアンス強化が可能になり、信頼性の高いシステム運用を実現できます。
導入にはコストや運用の手間も伴いますが、計画的な体制整備によりその効果を最大限に引き出すことができるでしょう。
TXOneにまずお気軽にご相談ください。
製造業界のサイバーセキュリティ課題は常に変化しています。TXOneはお客様のサイバーセキュリティに関する課題について最適なOTセキュリティソリューションが提供できるよう、いつでもお手伝いさせていただきます。お問い合わせ内容を確認後、担当者より迅速にご連絡致しますので、お気軽にお問合わせください。
