Windows OSのシステム管理者も無関係じゃない、これから始めるSBOM：SBOM基礎知識

使用していたオープンソースのソフトウェアに使われていたライブラリに脆弱性があったことに気付かないでいたことで、攻撃を受けてしまったという事例が発生しています。これはLinuxだけでなく、Windows OSでも起こり得る事態です。こうしたリスクを軽減する方策として、SBOMと呼ばれるOSSのサプライチェーン管理の手法があります。今回はSBOMとはどういったものなのかについて解説します。

[原仁俊，サイエンスパーク]

SBOMを知ろう
　

　本記事では、Windows OSをはじめとするOSを使用する開発者やIT管理者、経営層などに向けて、ソフトウェアのサプライチェーンリスクや既知の脆弱（ぜいじゃく）性といったリスクと、それを解決するためのSBOM（Software Bill of Materials）の活用について説明していきます。

　本校では、以下のような疑問に答えていきます。

• WindowsなどのOSにおいてもSBOMの導入が必要か？
• SBOMがなぜ必要なのか？
• SBOMと既知の脆弱性の関係は？

　SBOMに関する一般論からOS視点でのSBOM活用に触れることで、ソフトウェアの開発と運用に携わる全てのステークホルダーにSBOMの理解を深めていただければと思います。

OS視点で見るSBOM導入の課題

　SBOMは、もともとLinux環境におけるオープンソースソフトウェア（OSS）の管理で頻繁に使用される考え方でした。コードの再利用と共有が盛んなこの分野では、SBOMがセキュリティとコンプライアンスの鍵となっています。

　Windows OS環境では、長らく独自開発された商用ソフトウェアが中心でしたが、開発効率の向上やコスト削減、柔軟性の追求などから、無料で利用できるOSSの採用が進んできています。特に開発環境やクラウドインフラ、DevOpsツールなどで利用が拡がっています。

　しかし、国内の省庁から出されているSBOMのガイドラインでは、特定のOSを十分に考慮した内容に踏み込まれておらず、シーケンサー（プログラムによって定められた条件や順序で機械の動作を制御する装置）や医療機器などに多いWindows OSを組み込んだ機器の場合、具体的な提出物や基準が定まっていないという課題が存在します。

　この状況は、日本発の組み込みOSであるTRONのような、一般的にSBOMの利用が見られないOSに対しても同様です。これらの課題は、特定のOSやアプリケーションに依存するシステムにとって、セキュリティとコンプライアンスの確保がより複雑で困難になることを意味しており、今後の重要な議題となると考えられます。OS視点での課題を深堀する前に、まずはSBOMについて次章以降で説明します。

SBOMの概要とその重要性

SBOMについて

　SBOMは、ソフトウェア製品に含まれる全てのコンポーネントをリストアップしたソフトウェアの部品表であり、サプライチェーンのリスク対策として注目を集めています。

SBOMの例（SPDXフォーマット）と供給イメージ

　現代のソフトウェアは非常に複雑で、多くのコンポーネントで構成されています。これらのコンポーネントの中には、オープンソースソフトウェア（OSS）やサードパーティー製のライブラリも含まれることが多く、それぞれが異なるライセンスやセキュリティ要件を持っています。

　例えば、下画面はあるディスク管理ソフトを「cve-bin-tool」という既知の脆弱性が含まれているかどうかを検出できるオープンソースソフトウェアで診断した結果です。ここで表示されている「curl」というOSSは、Windows　OS用ソフトウェアでもよく使われているものですが、このディスク管理ソフトでは3年ほど前のバージョンが使われており、多くの脆弱性が検出されました。

cve-bin-toolであるディスク管理ソフトを診断した結果

　このような状況下で企業や開発者が使用するコンポーネントの一覧を持つことは、次のような重要な意味を持ちます。

