SBOMで強化するソフトウェアサプライチェーンセキュリティ

1. 経営アジェンダとしてのソフトウェアサプライチェーンセキュリティ

デジタル技術を活用したビジネスモデルへの変革に伴い、業界を問わずソフトウェア(以下SW)の重要性が増しており、SWに関連するセキュリティの確保が企業にとって課題となっています。

今日のSW開発では、1つのSWを開発する際、全てを一から自らの手で作り上げることは非常に困難かつ非効率であり、第三者が作成したSWをコンポーネントとして活用することが当たり前となっています。

特に、誰でも自由に利用・開発・再配布が行えるオープンソースソフトウェア(以下OSS)の活用は今日のデジタル経済を支える基盤であり、90％以上の企業がOSSを利活用しているとする調査も公表されています。^※1

しかしこれは広く普及したOSSにおいて脆弱性等の欠陥が見つかり、脆弱性が修正されたOSSのバージョンへの更新を企業が怠った場合、当該OSSコンポーネントを組み込んだ製品・サービスに脆弱性が内包されてしまうリスクがあります。

また、複数の主体が参画するSWの開発から実装までの一連の流れであるSWSCにおいて、多くの企業がSWの開発者・提供者となる昨今、供給元が幾重にも重なることにより、サプライチェーン(以下SC)上におけるSWの依存関係が非常に複雑なものになっています。

これはSWSC上にあるSWを構成するコンポーネントを起点にインシデントが発生した際、原因となったコンポーネントを突き止める工数が増加し、製品・サービスの復旧が遅れてしまう可能性があることを意味します。

こうした背景から、SWSC上において、ある製品・サービスを構成する全てのSWがセキュアであることを確認する“透明性”と、その関係性がSC上で一貫して識別出来る“追跡可能性”を担保することが非常に重要になってきています。（以下図参照）

以下、SWSCの脆弱性が突かれ、実際に発生したインシデント事例を2つ紹介します。

■ インシデント事例①：米大手SWベンダーの事例(2020) 

米大手SWベンダーの製品に不正なコードが埋め込まれ、本製品を導入していた政府機関含む18000社にマルウェアが侵入し、データが海外のサーバへ転送されました。

■ インシデント事例②「Log4Shell」(2021) 

Javaベースのオープンソースログ出力ライブラリApache Log4jにおける任意コードが実行される脆弱性が発表されました。^※2

こうしたインシデントを引き起こすSWSC上における脅威に対して、そのセキュリティ強化を目的に様々な法規制等の整備が各国で活発化しています。

米国においてはE.O.(Executive Order)14028、EUにおいてはCRA(Cyber Resilience Act)、日本においても経産省が昨年「OSS の利活⽤及びそのセキュリティ確保に向けた管理⼿法に関する事例集」を公表しており、対策に向けた動きが加速しています。

2. E.O.14028発令と共に注目が集まっているSBOM

今回フォーカスを当てるE.O.14028では、官民の情報共有促進、連邦政府のセキュリティ近代化、サイバー安全審査会の設置など、国全体のサイバーセキュリティ強化を図るための命令が9つのSectionに分けて記されています。

SWSCセキュリティに関しては、Section4“Enhancing Software Supply Chain Security”中に記されており、連邦政府が使用するSWのセキュリティが、権能の行使に際し不可欠であることを理由に、そのセキュリティと完全性の確保を目的として様々な命令の実行やガイドライン等の文書作成を各連邦政府機関に命じています。

例として、E.O.14028の発令日である2021年5月12日から45日以内には、「重要SW」の定義と、その対象となる製品の一覧を記した文書を、続く60日以内には「重要SW」使用時におけるセキュリティ管理策のガイダンスが保護のための管理策を所管官庁から公表することを命じています。（以下図参照）

その中でも特に注目を集めているのが、1章で述べたSWSC上における透明性と追跡可能性を向上する手段として、SBOMの活用をSW開発者に要求したことです。

本大統領令を受け、NTIAは“The Minimum Elements for an SBOM“という文書にSBOMの満たすべき最小限の要件として、Data Fields, Automation Support, Practices and Processesの3つを定義し、米国政府機関でのSBOM活用のガイドラインを制定しました。

SBOMはSoftware Bill of Materialsの略で、特定の製品に含まれるすべてのSWコンポーネントやライセンス、またそれらの依存関係を一覧化したもので、言わば「ソフトウェアの部品表」です。

部品表として、SWの構成要素を記載することで、構成要素の可視化が可能となり、例えばそのSWに含まれている脆弱性のあるコンポーネントやライセンスリスクのあるコンポーネントなどの検知が容易になり、SWの透明性が高まります。

