「SBOM」とは:ソフトウェアの安全性を確保するセキュリティの新たなスタンダード

情報セキュリティコラム

NECソリューションイノベータ株式会社 末松光章です。
近年、ソフトウェアサプライチェーンの弱点を狙う攻撃が増加する中、新たなセキュリティ対策として注目されているのがSBOMです。このコラムでは、SBOMの概要や必要性、導入メリット、課題について解説します。

本コラムでご紹介している内容のまとめ

SBOMとは

SBOM(Software Bill of Materials:エスボム)は、ソフトウェアのコンポーネントとそれらの依存関係をリスト化したデータです。これには、OSのパッケージ、ミドルウェア、アプリケーションのフレームワークなど、ソフトウェアを構成するすべての要素が含まれます。SBOMには、各コンポーネントの提供者、バージョン、作成者、ハッシュ値、識別子などの情報が含まれます。
また、SBOMではソフトウェアの構成要素の依存関係を明確にします。例えば、ソフトウェアXに、他社企業が開発したコンポーネントaを直接利用している場合、コンポーネントaの依存関係であるコンポーネントd、eもSBOMに記載されます。これにより、自分たちが直接認識できていないコンポーネントも含めて、利用している全てのソフトウェアコンポーネントを正確に把握することができます。

Component Name Supplier Name Version String Author Hash UID Relationship
Application Acme 1.1 Acme 0x123 234 Self
|--- Browser Bob 2.1 Bob 0x223 334 Included in
  |--- Compression
    Engine
Carol 3.1 Acme 0x323 434 Included in
|--- Buffer Bingo 2.2 Acme 0x423 534 Included in

引用:「Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)」 Table2[1]
表1:SBOMのイメージ

図1:ソフトウェアの依存関係のイメージ

ソフトウェアにとっての食品成分表!?

SBOMは、簡単に言えば、ソフトウェアにおける「食品成分表示」のようなものです。
食品成分表示が食品の原材料や産地、製造企業などを明らかにするのと同様に、SBOMもソフトウェアの構成要素を明確にします。例えば、マカロニサラダの成分表示には、マカロニは小麦粉を原材料とし、イタリア産であること、マヨネーズは卵を含むこと、ハムは豚肉であることなどが記載されています。この情報は、アレルギーを持つ人々にとって重要です。卵アレルギーのある人は、成分表示を通じて、マヨネーズに卵が含まれていることを知り、その食品の利用を避けることができます。また、特定の産地や企業に関連して気にすることがあれば、購入前にリスクを回避することもでき、購入後に自分の購入した食品に影響があったのかどうかを確認することもできます。
ソフトウェアにおいても、SBOMによってソフトウェアのコンポーネントの出所、製作者、バージョンなどが明らかにされることで、ユーザーや開発者はソフトウェアを安心して使用・選択することができるようになります。例えば、あるソフトウェアコンポーネントにセキュリティ上の脆弱性の問題があることが判明した場合、選定段階であればそのコンポーネントを含むソフトウェアを避けることができますし、既に利用しているのであれば、影響範囲を確認後、対処を検討することができます。このように、SBOMを参照することで、利用者はソフトウェアの構成情報を正確に把握することができ、リスクや問題を自分自身で判断することが出来るようになることが大きな特徴の一つです。

名称 マカロニサラダ
原材料名 マカロニ(小麦を含む、イタリア製造)、マヨネーズ(卵を含む)、 きゅうり、にんじん、玉ねぎ、ハム(豚肉を含む)、食塩
添加物 調味料(アミノ酸)、リン酸塩(Na)、酸化防止剤(V.C)、カゼインNa(乳・大豆由来)、発色剤(亜硝酸Na)
内容量 200g
消費期限 令和○年○月○日
保存方法 要冷蔵(10°C以下で保存)
製造者 ○○食品株式会社
○○県○○市○○区○○1-1-1

引用:経済産業省「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引Ver.1.0」[2]
表2:食品成分表のイメージ

SBOMの背景と動向

ソフトウェアサプライチェーンに対する攻撃の増加

近年、ソフトウェアサプライチェーンが複雑化し、オープンソースソフトウェア(OSS)の利用が一般化する中で、ソフトウェアに対するセキュリティ脅威が急激に増大しています。2020年に発生した米国SolarWinds社のインシデントでは、同社のネットワーク監視製品の正規アップデートにバックドアが仕込まれ、米国政府機関及び多数の企業の情報が窃取されるという被害が発生しました。2021年12月のApache Log4jの脆弱性を狙ったサイバー攻撃においても、Apache Log4jがログのポピュラーな部品であることから影響範囲が大きく、幅広い業界のサービス・製品で使用されていたために、世界中の多くの企業に影響を及ぼすこととなりました。こうした事例を引き金に、ソフトウェアサプライチェーンのセキュリティ強化を目的に様々な法規制等の整備が各国で活発化しています。

2021年の米国大統領令によるサイバーセキュリティ対策の強化

米国では、2021年5月にバイデン大統領が「大統領令:Executive Order on Improving the Nation’s Cybersecurity(国家のサイバーセキュリティ強化に関する大統領令)」[3]に署名しました。これに基づき、米国の政府機関が調達するソフトウェアにSBOMの提出が求められる方向で整備が進められています。

EUのサイバーレジリエンス法による要請

EUでは、2022年9月に草案が提出された「サイバーレジリエンス法(CRA:Cyber Resilience Act)」[4]において、デジタル要素を備えた全ての製品にSBOM作成等のセキュリティ要件への適合が求められています。この法案は2024年初めに発効し、2027年に施行される予定で、現在審議が進められています。

