SBOMとは？ソフトウェアサプライチェーンの透明性を高める部品表の役割

サプライチェーンリスクが高まる中、ソフトウェアにおいてもサプライチェーン攻撃への対策が急務となっています。IPAが発表した「情報セキュリティ10大脅威2024【組織】」でも「サプライチェーンの弱点を悪用した攻撃」は第2位に挙げられているほどです。
このような大きな脅威であるサプライチェーン対策の一つとして、近年「SBOM」が注目されています。経済産業省も導入ガイドラインを策定するほどの管理手法ですが、そもそもSBOMとはいったい何でしょうか？本コラムでは、SBOMの概要や求められる背景、導入メリットなどについて解説します。
※本コラムは経済産業省の「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 ver 2.0」を参考に執筆しています。

SBOMとは

SBOM（Software Bill of Materials、ソフトウェア部品構成表）は「エスボム」と読みます。製品に含まれるソフトウェアを構成する「コンポーネント」やその依存関係などをリスト化した一覧表のことです。ちなみにコンポーネントとは、ライブラリやフレームワークなどソフトウェアを構成するプログラム部品のことを指します。
この表現だといまいちイメージしづらい方もいらっしゃるかもしれません。簡単に言うと、ソフトウェアの「材料リスト」のようなものです。日常生活の例で説明すると、料理のレシピを想像してみてください。
1. レシピには使用するすべての材料が書かれています
2. 各材料の量や種類が明記されています
3. 時には材料の原産地や特定のブランドも記載されることがあります

SBOMは、このレシピの考え方をソフトウェアに適用したものです。つまり、ソフトウェアの「レシピ」とも言えます。
1. ソフトウェアを構成するすべてのコンポーネント（ライブラリ、フレームワーク等）を列挙します
2. 各コンポーネントのバージョンや出所を記録します
3. 各コンポーネントに適用されるライセンス情報なども含まれます

では、このレシピには具体的にどのような情報が含まれるのでしょうか？SBOMに含まれる主な情報は以下の通りです。

コンポーネント名：使用されているライブラリ、フレームワーク、モジュールの名前
バージョン情報：各コンポーネントの具体的なバージョン番号
ライセンス情報：各コンポーネントに適用されるライセンスの種類
依存関係：コンポーネント間の関係性
製造元情報：各コンポーネントの開発者や提供元
ハッシュ値：コンポーネントの完全性を確認するための一意の識別子

このように、SBOMを利用することでソフトウェアがどのような構成なのか、また構成要素の依存関係はどのような状況かを一元管理できるようになりますが、そもそもなぜSBOMが注目されることになったのでしょうか。

SBOMが求められた背景

SBOMが注目を集めるようになった背景には、現代のソフトウェア開発環境が直面する課題があります。

デジタル化が進む現代社会における脅威の拡大

サイバー攻撃は年々複雑化し、その頻度も増加の一途をたどっていますが、その攻撃の中でも、ソフトウェアの未知の脆弱性を悪用したゼロデイ攻撃や、既知の脆弱性を狙った攻撃が増加しています。
このような状況下で、企業や組織はセキュリティ対策の強化を迫られていますが、攻撃手法の進化スピードは速く、従来の防御策だけでは十分な対応が難しくなっています。特に、ソフトウェア開発のプロセスや、そのサプライチェーン全体にわたるセキュリティの確保が、新たな課題として浮上しています。
その中で、近年サイバーセキュリティの世界で特に注目を集めているのが、サプライチェーンを標的とした攻撃です。最も有名な事例の一つが、2020年に発覚したSolarWinds社の事件です。攻撃者は同社の製品開発プロセスに侵入し、正規のソフトウェアアップデートに悪意のあるコードを仕込むことに成功し、その結果、SolarWinds社の製品を利用していた多数の企業や政府機関が影響を受け、機密情報の流出など甚大な被害が発生しました。
サプライチェーン攻撃の危険性は、その影響の広範さと深刻さにあります。一度成功すれば、攻撃者は信頼された経路を通じて多数の組織に同時にアクセスできるため、従来の攻撃方法よりもはるかに効率的に被害を拡大できます。さらに、被害の発見や対応が遅れがちなため、攻撃者が長期間にわたって潜伏し続ける可能性も高くなります。
このような状況下で、企業や組織は自社のセキュリティだけでなく、取引先や使用しているソフトウェア、部品のセキュリティにまで注意を払う必要が出てきました。サプライチェーン全体のセキュリティ確保が、今や企業の重要な経営課題の一つとなっているのです。

複雑化するサプライチェーン

