NRI 野村総合研究所
一部業界を中心として対応が求められる可能性が高い、
ソフトウェアのサプライチェーンを守る取り組み

米国大統領令で注目されつつある「SBOM」
その概要と課題、そして効果的な導入手法とは

米国では大統領令として政府調達要件に加えられた「SBOM」。ソフトウェアのサプライチェーンを狙った攻撃への対策として、日本でも一部で検証が進んでいる。その重要性や実施する上での課題、考えられる対策など紹介する。

長期に渡って不正アクセスを続ける
ソフトウェアのサプライチェーンを狙った攻撃

企業などの組織内では、多種多様なソフトウェアが用いられている。いわゆるIT部門が扱うシステムが多彩なソフトウェアの集合体であることは言うまでもないが、製造業なら製品によって組込ソフトウェアが不可欠、コンシューマー向けの事業で使う顧客向けアプリなども、複数のソフトウェアの集合体であるはずだ。しかもそれらのシステムを構成するソフトウェアの中には、商用ソフトやオープンソースソフトウェア(OSS)など、外部から調達したソフトも多いはず。では、それら外部調達のソフトが、本当に信頼できるものだと、自信を持って言えるだろうか。そもそも、ソースコードの利用・修正・再配布が可能なOSSは自社でどの米国大統領令で注目されつつある「SBOM」その概要と課題、そして効果的な導入手法とは一部業界を中心として対応が求められる可能性が高い、ソフトウェアのサプライチェーンを守る取り組み米国では大統領令として政府調達要件に加えられた「SBOM」。ソフトウェアのサプライチェーンを狙った攻撃への対策として、日本でも一部で検証が進んでいる。その重要性や実施する上での課題、考えられる対策など紹介する。程度使っているか把握することも難しい。また、OSSならソースコードが公開されており、相応の手間をかければ利用者側で検証することも可能だが、商用ソフトの場合はベンダーが信頼できるという前提で利用するしかない。しかし、ときには信頼しているはずの外部ソフトが不正に改ざんされ、多くのユーザーが巻き込まれる例もある。特に周到な攻撃の場合、ほとんどのユーザーは気付かぬうちに被害を受けることになってしまう。ソフトウェアの流通を悪用した攻撃は「ソフトウェアサプライチェーン攻撃」と呼ばれ、ユーザーにとっては気付くことさえ極めて困難だ。逆に攻撃者の視点に立てば、気付かれる懸念が低いともいえる。長期に渡って不正アクセスを続けやすい環境が得られるため、時間と手間をかけて不正アクセスを続けることができ、より価値のある情報を探り出して盗むことが可能になってくる。攻撃者に時間の余裕があれば、発覚を遅らせるための活動隠蔽も行いやすいことから、被害が水面下で広がってしまいがちで、しかも実態の把握すら困難になりがちだ。

図1

大きな被害をもたらしたことから
米国政府もその対策に乗り出す

ソフトウェアサプライチェーン攻撃は近年増加中で、中でも代表的な例が、2020年末に発覚した、米SolarWindsの一件だ。同社はサイバー攻撃を受け、大企業および米国政府機関に広く採用されているネットワーク管理などのソフトウェア製品に不正なコードが仕込まれていた。これを利用したユーザーにバックドアが設置され、数多くの政府機関や企業が機密情報を盗まれている。非常に手が込んだ攻撃であったことから、少なくとも周到に計画された組織的な攻撃だとみて間違いないだろう。攻撃者はロシア政府の息の掛かったハッカー集団だ、とする説もある。この攻撃で米国の連邦政府機関、米国を代表する大企業などが被害を受け、米国では安全保障上の重大な懸念して受け止められた。2021年5月には大統領令により、その対策が指示されている。

図2

ソフトウェアのサプライチェーンに対する
トレーサビリティを実現する取り組み「SBOM」

大統領令および関連ガイドラインにより、米国政府の調達基準に盛り込まれた、ソフトウェアサプライチェーン攻撃への対策が「SBOM」だ。政府調達にSBOMの作成および提供を義務づけ、それに基づく脆弱性チェックや修復も要求している。また日本国内でも、経済産業省がその効果検証や課題検討などに乗り出しており、その中では3つの産業分野を挙げて、各業界とも連携した取り組みが進行中だ。
SBOMとは、「SoftwareBillOfMaterials」の略、つまりソフトウェアにおけるBOMだ。製造業におけるBOM(BillOfMaterials)になぞらえ、ソフトウェアの部品表あるいは部品構成表を作って管理しようという取り組みを指す。システムに組み込まれている全てのソフトウェアコンポーネントについて、例えばバージョンや依存関係なども含む詳細な情報を管理、これを元にシステム全体のリスクをきめ細かく洗い出せるようにする、というものだ。SBOMを適切に管理できれば、特定コンポーネントの特定バージョンに新たな脆弱性が発見された際、その影響範囲を洗い出すことが容易になる。また、各コンポーネント、とりわけOSSで発生しがちな、ライセンス義務違反などのコンプライアンスリスクを検証するにも効果的だ。これら期待される効果を考えれば、常にSBOMを最新の状態に保つ管理運用も重要であることが分かるだろう。例えばリリースやビルドのたびに、その都度SBOMを更新しなければならない。その時点で取り入れているコンポーネントのバージョン、またその時点における依存関係などを反映させる必要がある。
またSBOMの運用においては、ソフトウェアのサプライチェーン全体でこれを共有することも求められている。例えば外部から調達したソフトウェアコンポーネントについても、それに付随するSBOMも取り込む必要がある。逆にソフトウェアを自社から顧客に提供する場合も、SBOMを合わせて提供する。サプライチェーンのどの段階においても、脆弱性などのリスクを容易に把握できるようにするための取り組み、いうなればソフトウェアコンポーネントのトレーサビリティといったところか。これを実現するためには関係する企業間の標準化も欠かせないことから、米国政府はSBOMで管理する項目を規定し、これに基づく共有、連携を求めている。
そしてもう一つ、ソフトウェア単体で提供する製品のみならず、ソフトウェアを組み込んだハードウェア製品についても、SBOMの管理対象とすることが求められている。例えば経産省でも、ソフトウェア業界のみならず医療機器と自動車分野を対象として取り組んでいる。部品メーカーから最終製品メーカーまで、組込ソフトウェアのSBOMを流通させ、製品のセキュリティリスク管理に繋げようというわけだ。製品に組み込まれたものまで含む広範囲にわたるソフトウェアについて、セキュリティリスクを適切に管理し、関係先との連絡調整を行えるようにする必要がある。

