SBOMとは? - サプライチェーンリスクマネジメントを強化する新たなアプローチを解説

 情報セキュリティ分野におけるサプライチェーンリスクマネジメントとは、製品の部品調達から販売に至る一連のプロセスにおけるリスクを特定し、適切な対策を講じる手法です。サプライチェーン内の一部がサイバー攻撃を受けると、その影響は全体に波及する可能性があります。このような被害の拡散を防ぐために、サプライチェーンリスクマネジメントを実施し、持続可能なサプライチェーンの実現が求められています。本記事では、サプライチェーンリスクマネジメントが注目される背景と、サプライチェーンリスクマネジメントを強化するアプローチとして最近話題になっているSBOMについて解説します。

SBOMとは

 SBOM(エスボム)とは、ソフトウェア部品表(Software Bill of Materials)の略で、ソフトウェアを構成する部品(コンポーネント)やその依存関係を整理したリストです。これは、ソフトウェア管理手法の1つとなっています。このリストを活用することで、ソフトウェア開発の現場でオープンソースソフトウェア(以降、OSS)の利用状況を正確に把握できます。具体的には、ソフトウェアを構成するコンポーネントの名称やバージョン番号、ライセンスの種類などが含まれます。

 SBOMの代表的なフォーマット(出力項目を定めた規格)として、SPDX、CycloneDX、SWIDがあります。

図1. SBOMの例(SPDXフォーマット)
出典:NTIA「Survey of Existing SBOM Formats and Standards - Version 2021」に掲載の例を基に大和総研作成

 近年、ソフトウェア開発においてOSSの利用は欠かせないものとなっていますが、一方でOSSに関する脆弱性情報が頻繁に公開されています。また、OSSの依存関係が複雑化する中で、企業の資産管理が適切に行われていないケースが多く見受けられます。例えば、企業がJavaを使用している場合、主要なライブラリやフレームワークの管理は行われていても、OSSの一部が資産管理から漏れてしまうことがあります。ロギングフレームワークであるLog4jやLogbackがその一例です。このような状況は、脆弱性が見つかっても気付けないというセキュリティリスクや、ライセンス違反・著作権侵害といった法的リスクを引き起こす可能性があるため、OSSを含むすべての依存関係を正確に把握し、管理することが必要です。

SBOMが注目される背景

 近年サプライチェーンの弱点を狙う攻撃が増加しています。標的型攻撃に代表される巧妙かつ精度の高いサイバー攻撃は以前から問題となっています。これまでこのような攻撃は、多くの機密情報を保有する大企業が主な標的とされてきました。
 しかし、近年この状況に変化が見られます。攻撃者に狙われやすい大企業等においては、強固なセキュリティ対策が年々強化され直接的な侵入が困難となってきたことから、セキュリティ対策が進んでいない取引先企業や海外拠点などの関係先を初期潜入の標的とし、これらを経由して大企業等への侵入を試みる攻撃(サプライチェーン攻撃)が増加しています。
 独立行政法人情報処理推進機構(IPA)の「情報セキュリティ10大脅威 2024」でも「サプライチェーンの弱点を悪用した攻撃」は2019年版で初めて第4位にランクインし、その後2022年版は第3位、そして2023年版および2024年版では第2位と順位を上げており、サプライチェーンリスクマネジメントの重要性は企業の規模に関係なく高まっています。(*1)
サプライチェーンリスクマネジメントの実践においては、セキュリティフレームワークの活用が有効です。セキュリティフレームワークについてはこちらの記事で詳しく紹介していますのでご参照ください。

ソフトウェア開発におけるサプライチェーンリスク

 現在のソフトウェア開発では、OSSや商用ソフトウェアの部品を組み合わせて構成されています。設計、開発からテスト、リリース、保守に至るまでさまざまなツールやサービスが利用され、このようにソフトウェア開発は多くの関係者が連なるサプライチェーンに依存しています。
 ソフトウェア開発におけるサプライチェーンには、ソフトウェアを構成するソフトウェア部品やソフトウェア開発のライフサイクルで利用するツールに脆弱性が存在するリスクがあります。攻撃者はその脆弱性を悪用してシステム内に侵入し機密情報の窃取などを行う可能性があります。
 米国では、このようなサイバー攻撃による大規模な情報漏洩などの深刻な被害を背景に、2021年に「国家のサイバーセキュリティ改善についての大統領令」が発令され、NIST(National Institute of Standards and Technology、米国国立標準技術研究所)がサプライチェーンのセキュリティ強化を推進することとなりました。(*2)(*3)
 一方で、国内では経済産業省が設置する「産業サイバーセキュリティ研究会ワーキンググループ1」内の「ソフトウェアタスクフォース」で、ソフトウェアの適切な管理手法や脆弱性対応が検討されてきました。特に、SBOMの活用について議論や実証実験が進められています。
 ここで注目されるのがSBOMです。米国では「国家のサイバーセキュリティ改善についての大統領令」の一環として、連邦政府機関ではSBOMの導入が義務化されました。国内では、経済産業省は2023年に「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引(*4)」を策定し、ソフトウェアのサプライヤーに向けてSBOMの導入によるメリットや実施に関するポイントをまとめ、企業のセキュリティ対策を支援しています。また、2024年には金融庁が「金融分野におけるサイバーセキュリティに関するガイドライン(*5)」を発表し、同年7月には総務省が「ICTサイバーセキュリティ政策の中期重点方針(*6)」を公表する中で、SBOMの整備が推奨されています。これにより、国内でもサイバーセキュリティ対策を強化する動きが進んでおり、SBOMの整備が急務となっています。