現代のソフトウェア開発において、サプライチェーンの複雑化は避けられない現実となっています。この複雑化の主な要因の一つが、オープンソースソフトウェア（OSS）の広範な利用です。
多くの企業や開発者は、効率性や機能性の向上を目指し、既存のOSSコンポーネントを積極的に活用しています。このOSSの活用は開発速度を大幅に向上させる一方で、依存関係の管理を複雑にし、潜在的なセキュリティリスクを拡大させています。
さらに、ソフトウェアサプライチェーンは多層的な依存関係を形成しています。一つのアプリケーションが数十、時には数百ものライブラリやパッケージに依存し、それらがさらに他のコンポーネントに依存するという構造です。この複雑な依存関係の網の目は「依存関係の地獄」とも呼ばれ、セキュリティ管理を極めて困難にしています。例えば、ある重要なOSSライブラリに脆弱性が発見された場合、それを直接利用しているソフトウェアだけでなく、間接的に依存しているすべてのソフトウェアも潜在的なリスクにさらされることになります。この連鎖的な影響は、個々の組織の管理範囲を遥かに超えて広がる可能性があります。
このような状況下で、開発者や企業は自社製品に含まれるすべてのコンポーネントとその出所を正確に把握し、継続的に監視する必要性に迫られています。しかし、従来の手法では、この複雑化したサプライチェーンを効果的に管理することは極めて困難です。

サプライチェーンセキュリティの重要性

これまでの状況を踏まえると、サプライチェーンセキュリティの重要性は明白です。その重要性は、単に直接的な被害を防止するだけでなく、間接的な影響も考慮に入れる必要があることから、さらに増しています。
サプライチェーン攻撃は、被害組織の信頼性を大きく損なう可能性があります。顧客データが漏洩した場合、その組織は法的責任を問われるだけでなく、長期にわたって顧客の信頼を失うことになりかねません。また、取引先や投資家の信頼も失い、事業継続に深刻な影響を及ぼす可能性があります。
さらに、サプライチェーンセキュリティは、組織の競争力にも直結します。セキュリティ対策の強化が取引条件となる傾向が強まっており、適切な対策を講じていない組織は、ビジネスチャンスを失う可能性があります。逆に、強固なサプライチェーンセキュリティを実現することで、競合他社との差別化を図ることが可能です。
このように、サプライチェーンセキュリティは、組織の存続と成長に関わる重要な経営課題となっています。しかし、複雑化するサプライチェーンを効果的に管理し、セキュリティを確保することは容易ではありません。

法的要求の変化

さらにこの手法が注目されたのが、2021年5月12日に米国のバイデン大統領が署名した「重要インフラのサイバーセキュリティ強化に関する大統領令」です。政府調達の要件として「ソフトウェアの構成要素に関する詳細の開示」を政府調達の要件としており、ここでSBOMに言及しています。今後連邦政府のソフトウェア調達においてSBOMを開示等することが義務化される見通しとなっています。なお、大統領令は、2021年5月に起きたコロニアル・パイプラインへのサイバー攻撃を契機としており、米国においてもサイバーセキュリティの重要性が非常に高まっていることがわかります。
また国内においても、かねてからサイバーセキュリティに関する検討が行われて、2023年7月28日に経済産業省が「ソフトウェア管理に向けたSBOM導入に関する手引」を作成し、2024年8月29日に最新版のVer2.0が公開されました。

このように、複雑化するソフトウェアサプライチェーンのセキュリティ強化に向けて、近年注目を集めているのがSBOMなのです。

SBOMの利用方法

では、実際にどのようにSBOMを使えばよいのでしょうか？次はSBOMの利用方法について説明します。

SBOMフォーマットの選定

SBOMを効果的に活用するには、標準化されたフォーマットが不可欠です。SBOMには、米国国家通信情報局(NTIA)によって定義された「最小要素」を含む必要があります。その種類としては3つあり、「データフィールド」、「自動化サポート」、「プラクティスとプロセス」です。またSBOMはデータで管理される際、機械で判読可能で、相互運用可能なフォーマットを用いて作成することが求められています。作成には共通的なフォーマットを用いることで、組織内の管理が効率化され、さらには組織を越えてSBOMを共有することが可能となり、ソフトウェアサプライチェーンの透明性向上に寄与することができるようになるのです。
現在、共通的に主に使用されている主要なSBOMフォーマットは下記のとおりとなっています。

SPDX (Software Package Data Exchange)

Linux Foundation傘下のプロジェクトによって開発され、ISO/IEC 5962:2021として2021年に国際標準化されています。ライセンス管理などOSSの詳細な情報を表現できる記述に強みがあります。

CycloneDX

OWASP(Open Worldwide Application Security Project)のプロジェクトで開発されたオープンスタンダードなフォーマットです。セキュリティ管理を念頭に置いたフォーマットで、脆弱性情報や悪用可能性を記述できるフォーマットになっています。

SWID タグ(Software Identification タグ)

ISO/IEC 19770-2で標準化されており、ソフトウェア資産管理に適しています。

SBOMの生成ツール

SBOMのフォーマットを説明しましたが、多くのフォーマットはSBOMツールを利用して自動的に処理や管理ができるように設計されています。そのため、実際このフォーマットに沿って人手で管理を行うことはかなり困難です。
そこでSBOMを導入する組織は、ツールを利用してSBOMの作成や管理をすることが望ましいです。ツールはソフトウェアに含まれるコンポーネントを検出し、SBOMを自動生成してくれます。加えて、ツールを利用することでライセンス情報や脆弱性情報を把握することができるため、管理業務を効率化することもできるのです。
代表的な SBOMツールは、経済産業省の「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 ver 2.0」の付録にも記載がありますので参考にしてみてください。