意味	説明
セキュリティ管理	SBOMでソフトウェアの構成要素を把握することで、既知の脆弱性を迅速に特定し、対処までにかかる期間期間が短縮できる。
コンプライアンスの確保	各コンポーネントのライセンス要件を把握することで、ライセンス違反や法的な問題を未然に防ぐことができる。
品質管理と信頼性向上	使用しているコンポーネントの品質と互換性を確認することが容易になり、製品の全体的な品質と信頼性を向上させることができる。
保守業務の効率化	製品に使用されているコンポーネントが一目で分かるため、アップデートやメンテナンスが効率的に行え、開発サイクルを速めることができる。
コンポーネントの一覧を持つ意味

　このように、SBOMはソフトウェア開発の多岐にわたる側面で、透明性と効率性、セキュリティの強化に寄与します。特に今日の多様で相互依存する技術環境において、SBOMの役割はこれまで以上に重要となってきています。

サプライチェーンリスクとSBOM

　前述の通り、ソフトウェアが多くのコンポーネントやライブラリ、ツールの組み合わせで成り立っている中で、これら供給源からのリスクが増えてきています。毎年、情報処理推進機構（IPA）がが発表している「情報セキュリティ10大脅威 2023」において、組織におけるサプライチェーンリスクは2位までアップしてきています。

順位	組織	個人
1位	ランサムウェアによる被害	フィッシングによる個人情報などの詐取
2位	サプライチェーンの弱点を悪用した攻撃	ネット上の誹謗、中傷、デマ
3位	標的型攻撃による機密情報の窃取	SMSなどを使った脅迫、詐欺の手口による金銭要求
4位	内部不正による情報漏えい	クレジットカード情報の不正利用
5位	テレワークなどのニューノーマルな働き方を狙った攻撃	スマホ決済の不正利用
6位	修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）	不正アプリによるスマートフォン利用者への被害
7位	ビジネスメール詐欺による金銭被害	偽警告によるインターネット詐欺
8位	脆弱性対策の公開に伴う悪用増加	インターネット上のサービスからの個人情報の窃取
9位	不注意による情報漏えいなどの被害	インターネット上のサービスへの不正ログイン
10位	犯罪のビジネス化（アンダーグラウンドサービス）	ワンクリック請求などの不正請求による金銭被害

情報セキュリティ10大脅威 2023
情報処理推進機構（IPA）が発表している「情報セキュリティ10大脅威 2023」を編集部で再構成したもの。

　これは、サードパーティーからのコード供給や外部ライブラリの利用増加に伴い、悪意のあるコードの混入や脆弱性を突いた攻撃が増えていることを示しています。SBOMはこのリスクに対して、有効な対策となります。

●透明性の向上

　製品に使用される全てのコンポーネントを明確に把握し、外部からの攻撃や悪意のあるコンポーネントの混入を早期に検知できる。

●迅速な対応

　既知の脆弱性があるコンポーネントを速やかに特定し、必要なパッチの適用や置き換えによる対応が行える。

グローバルな動向

　SBOMは世界においてもその重要性は認識されており、行政主導で動きが活発化してきています。

　米国では2021年5月にバイデン大統領が署名した大統領令において、連邦政府機関が調達する重要なソフトウェアに対してSBOMを含む一定のセキュリティ対策が求められています。これを機にソフトウェア・サプライチェーンの確保に向けてNIST（米国立標準技術研究所）が中心となってガイドラインを策定しており、将来的にはガイドラインに基づいて政府調達に関するFAR（連邦調達規則）が改正される見込みです。

　民間においても、ヘルスケアや自動車、電力などの重要インフラにおいてSBOMの活用に関するガイドライン策定やその活用方法について検討が進んでいます。

　EUでは法制度化の検討が進んでいます。2022年9月に草案が提出されたEUサイバーレジリエンス法において、SBOMの作成が明記されているだけでなく、一部例外を除いたデジタル要素を備えた全ての製品が対象となっています。EUサイバーレジリエンス法は2025年の後半に適用を目指しています。

　このような海外の動きは、製品を輸出販売する日本のベンダーにとっても無視できない状況となってきており、SBOMの活用が急務となっています。

　日本においても、政府主導でSBOM活用の検討が進展しています。経済産業省と総務省が実証事業を進めており、経済産業省は自動車、医療、ソフトウェアの分野で実証事業を行い、2023年7月には「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引Ver. 1.0」を公開しました。