図3

SBOM の管理・運用には数多くの課題もある
特にプロセスを重視した解決策の検討が必須

先にも述べた通り、SBOMへの対応は、日本でも一部業界を中心に必須となってくる可能性がある。少なくともそれらの業界に関係する企業では、遠からず自社への影響を考慮しておくべきだろう。またリスク低減策の一環として、他の業種でも取り入れる企業が現れ、取引先がそれを求めてくる可能性がある。
ただし、相応の効果が期待できるとはいえ、SBOMを適切に管理・運用するためには課題も多い。まずSBOMが扱う内容はOSSだけではなく商用ソフトウェアやファームウェアも含まれ対象が広い上に、各コンポーネントについての詳細な情報を把握・収集する必要がある。いくつかのソフトウェアベンダーがSBOMに対応する製品の開発を進めており、順次機能強化が行われるようだ。
より大きな課題がその先にある。ソフトウェアのサプライチェーン全体を網羅する取り組みでもあるSBOMにおいては、複雑に絡み合う情報を連携させていく必要があり、そのためのプロセス整備は大きな課題だ。全てのソフトウェアについてビルドやリリースごとにSBOMを更新し、外部連携やリスクの洗い出しなどを行う作業は、非常に手間がかかる。それらを滞りなく実施し、人的ミスを避けるためには、適切なプロセスと自動化の仕組みが欠かせない。
また先に説明してきたように、SBOMの対象となるソフトウェアは範囲が広い。IT部門やセキュリティ部門は、専ら自社内のシステムを管理対象としている。一方、自社が顧客に提供するソフトウェア製品や組込ソフトウェアについては、品質管理部門などの関与が想定される。だが多くの企業で、IT部門には製品分野の知見が乏しく、品管など製品に関わる部署ではIT分野のノウハウが不足しがちだ。両者の知見やノウハウを持ち寄って、上手に体制を作り上げていかねばなるまい。
総じてみると、プロセスを適切に回す仕組みや体制が重要であることが分かる。

SBOM におけるプロセスや仕組みの整備には
IT 部門の手法やノウハウが効果的

このようなプロセスを適切に回すという観点では、IT部門に一日の長があると言えよう。すでにシステム運用の効率化、リスク低減などのために、変更・リリース管理や構成管理といったプロセス管理の手法を取り入れている企業も多いはず。それらのプロセス管理には様々なステークホルダーが組み込まれることも多いので、SBOMの維持管理にも役立つノウハウが多いことだろう。そして関連するベンダーも動き始めている。

図4

NRI が提供を検討している
ソリューションの概要

システム運用のプロセス管理で実績のある「SenjuFamily」を開発・提供する野村総合研究所(NRI)では、SBOMを見据えたソリューションの検討を進めている。そのソリューション構成イメージは、図に示したような内容だ。
Senju/SMの変更・リリース管理や構成管理機能を軸にSBOM運用プロセスを集約、セキュリティ管理者に加え、システム開発担当、外部ベンダーなど様々な関連者がこれを中心にSBOM関連の各プロセスを回していくという仕組みになっている。そこで用いられる情報ソースは、外部のコンポジション解析ツールなどによるSBOM情報、Senju/DCによるインベントリ情報などだ。Senju/SMでは脆弱性情報を外部機関から取り込み、インベントリやSBOMと関連付けてセキュリティ管理を一元的に行う。
なお、SenjuFamilyの機能強化のうち、特にSBOMに関連がありそうな箇所として、以下のような点が挙げられるとのことである。

・外部連携API強化

外部連携の柔軟性を向上させ、多彩な連携を容易にしている。また、SBOMに関連して注目されているコンポジション解析ツールやOSSツールなどとの連携検証を進めている。

・構成管理機能の強化

内部アーキテクチャを見直し、構成情報の連携などを、 従来より容易にする。SBOMの運用を構築しやすくなり、SBOMへの対応のハードルを下げる。

最新ソリューション資料を見る

ソリューション紹介資料ダウンロード ソリューション一覧へ戻る
Contact

Senju Family / mPLATに関するお問い合わせ

ご購入前の製品・サービスに関するお問合せは
Senjuインフォメーションセンター までお願いします。

お問い合わせフォームはこちら

フリーダイヤル・メールでもお受けしております。

0120-736-580

受付時間 平日10:00〜17:00 土日祝祭日、弊社休日を除く

senjuinfo@nri.co.jp