SBOM導入における注意点

 SBOMを作成・管理することができるツールとして、SCA(Software Composition Analysis、ソフトウェア構成解析)ツールがあります。SCAツールはソースコードやバイナリファイルなどを解析しSBOMを作成します。作成したSBOMに含まれるコンポーネントと、公開されている脆弱性情報やライセンス情報とマッチングを行い、ソフトウェアに存在するセキュリティリスクを検出します。ここでは、SCAツールを使用してSBOMを導入する際の注意点を紹介します。

図2. SCAツールのイメージ
出典:大和総研作成

有償ツールと無償ツールの違いを認識する

 SCAツールには、商用の有償ツールと、無償で入手できるフリーのオープンソースツールの二種類があります。有償ツールは一般的に高価ですが、その分機能やベンダーのサポートが充実しており、企業のニーズに応じた選択が可能です。一方、オープンソースツールはコストを抑えることができるものの、導入や利用方法に関する情報が限られているため、トレーニングに多くの時間を要することがあります。また、有償ツールに比べて機能が限定的である点も考慮する必要があります。
 たとえば、SBOMの出力だけを目的とする場合、ソフトウェアのビルド時にSBOMを生成するツール『sbom-tool』がMicrosoftによってオープンソースとしてGitHubに公開されています。このツールで作成したSBOMを他のツールと組み合わせて使用することで、脆弱性スキャンを実施し、脆弱性やライセンスを管理することも可能です。SBOMを適用するソフトウェアの規模や導入目的に応じて、適切なツールを選定することは非常に重要です。選択肢を比較し、組織の要件に最も合ったツールを見つけることで、効果的にセキュリティを強化することができます。

SCAツール導入時の運用体制を考慮する

 SCAツールを効果的に運用するためには、どのような体制を整えるかが非常に重要です。まず、自社の開発、運用、保守の各チームがどのような役割を持っているのかを理解することが大切です。一般的に、開発チームはどのOSSを使用するかを決定し、アプリケーションを作成します。一方、運用チームは脆弱性を調査し、検出した問題を周知する役割を担います。保守チームは運用チームからの情報をもとに具体的な対応を行い、脆弱性に対してセキュリティパッチを当てたり、システムを更新したりする役割を持っています。
 この時、SCAツールをどのチームが管理するのかは、運用の効果に重要な影響を与えます。例えば、開発チームがツールを管理する場合、彼らは自分たちのコードに対する脆弱性を直接把握しやすくなります。しかし、運用チームが管理する場合、全体の脆弱性を俯瞰して見ることができ、より広範な視点からの対応が可能になります。各チームが連携して効果的に運用するためには、コミュニケーションが不可欠です。また、脆弱性が発見された際の対応フローを明確にしておくことで、迅速な対応が可能になります。

SCAツールの対応言語やバージョン、使い方を事前に確認する

 ツールによってスキャン方法は異なり、サポートされるプログラミング言語(例えば、Java、JavaScript、Pythonなど)やその対応バージョンにも差異が生じます。特定の言語のバージョンに制約が課されるスキャン方法もあり、その結果、必要な機能が利用できなくなる可能性があります。例えば、企業によっては古いバージョンのJavaScriptを使用している場合があります。この場合、特定のツールがそのバージョンに対応していなければ、JavaScriptのコンポーネントが抽出できず、脆弱性を見逃すリスクが生じます。その結果、ツールを導入しても期待した効果を得られず、手作業が残ることで非効率的な状況を招くことになりかねません。また、スキャン方法によっては、ディレクトリ内に存在する旧バージョンのコンポーネント情報が取り込まれることがあります。このような場合、実際には存在しない無駄な脆弱性が検出され、その精査に余計な労力がかかることになります。これにより、重要な問題に集中できないリスクが高まるため、慎重なスキャン方法の選定が求められます。
 さらに、ツールによってはスキャンを実行するサーバーや端末にエージェントのインストールが必要となることがあります。エージェントとは、特定の機能を提供するためにシステムにインストールされるソフトウェアであり、その導入時にはシステム全体への影響を考慮することが重要です。エージェントのインストールによりシステムリソースが消費されるだけでなく、セキュリティポリシーに抵触する可能性もあるため、これらの要素を事前に十分に検討しておくことが求められます。
 このように、スキャンの仕組みを理解し、使用するプログラミング言語およびそのバージョンを確認することが極めて重要です。