SBOM導入の利点

SBOMが求められた背景や利用方法をここまで説明しましたが、SBOMを導入する事でどのような利点があるのでしょうか？
SBOMの主要な役割は、サプライチェーンの透明性と可視性を向上させることです。開発者や組織は、SBOMを活用することで自社のソフトウェア製品に含まれるすべてのコンポーネントとその出所を正確に把握可能です。これにより、潜在的な脆弱性やライセンス違反のリスクを迅速に特定し、対応することが可能になります。一例にはなりますが、具体的に下記のような利点があります。

セキュリティの強化

脆弱性の迅速な特定と対応

例えば、ある特定のオープンソースライブラリに重大な脆弱性が発見された場合、SBOMを参照することで、そのライブラリを使用している自社製品をすぐに特定し、迅速に対策を講じることが可能です。これは、従来の手動による調査と比較して、大幅に効率的で正確です。脆弱性が発見された場合も、使用中のすべてのソフトウェアコンポーネントを把握していることで、新たな脆弱性が発見された際に迅速に影響範囲を特定可能です。
SBOMの重要性を示す事例として、Log4jの脆弱性(CVE-2021-44228)、通称「Log4Shell」があります。SBOMを活用していない組織は、利用状況の把握のためにすべてのアプリケーションに対し手動でコードチェックを行う必要があり、調査だけでかなりの時間のロスとなります。また、人的ミスによる見落としや、直接使用していなくても他のライブラリを通じて間接的にLog4jを使用しているケースを見逃す可能性も否定できません。しかし、SBOMを活用していた組織の場合、脆弱性公表直後にSBOMにて検索するだけでLog4jを使用しているシステムとアプリケーションを短時間で特定でき、対象のバージョンも把握可能です。このように、セキュリティインシデントへの迅速な特定や包括的な検出、さらには優先度の高いシステムからのパッチ適用計画を立てることも可能となります。

リスク評価の効率化

各コンポーネントのバージョンや更新履歴を正確に把握することで、より精密なリスク評価が可能になります。
また依存関係の可視化によりどのコンポーネントが最も重要でどれが脆弱性を抱えているか容易に特定することが可能です。そのため新たな脆弱性が公開された際影響があるコンポーネントを特定することができ、またコンポーネントの使用状況や重要度を把握することで影響度をより正確に評価できることにより、優先順位付けされたパッチ適用やアップデート計画の策定が容易になることも挙げられます。

コンプライアンスの確保

ライセンス管理の効率化

多くの業界では、ソフトウェアコンポーネントの透明性に関する規制や標準が設けられています。SBOMはこの要求を満たすための強力なツールとなります。
ライセンスについては、使用しているオープンソースソフトウェアのライセンス条件を正確に把握し、ライセンス違反のリスクを低減します。また、商用ライセンスの管理や、ライセンス費用の最適化にも貢献します。

規制要求への対応

近年では、様々な業界でSBOMの活用が要求に含まれたり、ツールの一つとして参照されることが増えてきました。背景で例に挙げた「重要インフラのサイバーセキュリティ強化に関する大統領令」や、国際医療機器規制当局フォーラム(IMDRF)においては、サイバーセキュリティ対策の国際的な調和を図ることを目的とした「Principles and Practices forMedical Device Cybersecurity(医療機器サイバーセキュリティの原則および実践)」でSBOMについて言及しています。日本では、IMDRFガイダンスの要求事項を踏まえ作成された「医療機器のサイバーセキュリティ導入に関する手引書」の第2版でSBOMについて言及しており、医療機器メーカーに対して、SBOMの作成や医療機関等に対するSBOMの提供などを求めています。また経済産業省が公開した「ソフトウェア管理に向けたSBOM導入に関する手引」や、明示的には言及していませんがソフトウェア資産の把握を要求しているISO/IEC 27001も関連します。このように各種法規やガイドライン等でSBOMに言及しており、各国各業界団体でSBOM開示を義務化する法規制の動きが活発化しています。
SBOMの利用は、サイバーセキュリティ関連の法規制基準や国際規格への対応の支援、業界特有の規制への対応を容易にしてくれます。

サプライチェーンリスクの低減

透明性の向上

ソフトウェアを構成するすべてのコンポーネントとその依存関係を明確に示します。この透明性により、開発者や運用者は使用しているソフトウェアの全体像を把握可能です。潜在的な脆弱性やライセンス違反のリスクを特定しやすくなり、サプライチェーン全体の信頼性が向上します。

コンプライアンスの簡便化

多くの業界で、使用しているソフトウェアコンポーネントの開示が求められています。SBOMを活用することで、このプロセスが大幅に簡便化されます。規制当局や取引先への報告が容易になり、コンプライアンス関連のコストと労力を削減可能です。

サプライチェーン攻撃への対策

不正なコンポーネントや改ざんされたソフトウェアの検出を容易にし、サプライチェーン全体のセキュリティ強化につながります。

SBOMに関するよくある質問

まとめ