日本では経済産業省が牽引し、対応拡大

日本では、経済産業省を中心にSBOMに関する議論が進行中です。2023年7月には「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引Ver. 1.0」[2]が公開されました。また、医療機器や自動車など、様々な業界でSBOMの対応が検討され始めています。

SBOMのメリット

SBOMの有無による影響

ソフトウェアは、さまざまなサプライヤーから提供されたソフトウェアを使用し、それらが最終的なサービスや製品に組み込まれることで、何階層にも依存関係をもつ複雑な構造を持ちます。例えば、間接的に利用されるコンポーネントに致命的な脆弱性が見つかった場合、SBOMがないとその影響を受けるソフトウェアを特定するのが難しくなります。通常の IT 資産管理の対象では、直接参照できる上位のソフトウェア部品のみを管理しており、内部でどのようなソフトウェアが利用されているかまでは把握できていないことが多いです。SBOMを活用していない場合、ソフトウェア部品の提供企業からの連絡を待って対応するしかなく、それによって対応が遅れる可能性があります。
しかし、SBOMを活用してソフトウェアの構成要素を明確にしている場合は、間接的に利用するソフトウェアを含むすべての構成要素が明らかになっているため、あるソフトウェアにリスクの高い脆弱性の問題が発覚した際に、自社で使用しているソフトウェアに脆弱性を持つコンポーネントが使用されているかどうかを迅速に調査し、もし問題があれば、すぐに対応を行うことが可能となります。

図2:SBOMなしのイメージ
図3:SBOMありのイメージ

SBOM導入による効果

SBOM導入によるメリットは2つあります。

1. 透明性の確保

SBOMにソフトウェアの構成情報(間接的な依存関係)を含めてソフトウェア成果物とともに流通させることにより、ソフトウェアを利用する企業はSBOMを基に正確なソフトウェア構成を確認できるため、ソフトウェアの脆弱性や問題点の特定が早くなります。

2. 追跡可能性(トレーサビリティ)の向上

何か問題やリスクが発生した際に、SBOMを通じてサプライチェーン全体の影響範囲を迅速に確認できます。例えば、特定のソフトウェアコンポーネントに問題が発生した場合、SBOMを参照することで影響を受ける可能性のある範囲を特定し、迅速な対応を行うことができます。

SBOMを導入する際の課題

SBOMを導入する場合は以下の点に留意して対応する必要があります。

1. 対応ツールの出力フォーマットに差がある

現状、SBOMの記載方針が統一されておらず、異なるツール間でSBOMの出力フォーマットに差異が見られます。例として、同じOSSであっても異なる名前(識別子)で記載されることがあり、結果として脆弱性チェックやライセンスの把握が困難になる可能性があります。そのため、SBOMの生成や活用をする際には、SBOM対応ツールの出力フォーマットが利用目的に適するかどうか事前に確認する必要があります。

2. 記載項目の標準化が不足している

SBOMの記載項目に関する標準化は、NTIA(米国商務省の電気通信情報局)が定める最小要件に準拠する方向で進められていますが、依存関係の深さ、ハッシュ情報、ライセンス情報の扱いといった一部の項目では、統一された基準が確立されていません。そのため、業界や標準化機関の動向を注視するとともに、顧客や関係企業との間で記載方針について事前に確認と調整をすることが重要です。

3. 対応コストが増加する懸念がある

SBOMの生成や管理、脆弱性やライセンス対応、問い合わせへの対応などにより、製造元の負担が増加することが予想されます。ただし、JSON形式などの標準化されたフォーマットにより機械処理可能なSBOMを導入することで、これらの作業を一部自動化し、管理・運用にかかるコストを低減することができます。

SBOMは日本でも義務化される?

今後、政府や業界、標準化機関によって統一された記載方針が策定されることにより、国内においても政府調達や重要インフラの分野を中心にSBOMの提出要求が進む可能性があります。統一された記載方針の策定によって、SBOMの作成や共有が容易になり、幅広い業界や企業での採用が進むと予想されます。これにより、ソフトウェアのサプライチェーン全体の透明性が向上し、セキュリティ脅威に対する対応力が強化されることが期待されます。
加えて、SBOM関連技術の進化も期待されます。ソースコードの管理からリリースまでの各工程を一連化して自動化する「CI/CDパイプライン」などの開発基盤においては、SBOMの生成、管理、分析を自動化するツールの開発が進んでおり、効率的かつ正確なSBOMの作成と運用が可能になることが期待されています。さらに、AIを利用した分析ツールとの統合により、脆弱性の迅速な特定や影響範囲の分析が可能になることも予測されます。
現在、国内でのSBOMに関する動向や企業の対応は始まったばかりですが、政府や業界、標準化機関の動きを注視しながら対応を進めていく必要があります。

まとめ

本コラムでは、SBOMの概要や動向について紹介しました。ソフトウェアの透明性とセキュリティを強化する上でSBOMの役割は今後ますます重要になると予想されます。SBOMの導入や運用に関してご質問やご相談があれば、お気軽にお問い合わせください。

掲載日:2024年3月27日

執筆者プロフィール

末松 光章(すえまつ みつあき)

所属:NECソリューションイノベータ株式会社
ソフトウェアサプライチェーンやクラウドネイティブセキュリティの専門家として先端技術を活用したセキュリティ対策の設計、セキュリティリスクアセスメント、セキュリティ教育などの業務に従事。