また、構成要素であるSWコンポ―ネントに対してもSBOMを生成し鎖のようにつなげることで、SWSC全体を可視化するとともに、SWの追跡可能性の向上に役立ちます。

例えば、SW開発ライフサイクルのあらゆるフェーズでSBOMの内容を検証することで、組織が扱うSWの透明性と追跡可能性が向上し、各フェーズにおいて様々なSWの問題の検知が可能になります。(以下図参照)

上記のようにSBOMを効果的に活用するため、導入時に考慮すべき点は何かを3章で紹介します。

3. SBOMが満たすべき最小要件とは？

■Data Field

SWSC全体でコンポーネントを識別して追跡するためには、そのコンポーネントに関する十分な情報を集めることが必要不可欠です。組織によって「十分な情報」は多少異なりますが、NTIAは少なくとも以下7つのデータフィールドを提唱しています。（以下図参照）

また、これらに加え、SWコンポーネントの改ざんの有無を検証するために使用できるハッシュ値やSWコンポーネントのライセンス情報、条件や制約の追跡に活用できるSWに関するその他の情報など、上記7つのデータフィールドに加え、各組織のニーズに合わせて様々なデータフィールドの追加を推奨しています。

■Automation

組織に存在するSWコンポーネントの数は膨大であるため、SBOMの生成や検証を実施する際は、手作業ではなくある程度ツールを使用して自動化する必要があります。そのためNTIAは、SBOMを人間だけでなく機械にとっても読みやすい一貫性のあるフォーマットで管理する必要があるとしています。

SPDX（Software Package Data Exchange）やCycloneDX、SWIDタグのような共通のデータ構文表現の規格を使用することで運用性は高まると考えられ、NTIAもこれらの規格の使用を推奨しています。

SBOMに含むデータの収集から実際にSBOMを利活用するまで、自動化できる作業はなるべくツールに任せ、コンポーネントの透明性と追跡可能性が常に担保された持続可能な仕組みづくりの準備が大切になってきます。

■Practices and Processes

NTIAはSBOMを実際に活用していく際に、守るべき運用上の原則を6つ挙げています。(以下図参照)

これらのルールを守った上でSDLCのあらゆるフェーズにおいてSBOMの生成・検証を実施することで、その組織におけるSWSCが可視化され、よりセキュアなSW開発・管理に一歩近づきます。

ただし、SBOMを効果的に運用するための人材不足やSBOM管理・運用のための自動化やシステム化の価値を十分に検討できていない等、組織においてSBOMを活用するには様々なハードルがあります。

SBOMを組織全体のあらゆるプロセスに即時導入することは難しいため、まずは正確かつ最新の情報を有するSBOMを生成・管理するところから始めましょう。SBOMがSWSCの透明性と追跡可能性の向上に寄与して、その結果SWSC全体のセキュリティ強化につながることを強く認識した上で、段階的に導入を進めることが重要です。

≪参考文献≫

※1:Wolfgang Gehring,” The state of open source software”,GitHub,23-03, Octoverse 2022: The state of open source | The State of the Octoverse (github.com),（参照 2023-03-07）

※2:JPCERTCC,“Apache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）に関する注意喚起”, https://www.jpcert.or.jp/at/2021/at210050.html , (参照 2023-03-17)

≪執筆者≫

岩本 高明、北町 任、鈴木 秀汰、原田 丈

≪関連するリンク≫

サードパーティー・リスク 管理（TPRM: Third-party Risk Management)

執筆者

北町 任／Takashi Kitamachi
デロイト トーマツ サイバー合同会社

デロイト トーマツ サイバー合同会社所属。会計系の大手コンサルティング会社を経て現職。製造業を中心に、取引先を含めたサプライチェーン全体のサイバーセキュリティー戦略や製品セキュリティー戦略の策定などに従事。

鈴木 秀汰／Shuta Suzuki
デロイト トーマツ サイバー合同会社

​Deloitte USのニューヨーク事務所勤務を経て、2022年にデロイト トーマツ サイバー合同会社に入社。日系企業や外資系企業に対し、サイバーセキュリティ戦略、ガバナンス強化、システム導入、コンプライアンス対応に関するリスクアドバイザリー経験を有する。

原田 丈／Jo Harada
デロイト トーマツ サイバー合同会社

デロイト トーマツ サイバー参画後、CCoE（Cybersecurity Center of Excellence）組織構築に係る立ち上げ支援や個人情報保護に係るPIA（Privacy Impact Assesment）の運用支援等、一貫してサイバーセキュリティ関連の案件に従事。

※所属などの情報は執筆当時のものです。