脆弱性の優先順位を自動で付ける機能があるか確認

 オープンソースコンポーネントに関する脆弱性は年々増加しており、毎年数千の新しい脆弱性が公表されています。それらはすぐバックログとして蓄積されることで、担当者に大きな負担を強いることになります。現実的には、リスト上のすべての脆弱性を修正することは非常に困難であり、限られた時間とリソースの中で、どの脆弱性に優先的に対処することが最も効果的かを見極める必要があります。そこで、脆弱性の優先順位を自動で付ける機能を持つ管理ツールの重要性が増してきています。
 脆弱性の優先順位付けができるSCAツールは、脆弱性の深刻度(CVSSスコア)や影響範囲(外部からのアクセスが可能か)、攻撃の可能性(攻撃コードが流通しているか)などを考慮して、どの問題を解決すべきかを判断します。たとえば、ある脆弱性が特定のシステムに対して非常に危険で、すぐに修正が必要な場合、その脆弱性は高い優先順位を持つことになります。一方で、そのシステムが外部からのアクセスがない、攻撃コードが流通していないといった場合は、優先順位が低く判定されます。このように、自動的に優先順位を付けて現実的に対応可能な数に絞り込むことで、チームは重要な問題に集中でき、効率的に作業を進めることができます。また、優先順位が明確になることで、チーム内のコミュニケーションが円滑になり、誰がどの問題に取り組むべきかがはっきりと示されるため、各メンバーの役割や責任が明確になります。これにより、無駄な重複作業や混乱を避け、全体の生産性を向上させることが可能になります。

製品紹介

 SBOMを作成・管理することができるツールを紹介します。

Black Duck

 米国Black Duck Software社(2024年10月1日、米国Synopsys社から独立)が提供するSCAツールです。依存関係の解析やバイナリ解析など複数の方法でソフトウェアを解析することができます。また、OSSの脆弱性情報は常に最新の情報が参照でき、利用者は新たなリスクに素早く対応することができます。GUIが日本語に対応しています。
Black Duckソフトウェア・コンポジション解析(SCA) | Black Duck

yamory

 yamoryは、ITシステム全レイヤーを対象とした脆弱性対策とリスク管理をオールインワンで実現するクラウドサービスです。ソフトウェアの脆弱性管理に加え、OSSライセンスの違反リスクも可視化できるほか、マルチクラウド環境のクラウド資産を一元管理し、設定不備を検知するクラウド設定管理(CSPM)も完備しています。
yamory | 脆弱性管理クラウド | SBOM対応

おわりに

 SBOMは、ソフトウェアの透明性を向上させ、依存関係や脆弱性を明確にすることで、企業のセキュリティを強化する重要な手段です。サプライチェーンリスクマネジメントにおけるSBOMの導入は、リスクを効果的に管理し、企業の競争力を維持するとともに、より安全な製品を提供することを可能にします。このように、SBOMの導入は企業のセキュリティ対策を強化するだけでなく、持続可能なサプライチェーンの構築にも寄与します。
 企業は、これらのポイントを参考にし、自社にとって最適なアプローチを見つけ出し、実行に移していくことが求められます。

参考文献

(*1)IPA 独立行政法人 情報処理推進機構 「情報セキュリティ10大脅威 2024」 p.44-45
https://www.ipa.go.jp/security/10threats/nq6ept000000g22h-att/kaisetsu_2024.pdf

(*2)Executive Order on Improving the Nation's Cybersecurity
https://bidenwhitehouse.archives.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

(*3)NIST 「Survey of Existing SBOM Formats and Standards – Version 2021」 p.20
https://ntia.gov/sites/default/files/publications/sbom_formats_survey-version-2021_0.pdf

(*4)経済産業省 「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引ver2.0」
https://www.meti.go.jp/press/2024/08/20240829001/20240829001-1r.pdf

(*5)金融庁 「金融分野におけるサイバーセキュリティに関するガイドライン」 p.12
https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf

(*6)総務省 「ICTサイバーセキュリティ政策の中期重点方針」 p.25-26
https://www.soumu.go.jp/main_content/000960379.pdf