　この手引きでは、SBOMの実際の導入方法や管理のベストプラクティスが紹介されており、国内企業の利用促進が図られています。また、総務省においても通信分野におけるSBOM活用の実証事業を始めています。

経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引」概要資料の抜粋

SBOMと既知の脆弱性について

既知の脆弱性とそのリスク

　既知の脆弱性とは、過去に発見されたソフトウェアやハードウェアのセキュリティ上の欠陥で、攻撃者によって悪用される可能性があるものを指します。サイバー攻撃によるインシデントの99%以上がこの既知の脆弱性を狙われたものであり、近年は新たな脆弱性が発見されてからそれが攻撃に利用されるまでの期間も短くなってきています。

　この脆弱性が攻撃者に悪用されると、データの漏えいやシステムの不正操作など、企業や組織にとって重大な損害をもたらすことがあります。最近では、「Apache Log4j」の脆弱性である「Log4Shell」が大きく話題に上がり、影響範囲の把握や対応に追われた企業も多くあります。実際にLog4jの脆弱性が悪用され、ランサムウェアの被害に遭ったケースも報告されています。

　また、セキュリティインシデントとしてニュースに取り上げられた徳島県や大阪府の病院におけるランサムウェアの被害は、VPN機器の脆弱性を突かれた事例として有名です。これらの事例からも、既知の脆弱性の迅速な特定と対処が、組織のセキュリティ対策において重要な課題となっています。

Log4Shellを突いた感染イメージ
Log4jのLookup機能を使って攻撃コードを含むデータを送信。ログに出力されたコードが実行されることで攻撃用サーバと通信し、マルウェアなどの不正プログラムをダウンロードする。

脆弱性データベースとその活用

　既知の脆弱性は、CVE(Common Vulnerabilities and Exposures) やNVD（National Vulnerability Database）、JVN（Japan Vulnerability Notes）などの脆弱性データベースで一元管理されています。これらのデータベースには、脆弱性の詳細な情報、影響範囲、対策方法などが記載されており、セキュリティ担当者はこれらの情報を参照して対応策を決定します。

CVEのサイトで「Log4j」を検索した結果
本記事を執筆時点でLog4Shell（CVE2021-44228）を含む23件が検出される。

SBOMの活用と脆弱性管理

　SBOMを使用すると、製品に含まれるコンポーネントのリストが手元にあります。SBOMと脆弱性データベースを突き合わせることで、特定のコンポーネントに既知の脆弱性が存在するかどうか、簡単かつ迅速に確認することができます。

SBOMツールの現状と課題

市場のSBOMツール

　ソフトウェアのサプライチェーンリスクを管理する上で、SBOMの作成は欠かせないプロセスです。ソースコードからSBOMを生成するツールは市場に数多く存在し、開発者にとって手間を大幅に削減する役割を果たします。Microsoftが提供する「sbom-tool」やSynopsysが提供する「Black Duck」が有名ですが、これらのツールはOSSを識別し、関連するライセンスや脆弱性情報を一元的に管理することができます。

　一方、ソースコードからではなく、バイナリからSBOMを作成するツールも市場に存在します。逆アセンブルや逆コンパイル技術を使用して、ソースコードの不足を補う機能が備わっています。こちらはCybellumのSBOM管理ツールが有名ですが、前述のBlack Duckもバイナリから生成する機能を持っています。

　これら海外製品の多くは、多機能なのでツールの操作には専門的な技術を求められ、価格面においても大企業向けのツールとなっています。

中小企業のSBOMツール利用

　SBOMはサプライチェーンに含まれる中小企業にとっても重要な課題です。しかし、SBOMツールは多機能で高価なものが主流であり、中小企業にとってはその導入が難しい現実があります。

　世界的にSBOM導入の動きが進展する中で、中小企業のSBOMツール活用や支援体制の構築が今後の課題となっています。中小企業にとって、価格、機能、操作性を兼ね備えたSBOMツールが今後のビジネスにおける重要な要素であると考えられます。

　次回は、これらの課題に対する現状の要望について、OSごとに考察していきます。