無料セキュリティ対策に不安がある企業必見！「セキュリティ対策無料相談窓口」

多くのソフトウェアおよびアプリケーションの構成には、OSSやプロプライエタリソフトウェアなどの「部品」が含まれています。多様な部品が組み込まれたソフトウェアの構成は複雑化しており、迅速な脆弱性対応を阻害する恐れがあります。そこで重要視されているのが、SBOM（Software Bill of Materials）です。この記事では、SBOMについて詳しく解説します。

SBOMとは

SBOM（Software Bill of Materials：エスボム）とは、特定ソフトウェアの構成を可視化した一覧表です。特定ソフトウェアを構成する「OSS（オープンソースソフトウェア）」や「プロプライエタリソフトウェア」のコンポーネントや依存関係、ライセンス情報をすべて記載します。

近年、多くのソフトウェアには、有償のプロプライエタリソフトウェアやソースコードを無償公開しているOSSが多数組み込まれています。SBOMを作成することで、1つのソフトウェアを構成する情報の可視化が可能です。ライセンス管理や脆弱性対策、リスク管理を強化できるため、SBOMを用いる企業が増えています。

SBOMの構成要素

SBOM作成時の指標として参考になるのが、2021年7月にNTIA（米国商務省電気通信情報局）が発表したガイドライン（※1）です。同ガイドラインは、SBOMのMinimum Elements（最小限の構成要素）として、次の3要素と各要件を挙げています。

※1 参照：NTIA（米国商務省電気通信情報局）「The Minimum Elements For a Software Bill of Materials (SBOM)」

SBOMが注目された背景

SBOMが急速に注目を集めている理由として、2021年に起きた下記2つのできごとが大きく影響しています。

1. 米国大統領令によるSBOMへの言及
2. Apache Log4jの脆弱性「Log4Shell」の発見

それぞれの詳細を説明します。

1.米国大統領令によるSBOMへの言及

2021年5月、アメリカのバイデン大統領はサイバーセキュリティ強化に関する大統領令に署名（※2）しました。同大統領令ではソフトウェアサプライチェーンのセキュリティ強化に対して述べ、SBOMへも言及しています。この言及がきっかけとなり、SBOMの重要性が注目されるようになりました。

2.Apache Log4jの脆弱性「Log4Shell」の発見

2021年12月、OSSライブラリ「Apache Log4j」の脆弱性「Log4Shell」が発見されました。簡潔にまとめると、Log4Shellは「容易に悪用できる上、深刻な攻撃を実行できてしまう」重大な脆弱性です。加えて、Log4Shellは膨大なソフトウェアに組み込まれており、多くの企業への影響が危惧されました。

とりわけ問題となったのが、「自社のソフトウェアにApache Log4jが使われているのかがわからない」企業が多かった点です。Log4Shell対策をすべきなのかがそもそも判断できず、迅速に対応できない企業が相次ぎました。こうした事態を受け、特定ソフトウェアの構成部品を素早く確認できるSBOMの必要性が高まったわけです。

※2 参照：THE WHITE HOUSE「Executive Order on Improving the Nation’s Cybersecurity」

SBOMはサプライチェーンのセキュリティ強化に有効

SBOMは、ソフトウェアサプライチェーンのセキュリティ強化に効果的です。企業が用いるソフトウェアは、OSSやプロプライエタリソフトウェアなどで構成されています。前述のLog4Shell騒動のように、多数のソフトウェアで利用されているOSSに脆弱性が見つかれば、ソフトウェアサプライチェーン全体への攻撃リスクが上がるでしょう。

IPA（情報処理推進機構）の「情報セキュリティ10大脅威 2023」によれば、「サプライチェーンの弱点を悪用した攻撃」は組織への影響が大きい脅威第2位に位置付けられました。前年度は第3位であったため、サプライチェーンを狙うサイバー攻撃の脅威は増加傾向にあります。

サプライチェーンのセキュリティリスクを下げる有効な手段の1つが、SBOMです。SBOMでソフトウェア構成を可視化することで、適切なコンプライアンス管理や脆弱性対応が可能になります。

SBOMを活用するために必要なこと

SBOMを活用するためには、次の2項目の取り組みが重要です。

1. 適したフォーマットによる生成
2. 管理環境や開発現場での運用

順番に確認しましょう。

1.適したフォーマットによる生成

NTIAは、SBOMの効率的な活用には、機械判読や自動生成が可能なフォーマットによる作成が必要としています。自動化に対応したフォーマットで作成されたSBOMであれば、異なる組織間でもスムーズにデータのインポートや管理が可能です。SBOMに適したフォーマットとして、NTIAは以下の3種類を明示しています。

• SPDX
• SWIDタグ
• CycloneDX

HTMLやプレーンテキストといった一般的なフォーマットでも、SBOMの作成は可能です。しかし、組織間の情報共有や管理効率を考慮するなら、上記のいずれかの手法で生成しましょう。

2.管理環境や開発現場での運用

生成したSBOMは、ただ作っただけでは意味がありません。管理環境や開発現場で運用する必要があります。ソフトウェアの管理環境にSBOMを取り込み、情報変更があれば随時更新して最新状態を保ちましょう。SBOMで各ライセンス要件を正確に把握できるため、厳格なコンプライアンス遵守も可能です。

また、コンポーネントのどこかに脆弱性が発覚しても、開発現場へ即座に伝達できます。開発現場はSBOMのバージョン情報などをもとに、迅速に脆弱性へ対応できるでしょう。

SBOMの活用例

SBOMは脆弱性対策やライセンス管理に効果を発揮しますが、以下3つのような活用方法もあります。

1. ユーザー企業への提供
2. ステークホルダーからの要求
3. 将来的なSBOM推奨または義務化への備え

順番に見ていきましょう。

1.ユーザー企業への提供

一般的にSBOMを作成および管理するのは、ソフトウェアを開発・販売・納入するサプライヤー企業です。今後SBOMへの理解と需要が高まれば、ソフトウェアのユーザー企業が自社による脆弱性管理を強化するため、SBOMの提出を求めるケースが考えられます。

2.ステークホルダーからの要求

資金調達やM&Aなど、自社のステークホルダー（利害関係者）がSBOMを要求するパターンもあるでしょう。自社製品の価値やリスクを分析する際に、SBOMは重要な資料となります。

3.将来的なSBOM推奨または義務化への備え

2023年現在、日本国内では官公庁へ提供する製品へのSBOM公開義務はありません。ですが、すでに国内では経済産業省が主体となって、国内のSBOM活用モデルの実証が進められています（※3）。今後SBOMの提供が推奨または義務化されれば、民間でもSBOMの作成・公開が活発化する可能性があります。

※3参照：経済産業省「サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース」

まとめ

SBOM（Software Bill of Materials：エスボム）があれば、特定ソフトウェアの構成を一覧化できます。ソフトウェアを構成するOSSおよびプロプライエタリソフトウェアのコンポーネントやライセンス情報を網羅することで、厳格なコンプライアンス管理が可能です。さらに、スピーディな脆弱性対応により、ソフトウェアサプライチェーン全体のセキュリティリスクを低減できます。国内外でもSBOMの重要性は高まっているため、SBOMを導入する企業は今後さらに増加するでしょう。