SBOM普及の本格化～製品セキュリティにおけるSBOMを使った脆弱性管理～

2022-05-09

製品セキュリティにおける脆弱性管理とその課題

自動車、家電製品、医療機器、防衛装備品、航空宇宙関連機器などの組み込み機器・製品群のIoT化が進んでいます。これに伴い、IoT機器などコネクテッド製品へのサイバーセキュリティ対策を検討する必要がありますが、その際には「研究開発」「製造」「市場利用」「廃棄」の製品ライフサイクル全体を包括したセキュリティプロセスを考える必要があります。特に、ユーザーが所有・利用する製品に対しては、継続的なセキュリティ確保が必要であり、対象製品に影響を与えかねない脆弱性を管理し、適切に対応する必要があります。

脆弱性を管理するには、日々発見・報告される脆弱性情報を収集し、それらが管理対象の製品に関連するかの該否判断をすることが求められます。特に、製品内でオープンソースソフトウェア（以下、OSS）を活用している場合、大量の脆弱性情報が報告されたり、頻繁にアップデートされることで影響を受けるバージョンを把握する必要があったりするなど、該否判断を難しくする要因が増えてきます。

このような脆弱性管理における課題への対応策として注目されているのが、ソフトウェアに含まれるコンポーネントを管理する仕組みであるソフトウェア部品表（SBOM）です。

SBOMを活用した脆弱性管理

製品セキュリティの分野におけるSBOMの基本的な考え方は、当該製品に含まれるソフトウェアをデータベース化して管理し、研究開発・製造・市場運用の各フェーズ共通で参照できるようにするものです。これにより迅速かつ網羅的な脆弱性対応が可能になることが期待されています。

SBOMを作成するにあたっては、ソフトウェアの名称やバージョン情報など、ソフトウェアが有する特徴が含まれるようにします。自社で利用するSBOMのフォーマットを定め、必要な要素を入れ込むことで、脆弱性への該否判断の機械化や自動化を進めることができ、OSSを多く活用する製品でも効率的に脆弱性対応を推進することができるようになります。

なお、SBOMについては、ISOなどのガイドラインで標準的なフォーマットが提案されています。現在に至るまで最も広く利用され、事実上の業界標準であったSoftware Package Data Exchange（以下、SPDX）と呼ばれる仕様が、2021年9月にISO／IEC 5962として公開され、国際標準フォーマットとして認められています。

SBOMのイメージ（構成要素）

サプライヤー名	依存関係
コンポーネント名	SBOM作成者名
バージョン情報	タイムスタンプ
その他の識別子

名前	説明
サプライヤー名	コンポーネント（製品、ソフトウェア、プログラムなど）の作成者
コンポーネント名	サプライヤーによって定義されたコンポーネントの名前
バージョン情報	コンポーネントのバージョン識別情報
依存関係	ソフトウェア等の包含関係を表す情報
SBOM作成者名	SBOMデータの作成者
タイムスタンプ	SBOM作成・更新時の時刻情報
その他の識別子	必要に応じて使用できる一意の識別子

製品セキュリティにおけるSBOMライフサイクル

SBOMを製品セキュリティのライフサイクル全般で活用するためには、SBOMの作成・更新・利用といったライフサイクルを考慮し、既存の製品セキュリティ活動に取り込む必要があります。

SBOMの作成は、基本的には対象製品の設計・実装プロセスなど、上流工程で開始することが推奨されます。設計や実装のプロセスなど、ソフトウェアの実装が始まる前に、利用するソフトウェア・バージョンを一覧化し、SBOMとして管理し始めることで、適切なセキュリティ活動を導出することができるためです。

SBOMの作成を支援する製品もいくつか登場しており、中には設計・実装が完了した後に、できあがった実行ファイル（バイナリファイル）を検査するものもあります。製品内でOSSを利用する場合、OSS自体が別のOSSやソフトウェアを利用していることもありますが、それらをチェックするためにはツールを活用することが効果的です。ただし、利用するソフトウェアは設計時に事前に把握すべきであり、ツールは活用しつつも、設計時に利用するソフトウェアに関する情報をSBOMとして管理するプロセスを構築することが健全と言えます。

SBOMの完成後は、主に、脆弱性管理での活用を開始します。脆弱性管理にあたっては、日々製品に関連する脆弱性情報を収集する必要があります。ここで、作成したSBOMを使って収集すべき脆弱性情報を絞り込むことが効率化への第一歩です。SBOMを使って脆弱性情報を収集するには、抜け漏れが無いようにすること、膨大な量が集まってしまった際の対処方法を準備すること、という2つの観点が重要になります。特に、OSSを多く活用している製品の場合、ソフトウェア・バージョン名だけに基づいて関係する脆弱性情報を集めると、情報量が膨大になってしまいます。そのため、製品特性やソフトウェアの設定情報なども踏まえ、対象を適切に絞り込むことが重要です。例えば、「Wi-Fi機能をもっていない」「画像表示デバイスをもっていない」「データ連携するデバイスが明確である」といった設計情報をもとにすると、適切に絞り込むことができます。この観点からも、設計時からSBOMを作成することが重要であることが分かります。

脆弱性の修正対応など、ソフトウェアを更新する際にはSBOM情報も同時に更新することが必要です。ここで注意すべきは、最新製品に含まれるソフトウェアのみをSBOMとして管理するのではなく、過去の製品・バージョンのソフトウェアもSBOMで管理し続けることが必要となる点です。OTAが普及し、IoT製品もソフトウェアアップデートすることが常識となったとしても、エンドユーザーがアップデートを実施しないケースも考えられるため、過去の製品も情報として管理し続ける必要があります。このようなことから、SBOM管理において、全ての製品バージョンに含むソフトウェアをまとめた1つのSBOMを作るより、製品バージョンごとにSBOMを作成する、ないし、製品バージョンと結び付けられるようなフォーマットを作成し、管理することが適切です。この活動を推進するにあたっては、CI（Continuous Integration：継続的インテグレーション）などとも連携し、ソフトウェアの更新作業を自動化して、SBOMを作成するのが効果的です。

SBOM活用における今後の課題

SBOMを活用することで製品セキュリティにおける脆弱性管理を高度化、そして効率化することができます。

一方で、製品セキュリティにおけるSBOM活用には超えるべき課題があります。それはサプライチェーン全体でSBOMを活用することです。製品開発は1社のみで完結することはほぼなく、複数の部品メーカーに委託し、それらを組み合わせることで製品が完成します。各部品もソフトウェアを含むため、サプライチェーン全体を通じた統一的なSBOM利用が必要となります。

次回は、このサプライチェーン全体を通じたSBOM活用について解説します。