ITシステムと組み込みソフトウェアにおけるSBOM対応の違い

本記事は2025年2月25日にZDNet Japan（https://japan.zdnet.com/article/35229599/）にて掲載されたものです。

サイバーセキュリティ対策の強化が求められる昨今、特にソフトウェアレベルでの資産管理や脆弱（ぜいじゃく）性管理といったSoftware Bill of Materials（SBOM：ソフトウェア部品表）対応が求められるレギュレーションが増えています。しかし、一言でSBOM対応といっても、製品に組み込まれているソフトウェアと、自社などのITシステム内で利用されているソフトウェアでは、求められる要件が異なります。また、各種オープンソースソフトウェア（OSS）やパッケージ管理システムなどの普及により、SBOMの抽出（スキャン）がしやすいかどうかでも管理手法が変わってきます。

本記事では、SBOM対応において、自社のITシステムや製品に組み込まれているソフトウェアはどのような要件が求められており、どのように管理をすべきか、ITシステムと組み込みソフトウェアのSBOM対応の相違点を中心に解説します。

まず、ITシステムと製品に組み込まれているソフトウェアのサイバーセキュリティにまつわるレギュレーションで、SBOMやソフトウェアの脆弱性管理に関連する部分を確認します。

ITシステムに関しては、現在稼働しているITシステム上のソフトウェアのリスクを確認する必要があります。現在稼働しているアプリケーションやサーバーなどの実環境をスキャンしてソフトウェアの利用状況を可視化するツールで運用できれば、SBOMをファイルとして管理することや、SBOMファイルのやりとりが不要となります。

​​​​​​​

組み込みソフトウェアが含まれる製品に関しては、ITシステムと異なり、End Of Life（EOL）を迎えていないサポート対象の製品バージョンが複数存在します。そのため、サポート対象の製品バージョン別に組み込みソフトウェアのSBOM情報を管理し、脆弱性管理する必要があります。

そもそもEOLなどサポート期間を明確に定義していない製品が多いため、製品バージョンごとにEOLを明確に定義し、顧客に通知するなどの要件もレギュレーションに含まれています。また、ソフトウェアサプライチェーンが複雑であることが多く、サプライチェーンの企業の間で、SBOMファイルなどによるSBOM情報の共有が必須です。

相違点、切り分けポイントのまとめ

ITシステムや組み込みソフトウェアのSBOM管理とその脆弱性管理に関する運用を設計する際には、下記のポイントを見極め、運用設計やツール選定を検討すると良いでしょう。

バージョン単位でのSBOM管理が必須か、単一バージョンのSBOM管理で良いか

組み込みソフトウェアの場合は、メーカー側がサポート対象の複数バージョンについてのリスクを管理する必要がありますが、ITシステムやインターネットサービスの場合は、稼働しているシステム、ソフトウェアが一つなので、最新の稼働バージョンのSBOMやリスク管理ができれば問題ありません。

サプライチェーン内でSBOMファイルをやり取りする必要があるか、ソフトウェアのソースコードや実環境のスキャンによりSBOM生成が可能か

ソフトウェアのソースコードや実環境のスキャンでSBOMを生成できる場合は、サプライチェーン内でのSBOMファイルのやりとりは必要ありません。

しかし、サプライチェーンの中でSBOMファイルを受け渡さなければいけないシーンがある場合は、SBOMのエクスポート／インポート機能を有するツールが必要です。サプライチェーンの中で異なるツールによって作成されたSBOMを取り込む場合、脆弱性などのリスク検出が上手くできないケースがほとんどです。そのため、SBOMの形式や仕様、利用ツールなどをサプライチェーン内で統一する必要があります。

パッケージ管理システムを利用しているかどうか

開発しているソフトウェアやシステムでパッケージ管理システムを利用している場合は、システムが管理しているソフトウェアやバージョンが確定しているため、ツールなどによりSBOMの生成が可能です。

一般的に、組み込みソフトウェアでは、パッケージ管理システムを利用しないソフトウェア開発の慣習があり、スキャンツールによるソフトウェア抽出は容易ではありません。実行可能なバイナリーファイルをツールを利用しても解析しても誤検知などが多いため、手動でSBOMを確認、修正をする必要があります。

受託開発か、自社製品や自社システムの開発運用か

自社製品や自社システムの開発の場合は、自社が管理するソフトウェアやシステムの脆弱性管理を行うためにSBOM対応を行うことになります。しかし、受託開発（クライアントから仕事を受注してオーダーメイドでシステムやソフトウェアを開発する）の場合、そのソフトウェアやシステムはクライアントのものになります。

受託開発している企業には、SBOMファイルの提出は求められますが、その後の脆弱性などの責任はクライアントが持つことになるため、脆弱性などのリスク管理の機能は必要ない可能性があります。

以上のように、一言でSBOM対応といってもさまざまなパターンがあり、担当者は自社の実態に応じて、SBOM対応の要件を決める必要があります。これからSBOM対応が求められる企業の担当者は、本記事を参考に自社のSBOMの要件の洗い出しやツール選定にお役立てください。