SBOMに関する⽇本及び⽶国における動向や取組について
経済産業省

商務情報政策局

サイバーセキュリティ課
三⽥真史

１．はじめに~ソフトウェアに関する事例、SBOMに関する国内外の動向・取組等

２．ソフトウェアタスクフォースにおける取組（１）~OSS管理⼿法に関する事例集策定

３．ソフトウェアタスクフォースにおける取組（２）~SBOMの利活⽤に関する実証1

SolarWinds Orion Platformのアップデートを悪⽤した攻撃 2020年12⽉13⽇、SolarWinds社は同社のネットワーク監視ソフトウェア「Orion Platform」に、正規のアップデートを通じてマルウェアが仕込まれたことを公表。⽶政府機関等を含む最⼤約18,000組織が影響を受けたとされる。

Kaseya VSAの脆弱性を利⽤したサプライチェーンランサムウェア攻撃 2021年7⽉、⽶国のKaseya社は、同社のリモートIT管理サービス「Kaseya VSA」をオンプレミスで利⽤している企業に対するランサムウェア攻撃が発⽣していると発表。
 Kaseya VSAはマネージドサービスプロバイダー（MSP）に導⼊されていることが多く、複数のMSPが攻撃を受けたことで被害範囲が拡⼤し、攻撃を受けた可能性のあるユーザー企業は全体で1,500組織と推計されている。

Apache Log4jの脆弱性︓Log4Shell（CVE-2021-44228等）
 2021年12⽉、Javaベースのオープンソースログ出⼒ライブラリApache Log4jにおける任意コード実⾏の脆弱性が発表。
 この脆弱性を利⽤することで、Log4jが動作するアプリケーションに対して外部からの任意コード実⾏が可能となり、情報漏えいやマルウェア感染等の被害に繋がる恐れがあり、脆弱性に対処するよう注意
喚起がなされた。
2

⽶国の動向・取組等

3

国家のサイバーセキュリティの改善に係る⽶国⼤統領令の署名
 2021年5⽉12⽇、バイデン⼤統領は、連邦政府機関におけるサイバーセキュリティ改善に係る⼤統領令に署名。
 官⺠での脅威情報の共有、ソフトウェアサプライチェーンセキュリティ対策の強化、ゼロトラストアーキテクチャへの移⾏等を通じて、連邦政府機関のサイバーセキュリティ対応能⼒の向上を図っている。

本⼤統領令における主な指⽰事項
1

官⺠の脅威情報共有における障害の除去(Section 2)2

連邦政府におけるより強⼒な標準の近代化と導⼊ (Section 3)

3

 NISTを通じて政府が調達するソフトウェアの開発に関するセキュリティ基準(安全な開発環境の確保や構成要素に関する詳細（SBOM）の開⽰等を含む)を確⽴し、特に重要なソフトウェアに対して⼀定の対策を義務づける。
 商務省は、既存のラベル表⽰などを参考にして、消費者向けの情報提供に関するパイロット制度を開始する。

ソフトウェア・サプライチェーンのセキュリ
ティ向上 (Section 4)4

5

6

サイバー安全審査委員会の創設 (Section 5)
インシデント対応のための標準プレイブックの策定 (Section 6, 7)
調査及び修復能⼒の向上

 ⼤統領令では、ソフトウェア・サプライチェーンの確保に向け、
NISTが中⼼となりガイドラインを策定する旨を指⽰しており、このガイドラインには製品購⼊者に対するSBOM提供に関す
る項⽬も含まれる。
 将来的には、公開されたソフトウェア・サプライチェーンに関するガ
イダンスの要求事項に基づき、連邦政府のソフトウェア調達に関するFAR（連邦調達規則）が改正される予定である。

(Section 8)（出典）各種公開情報より作成

4

（参考）SBOMについて
 SBOM （Software Bill of Materials）とは、ソフトウェアの部品構成表のこと。ソフトウェアを構成する各コンポーネントを誰が作り、何が含まれ、どのような構成となっているか、等を⽰す。
 SBOMによりソフトウェアの構成情報の透明性を⾼めることで詳細を把握することができ、ライセンス管理や脆弱性対応への活⽤が期待される。
SBOMの構成イメージ

SBOMの導⼊効果︓脆弱性発覚から復旧までの時間を短縮

SBOMなし脆弱性発覚
パーツ ︕
コンポーネント

パーツの修正により、当該パーツを利⽤していたコンポーネントでも修正が必要なことが発覚。対応が後⼿に。

︕

修正・対応

最終製品

︕

軽減措置

SBOMあり

オペレータ

︕

時間経過

パーツ ︕
︕
コンポーネント︕

対応完了までの時間短縮

最終製品 ︕
オペレータ ︕

軽減措置

修正・対応

脆弱性の存在をSBOMにより即座に認識、対応開始。
https://www.ntia.doc.gov/SoftwareTransparency

5

（参考）SBOMの「最⼩要素」の定義
 ⼤統領令を受け、NTIAは当該定義に関するパブリックコメントを実施。ソフトウェア関連の企業や専⾨家からの意⾒を踏まえ、SBOMの「最⼩要素」の定義を2021年7⽉12⽇に公開。
 SBOMの「最⼩要素」には、「データフィールド」、「⾃動化サポート」、「プラクティスとプロセス」の3つのカテゴリが含まれ、コンポーネントを⼀覧化した部品表に含まれる情報だけでなく、SBOMの
利活⽤者が実施すべき事項も規定されている。
3つのカテゴリ「最⼩要素」の概要「最⼩要素」の具体的な定義
以下の情報をSBOMに含めること。

データフィールド（Data Fields）

各コンポーネントに関する基本情報を明確化すること

⾃動化サポート（Automation
Support）

SBOMの⾃動⽣成や可読性などの⾃動化をサポートすること

プラクティスとプロセス（Practices andProcesses）

SBOMの要求、⽣成、利⽤に関する運⽤⽅法を定義すること出所）NTIA, “The Minimum Elements For a Software Bill of Materials (SBOM)”
https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom• サプライヤー名• コンポーネント名• コンポーネントのバージョン• その他の⼀意な識別⼦• 依存関係• SBOMの作成者• タイムスタンプ

SBOMデータは機械判読可能かつ相互運⽤可能なフォーマットを⽤いて作成され、共有されること。現状では、国際的な議論を通じて策定された、SPDX、CycloneDX、SWIDタグを⽤いること。
SBOMを利活⽤する組織は、以下の項⽬に関する運⽤⽅法を定めること。
• SBOMの作成頻度• SBOMの深さ• 既知の未知• SBOMの共有• アクセス管理• 誤りの許容6

【⽶国】ソフトウェアサプライヤーのためのSBOMプレイブック
 2021年11⽉、NTIAはソフトウェアサプライヤーを対象としたSBOM作成に関するプレイブックを公開。
 本プレイブックでは、SBOM作成⼿順、SBOM作成に当たって考慮すべき事項及びSBOMに関する補⾜事項についてまとめられている。
ソフトウェアサプライヤーのためのSBOMプレイブックの概要
SBOM作成⼿順
ソフトウェア開発組織は多様であり、様々なソフトウェ
アやシステムに対してSBOMを作成することが必要である。
開発組織は様々なツールやプロセスを⽤いて、SBOMを作成することが可能である。SBOM作成⼿順は⼀般的に以下の⼿順となる。
1. コンポーネントの特定対象となるソフトウェアに含まれるソフトウェアコン
ポーネントを特定する。
2. コンポーネント情報を取得特定したソフトウェアコンポーネントに関する情報を取得する。
3. SBOM形式への出⼒
コンポーネント情報を、構造化されたSBOM形式
へ出⼒する。
4. SBOMの検証作成したSBOMフォーマットが有効であるかを検証し、コンポーネントに最低限の属性情報が存在することを確認する。

SBOM作成に当たって考慮すべき事項
•

•

•

•

•

SBOM作成の⾃動化
ビルド前のソースレベルのSBOMの⽣成にあたっては、ソフトウェアバージョン管理ツールやCI/CDパイプライン※1などを活⽤することで、SBOMを⾃動作成することが可能となる。
コンテナイメージに対するSBOMの作成
コンテナイメージには、様々なソフトウェアアプリケーション
や、様々なレイヤに組み込まれたアーティファクトが含まれる。そのため、全レイヤの全ソフトウェアを特定し、SBOMに記述する必要がある。
SBOM作成⽇時の明確化
ビルド後に作成されたSBOMの場合、いつSBOMが作成されたかを明確化するために、SBOMの作成⽇時に関する情報を含める必要がある。
SBOMに含まれる情報の明確化
アプリケーションとともに利⽤者に提供される追加のコン
ポーネント情報（ダイナミックリンクライブラリ、共有ライブ
ラリ 等）がSBOMに含まれるか、利⽤者に明⽰する必要がある。
外部サービスの明確化
アプリケーションが機能を実⾏するために、インターネット
サービスを呼び出す場合、当該サービスに関する情報を可視化する必要がある。ただし、これは検討段階である
ため、SBOMの最⼩要素としては含まれていない。

SBOMに関する補⾜事項•••

SBOMの知的財産/機密性
SBOM情報は中間サプライヤーを介して最終利⽤者に提供される必要がある。SBOMの配布を妨げるのではなく、契約上の機密情報として
SBOMを扱うように機密保持体制を構築することが望まれる。
SBOMフォーマットの検証
SBOMのフォーマットが有効であるか（必要な情報が存在し、構造化されているか）を確認する。
活⽤できるツールの例は以下のとおり。
・SPDXOnline Tool: SPDX形式の検証ツール
・SWID Tools: SWID形式の検証ツール
・CycloneDX CLI Tool、Web Tool:
CycloneDX形式のSBOM検証ツール
コンポーネント情報の検証
SBOMに含まれるコンポーネント情報の確からしさを検証する。活⽤できるフレームワークの例は以下のとおり。
・OWASP SCVS:
ソフトウェアコンポーネントの評価や改善⽅法の参考となるフレームワーク
・OpenChain（ISO/IEC 5230:2020）:
ソフトウェアコンポーネントの正確な特定と監視に必要となるプロセス管理標準※1: ソフトウェア配信プロセスにおけるステップの⾃動化を⽀援するツール
出所）NTIA, ” Software Suppliers Playbook: SBOM Production and Provision”
https://www.ntia.gov/files/ntia/publications/software_suppliers_sbom_production_and_provision_-_final.pdf

7

【⽶国】セキュアなソフトウェアを開発するためのフレームワーク（SSDF）
 2022年2⽉、NISTは、ソフトウェアの脆弱性を軽減するためのソフトウェア開発者向けの⼿法をまとめたフレームワークであるSSDF（Secure Software Development Framework）のVer. 1.1を公開（SP 800-218）。
 各⼿法は4つに分類され、⼿法を実践するためのタスクが体系化。各⼿法の実践により、脆弱性を低減するとともに、未対処の脆弱性が悪⽤された場合の影響を軽減し、脆弱性の再発を防ぐ根本原因に対処可能。
セキュアなソフトウェアを開発するための⼿法をまとめたフレームワーク（SSDF）
分類

⼿法

1. 組織の準備（PO）
ソフトウェアを開発する組織は、組織レベルで安全なソフト
ウェアの開発を⾏うために、適した⼈材、プロセス、技術を準備する必要がある。

•
•
•
•
•

2. ソフトウェアの保護（PS）
ソフトウェアを開発する組織は、ソフトウェアのすべてのコン
ポーネントを、改ざんや不正アクセスから保護する必要がある。

• あらゆる形態のコードを不正アクセスや改ざんから保護する（PS.1）• ソフトウェアリリースの完全性を検証する仕組みを提供する（PS.2）• 各ソフトウェアのリリースをアーカイブ化し、保護する（PS.3）

3. 安全なソフトウェアの開発（PW）
ソフトウェアを開発する組織は、脆弱性を最⼩限に抑え、⼗分なソフトウェアを備えたソフトウェアをリリースする必要がある。

•
•
•
•
•
•
•
•

4. 脆弱性への対応（RV）
ソフトウェアを開発する組織は、リリースするソフトウェアに残存する脆弱性を特定し、適切に対応する必要がある。

• 脆弱性に対する継続的な把握と確認を実施する（RV.1）• 脆弱性の評価、優先順位付け及び修正を実施する（RV.2）• 脆弱性を分析することで、その根本原因を特定する（RV.3）

ソフトウェア開発におけるセキュリティ要件を定義する（PO.1）
ソフトウェア開発における役割と責任を明確化する（PO.2）
ソフトウェア開発を⽀援するツールチェーンを明確化する（PO.3）
ソフトウェアのセキュリティを確認するための基準を定義し、活⽤する（PO.4）
ソフトウェア開発のための安全な環境を導⼊し、維持する（PO.5）

セキュリティ要件を満⾜するとともにセキュリティリスクを軽減できるよう、ソフトウェアを設計する（PW.1）
ソフトウェア設計をレビューし、セキュリティ要件やリスクへの適合性を検証する（PW.2）
実現可能な場合、機能を重複させずに既存の保護されたソフトウェアを再利⽤する（PW.4）
セキュアコーディングのプラクティスを遵守してソースコードを作成する（PW.5）
実⾏可能なセキュリティを向上させるために、コンパイル、インタプリター及びビルドプロセスを構築する（PW.6）
コードをレビュー・分析することで、脆弱性を特定し、セキュリティ要求事項への準拠を検証する（PW.7）
実⾏コードをテストして脆弱性を特定し、セキュリティ要求事項への準拠を検証する（PW.8）
ソフトウェアをデフォルトで安全な設定とする（PW.9）※ PW.3はPW.4の⼿法に統合されたため、定義されていないことに留意。また、PS.3のタスクの⼀つとして、SBOM等を⽤いたコンポーネントリストの⽣成・維持・共有に関するタスクが含まれている。
出所）NIST, SP 800-218 Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf

8

【⽶国】ソフトウェアサプライチェーンの確保に関する覚書の発⾏ 2022年9⽉14⽇、OMBは、安全なソフトウェア開発⼿法の実装を通じたソフトウェアサプライチェーンの確保に関する覚書を発⾏した。
 各省庁等の機関に対して、本覚書発⾏後⼀定期間内に、機関が使⽤するソフトウェアの⽬録作成や、NISTのガイダンスに基づく⾃⼰適合証明書をソフトウェアベンダーに要求することなどが求められている。
 なお、SBOMに関しては、適合証明のために必要に応じてソフトウェアベンダーからSBOMを⼊⼿することができるとして推奨の位置付けとしている。
覚書の概要
政府関係機関は、安全なソフトウェア開発⼿法（SSDF）の実装を証明できるソフトウェアベンダーが提供するソフ
トウェアのみを使⽤すべきである。そのために、各機関の最⾼情報責任者（CIO）は、OMB及び最⾼調達責任者（CAO）と連携し、ソフトウェアベンダーによるSSDFの実装、実装の適合性を確保しなければならない。このために、機関は以下を実施する必要がある。
1. 機関は、ソフトウェア使⽤前に、SSDFの実装の適合性を証明する⾃⼰適合証明書の取得をソフトウェアベン
ダーへ要求する。
2. 機関は、必要に応じて、⾃⼰適合証明書に付随する成果物（SBOM等）をソフトウェアベンダーから⼊⼿することができる。
 対象ソフトウェア︓
ファームウェア、OS、アプリケーション、アプリケーションサービス（クラウドベースのソフトウェア）、ソフトウェアに使⽤されるOSS、ソフト
ウェアを使⽤する製品※ 機関によって開発されたソフトウェアや直接的に⼊⼿したOSSは対象外
 要件の適⽤範囲︓
覚書発⾏⽇以降に開発されたソフトウェア（既存ソフトウェアのメジャーバージョンアップ含む）を機関が使⽤する場合に適⽤される。
出所）OMB, ” Enhancing the Security of the Software Supply Chain through Secure Software Development Practices”
https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf

9【⽶国】 SBOMに係る取組の進展
 ヘルスケア分野における実証事業（PoC）のほか、⾃動⾞分野・電⼒分野のSBOMの取組を実施。

ヘルスケア分野 (病院、医療機器)
病院、医療機器メーカー、ベンダーが参加。2回のPoCを経てSBOM活⽤の⼿法、課題等を公開。医療機器メーカーにおけるSBOM活⽤に向けたガイドライン案を公開。2022年のPoCでは、SBOMの⾃動化やSBOMとVEXとの連携⽅法について検討するほか、多数の関係者を巻き込んだ場合のより現実的なSBOM共有⽅法について検討。

⾃動⾞産業分野
Auto-ISACを中⼼としたサプライヤー中⼼のプロジェクト。⾃動⾞産業分野でのSBOMの普及促進を⽬的として、SBOM活⽤に関するベストプラクティス⽂書を策定。

電⼒分野

INL主導で、電⼒会社、電⼒機器ベンダー、ソフトウェアベンダー、電気協会等が参加。⽶国エネルギー省からもプレゼンターとして参加。2022年のPoCでは、SBOMの作成⽅法やVEXの活⽤⽅法に関して検討。

10

（参考）VEXとは Vulnerability Exploitability eXchange（VEX）とは、ある製品が既知の脆弱性の影響を受けるかど
うかを⽰す機械判読可能なセキュリティ勧告の⼀つであり、⽶国NTIAを中⼼として開発された。
 VEXの主な⽬的は、製品利⽤者に対して、製品が特定の脆弱性の影響を受けるかどうか、そして影響を受ける場合に是正するために推奨されるアクションがあるかどうかの追加情報を提供し、製品サプライヤー及び利⽤者の双⽅のコスト・労⼒を軽減することにある。
VEXを導⼊することのメリットの例【SBOMのみを製品利⽤者に提供する場合】
製品サプライヤー

製品利⽤者

SBOMを付随した製品を納⼊
SBOMを踏まえて、コンポーネントに脆弱性が含まれていないかを評価した結果、複数の既知の脆弱性が含まれていることを確認【SBOM＋VEXドキュメントを製品利⽤者に提供する場合】
製品サプライヤー
SBOM＋VEXドキュメントを付随した製品を納⼊資産管理システムを使⽤してSBOMとVEXドキュメントを⾃動処理した結果、悪⽤可能な脆弱性は含まれていないことを確認
確認結果を踏まえ、製品を利⽤することを決定

脆弱性の影響やパッチ適⽤の必要性に関してサプライヤーに問い合わせ
問合せを受け、攻撃者は当該コンポーネントの脆弱性を悪⽤できず、脆弱性の影響を受けることが無い
ことを回答※ 複数の利⽤者から問合せを受ける可能性あり

回答を踏まえ、製品を利⽤することを決定

製品利⽤者

製品が既知の脆弱性の影響を受けるか否かを
VEXを⽤いて説明することで、製品サプライヤー及び利⽤者の双⽅のコスト・労⼒を軽減可能

出所）NTIA, ”Vulnerability Exploitability eXchange(VEX) – An Overview” https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf
NTIA, “Framing Working Group” https://www.ntia.doc.gov/files/ntia/publications/framing_2021-04-29_002.pdf

11経済産業省の取組等

12産業分野別での具体化 と 分野横断的な検討
 7つの産業分野別サブワーキンググループ（SWG）を設置。CPSFに基づくセキュリティ対策の具体化・実装。
 分野横断の共通課題を検討する、3つのタスクフォース（TF）を設置。
産業サイバーセキュリティ研究会ＷＧ１（制度・技術・標準化）

標準モデル（CPSF）

Industry by Industryで検討(分野ごとに検討するためのSWGを設置)

ビルSWG『サイバー空間におけるつながり』の信頼性確保『第3層』 TF︓に向けたセキュリティ対策検討タスクフォース

検討事項︓
 「協調的なデータ利活⽤に向けたデータマネジメント・フレームワーク」の策定

分
電⼒SWG• ⼩売電気事業者ガイドライン策定(2021.2) 野ソフトウェアTF︓ サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理⼿法等検討タスクフォース
防衛産業SWG
横• 防衛産業サイバーセキュリティ基準の改訂
検討事項︓(2022.4)
断  OSSの管理⼿法に関する事例集の策定
⾃動⾞産業SWG
 SBOM活⽤促進に向けた実証事業（PoC）の実施
S• ガイドライン2.0版の策定(2022.4)
スマートホームSWG
W 『第2層』 TF︓『フィジカル空間とサイバー空間のつながり』の信頼性確保に向けたセキュリティ対策検討タスクフォース• ガイドライン1.0版の策定(2021.4)
G 検討事項︓
宇宙産業SWG• ガイドライン第1版の策定(2019.6)• ガイドライン1.0版の策定(2022.8)

⼯場SWG• ガイドライン1.0版の策定（2022.11）

・・・

 フィジカル空間とサイバー空間のつながりの信頼性の確保するための「IoTセキュリティ・セーフティ・フレームワーク(IoT-SSF)」の策定
 IoT-SSFをわかりやすく理解するためのユースケースの策定

13

(参考)「Society5.0」の社会を⾒据えた対策の検討
 「Society5.0」では、データの流通・活⽤を含む、より柔軟で動的なサプライチェーンを構成することが可能となる。⼀⽅で、サイバーセキュリティの観点では、サイバー攻撃の起点の拡散、フィジカル空間への影響の増⼤という新たなリスクへの対応が必要となる。
 サイバー・フィジカル・セキュリティ対策フレームワークを策定し、必要な対策を検討。
サイバー空間で⼤量のデー
タの流通・連携⇒データの性質に応じた管理の重要性が増⼤

フィジカル空間とサイバー空間の融合⇒フィジカル空間まで
サイバー攻撃が到達

企業間が複雑につながるサプライチェーン
⇒影響範囲が拡⼤

CPSFのモデル＜3層構造＞【第３層】
サイバー空間におけるつながり【第２層】
フィジカル空間とサイバー空間のつながり【第１層】
企業間のつながり＜6つの構成要素＞
ソシキ

ヒト

モノ

データ

プロシージャ

システム

Society5.0の社会におけるモノ・データ等の繋がりのイメージ

14

１．はじめに~ソフトウェアに関する事例、SBOMに関する国内外の動向・取組等

２．ソフトウェアタスクフォースにおける取組（１）~OSS管理⼿法に関する事例集策定

３．ソフトウェアタスクフォースにおける取組（２）~SBOMの利活⽤に関する実証

15

OSS管理⼿法に関する事例集の策定

https://www.meti.go.jp/policy/netsecurity/wg1/ossjirei_20220801.pdf

 OSSの留意点を考慮した適切なOSS利⽤の促進
 企業がOSSを利活⽤するに当たって留意すべきポイントを整理。
 そのポイントごとに参考となる事例を、具体的な個別企業ヒアリング等により取りまとめ公開。
 企業のOSS利⽤の障壁を取り除くことで、⼀層のOSS利活⽤を促進。
 産業界においてOSSのメリットを享受することで競争⼒を向上
OSSに関する課題例
ライセンス管理
脆弱性管理
サプライチェーン管理
組織体制
コミュニティ活動

OSS事例集で紹介する取組例
 スキャンツールを⽤いてソフトウェア部品構成表（SBOM）を作成。
 脆弱性やライセンス等について、抜け漏れのないリスク管理を実施。
 安全確認したOSSの登録・利⽤、良質なOSS選定のため評価結果のレーダー
チャート化等に係るシステムの構築。
 サプライヤからの部品・ソフトウェア納⼊の際に、確認書を提出。
 OpenChain Japan WGを活⽤し、サプライヤの理解促進。
 サポート終了リスク、⻑期間利⽤での脆弱性管理やアップデート対応に係るコストの考え⽅等について、顧客と事前合意。
 OSS利活⽤プロセスを全社ルール化して、トップダウンで適⽤を指⽰。適⽤プロ
ジェクトを増やし、⾼い効果に結実。
 社員に対して、就業時間内でのOSS開発等を容認。
 ⾃社開発のソフトウェアをOSS化し、コミュニティ型開発により性能向上。
16

（参考） OSS管理⼿法に関する事例集の主な掲載事例
 OSSの利⽤が広がる⼀⽅、⾃社だけでOSSを検証するための体制等を整える負担は⼤きく、ベストプラク
ティスを共有することに対するニーズが存在していることを踏まえ、「OSSの利活⽤及びセキュリティ確保に向けた管理⼿法」をまとめた事例集を作成し、2021年4⽉21⽇に公開（2022年8⽉事例を拡充）。

主な掲載事例
ヒアリング調査• トヨタ⾃動⾞
︓サプライチェーンにおけるソフトウェア使⽤状況把握• ソニー
︓各事業部による主体性のある取組• オリンパス︓ヒヤリ・ハット事象を契機とした全社的取組• ⽇⽴製作所
︓製品化の過程における徹底したOSS管理• オムロン
︓PSIRTの連携を通じたOSS対応• 東芝
︓グループにおける⼀貫したOSS対応体制• デンソー
︓サプライチェーン全体における最適なOSS管理• 富⼠通
︓部⾨横断のOSS対応体制と全社統⼀的なソフトウェア管理• NEC
︓事業部毎の取組から全社的取組へ• NTT
︓OSSサポートに係る適切な役割分担• 損害保険ジャパン ︓ソフトウェア部品構成表を活⽤した脆弱性管理• Visionalグループ ︓⾃社状況に対して最適なツールの利⽤• サイボウズ︓OSSエコシステムに貢献するOSSポリシー
⽂献調査• マイクロソフト
︓OSSに係るセキュリティリスク緩和策• ザランド︓OSSプロジェクトの全社的な推進• Linux Foundationとハーバード⼤学によるCensusⅡプロジェクトの予備的レポート
︓アプリケーションに最も利⽤されているFOSSコンポーネントに関する調査
17

１．はじめに~ソフトウェアに関する事例、SBOMに関する国内外の動向・取組等

２．ソフトウェアタスクフォースにおける取組（１）~OSS管理⼿法に関する事例集策定

３．ソフトウェアタスクフォースにおける取組（２）~SBOMの利活⽤に関する実証18

SBOM導⼊・活⽤に向けた課題
 SBOM活⽤による効果が想定される⼀⽅で、導⼊コスト等が障壁となり、活⽤が進んでいない。
 実証事業において、どうSBOMを活⽤すれば、導⼊効果が⼤きくなり、普及に繋がるかを確認。

 SBOM導⼊にかかるコスト– 効果に対してどの程度のコストをかけるべきか判断に必要な情報が少ない。
– 多数のSBOMを⼿動で管理するとコストが膨⼤になるためツールによる⾃動化が考えられるが、下記のような課題が存在。
•

ツールの導⼊コスト・ランニングコストが発⽣。

•

ソフトウェアIDやSBOM形式が統⼀されていないなど、⾃動化の障害が存在。

 SBOM⽣成・情報開⽰に対するサプライヤーの強い抵抗感

192021年度 SBOM実証事業の内容
SBOM作成⼿段や作成者等の条件を設定して、効果やコストを⽐較し、今後の検討事項を整理。
⽐較項⽬
 SBOMの効果– 脆弱性管理

脆弱性特定⼯数、脆弱性修正までの期間、脆弱性残留リスク等の低減– ライセンス管理

ライセンス特定⼯数、ライセンス違反残留リスク等の低減

 SBOMのコスト– 初期コスト

体制構築、環境整備– SBOM作成コスト

作成⼯数、作成ツール費⽤– SBOM活⽤コスト

部品管理⼯数（脆弱性の影響特定など）、管理ツール費⽤

⽐較条件– そもそもソフトウェアの部品管理を⾏わない場合– SBOMという形ではないが、何らか部品管理を実施する場合– SBOMをユーザーが作成する場合– SBOMをベンダーが作成する場合（⼿動で⾏う場合、ツールを利⽤する場合）

 実証を通じてSBOMの実際の効果やコストを算出。
 国外の取組の進展も踏まえ、SBOMの効果的な活⽤⽅法を検討、今後の検討事項を整理。

20

SBOM実証のシナリオ、まとめ（2021年度の取組）
 実証では、従来の部品管理を含む4つのシナリオに関し、SBOM等の作成、活⽤に係る⼯数・費⽤を計測。

実証体制（GARDENのサプライチェーン）
Covalent（ユーザー企業）

GARDENを活⽤した
開発⽀援コンサル／
安全性検証
⾃動⾞OEM／

部品サプライヤー等

GARDEN（実証対象ソフトウェア）• NTTD ARCの開発部品

NTTデータARC • サプライヤーの開発部品• OSS（製品ベンダー）
OSS
OSS

ツールのフォーマットに合わせて⼿作業でSBOMを作成。
脆弱性やライセンスの特定はそれぞれOSSの無償ツールで実施。

③SBOM(無償ツール)④SBOM(有償ツール)
OSSコミュニティOSS
OSS

Excelの独⾃形式で⼿作業管理。
脆弱性やライセンスの情報は⼿作業で検索。

OSSの無償ツールによりSBOMを作成。
脆弱性やライセンスの特定はそれぞれOSSの無償ツールで実施。

SBOM

CPIZS
（サプライヤー）①従来の部品管理(独⾃形式)②SBOM(⼿動作成)

ベンダー作成SBOM

ソフト部品
ソフト部品

実証のシナリオ

有償ツールにより、SBOM作成、脆弱性管理、ライセンス管理
をシームレスに実施。

凡例 実証参加企業

21

（参考）実証における⽐較条件
 NTTデータARC社が従来から⾏っていた独⾃形式の部品管理と、SBOMを使った部品管理について、
SBOM等の作成、脆弱性管理、ライセンス管理の費⽤・⼯数を計測。
 ツールは、SBOM標準への準拠性から、SPDX projectおよびNTIA Formats and Tooling
WGの提供⼀覧から選出。中⼩企業への普及も考慮し、無償ツールと有償ツール間も⽐較。
シナリオ

SBOM等（部品情報）の作成①従来の部品管理(独⾃形式)

ベンダーおよびサプライヤーが、⼿作業で、
Excel独⾃形式の「OSS⼀覧」を作成。

②SBOM(⼿動作成)

ベンダーおよびサプライヤーが、SBOM作
成ツールのフォーマットに合わせ⼿作業。

③SBOM(無償ツール)④SBOM(有償ツール)

脆弱性管理

ライセンス管理

NVD等の脆弱性DBの⼿動検索や公開
Web検索によりライセンス情報を確認。
情報収集を通じて脆弱性の発⽣を確認。

作成したSBOMを、脆弱性管理ツールにベンダーおよびサプライヤーが、部品構成
⼊⼒して脆弱性の有無を特定。
ファイルを無償ツールに読み込ませて作成。
使⽤ツール︓Grype
使⽤ツール︓Scancode-Toolkit、Syft、
FOSSology

SBOMを活⽤したライセンス管理ツールによりライセンス情報を確認。
（他ツールで作成したSBOMファイルが読み込めず、SBOM作成機能も持つツール
を⽤い、ソースコード検索により実施。）
使⽤ツール︓FOSSology

有償ツールの機能により、SBOM作成、脆弱性管理、ライセンス管理をシームレスに実施。
ユーザーが、ベンダーから受領したPython仮想環境（ソースコード、部品構成ファイル、実⾏に必要なOSSを含む）をツールに読み込ませてSBOMを作成。
使⽤ツール︓Black Duck

※ 本事業では、SBOMの定義は、NTIAの定義「ソフトウェアを構成する部品の詳細情報とサプライチェーンにおける関係を標準的な形式で記録したもの」を採⽤し、個社独⾃形式で企業間での共有を前提しない部品情報とは区別。
SPDX project︓https://spdx.dev/spdx-tools/
NTIA Formats & Tooling WG︓https://ntia.gov/files/ntia/publications/ntia_sbom_tooling_2021-q2-checkpoint.pdf

222021年度の検討結果（まとめ） R3年度の実証事業で、ソフトウェアの成分構成を表すSBOM（Software Bill ofMaterials）を活⽤することの有効性は確認。
 SBOMは初期⼯数（ツール導⼊等の環境整備、学習等）が⼤きいが、運⽤⼯数（SBOM作成、活⽤）は従来の⼿作業部品管理に⽐べ⼩さい結果となり、管理対象のソフトウェア部品が多いほど、SBOM導⼊効果が⼤きくなる ⼀⽅で、実際にビジネスで活⽤するためには課題も多い。
 産業分野ごとの状況を踏まえ、「規制や推奨化が⾒込まれる分野」や「効果が⼤きいと思われる分野」等を候補に実証を継続。
1. SBOM活⽤モデルの最適化•産業分野によっては規制等の動きもあるため、産業分
野の状況に応じたSBOMの効果的な活⽤モデルを整理。

2. SBOM共有のための環境整備•各分野等における標準的なSBOMの項⽬、粒度、
フォーマット、部品命名規則等の整理。
•契約、責任、費⽤負担の整理。

3. SBOM⾃動⽣成ツールの活⽤促進による効率化

4. 国際的な基準との整合性確保•SBOMツールの導⼊や利⽤⽅法に係る情報発信、ノウハウの共有による導⼊⼯数の低減。

•グローバルサプライチェーンにおいて国内と海外の整合性を確保しつつ効率的に部品管理を⾏うためには、国内外の基準の整合化が必要。
23

2022年度の実証内容・体制
 SBOMに関して「規制や推奨化が⾒込まれる分野」や「効果が⼤きいと思われる分野」
を候補に、実証参加企業の選定、実証内容を設計。
 実証結果や⺠間で進められているSBOM活⽤の取組について、知⾒等を共有し、実際の活⽤⽅法を検討。
経済産業省

事業委託先

⾃動⾞業界
（OEM/部品サプライヤー等）

 実証の対象分野／組織の選定
 SBOMの効果に係る評価の観点、項⽬の整理
 調達時のリスク評価（脆弱性、ライセンス、サポート期間、ベンダー評価）
 運⽤時の脆弱性対応（脆弱性および影響の特定〜対応の時間短縮、特定漏れの低減等）
 資産管理（システムや機器の更新判断、計画）
 供給者管理（契約書における責任分界点等の規定）
 SBOM活⽤モデルの選択肢の整理
 参加者の知⾒共有の仕組み（定期的な会議開催等）の検討
 これまでの調査、検討結果や、国内外の動向等の共有

医療機器業界（医療機器メーカー等）

SBOMに関する規制や推奨化が⾒込まれる分野

ソフトウェア業界（ITベンダーとそのサプライチェーン等）
知⾒を共有

 規制等において定められるSBOMへの要求事項を満たしつつ、効率的にSBOMを作成、活⽤していくモデル（作成者、作成／共有⽅法、最低限含むべき項⽬やフォーマット等）を検討。
 ⽶国NTIAにおける既存のPoCについて得られる情報を確認、活⽤。

SBOMの効果が⼤きいと思われる分野

 社内システム及び顧客向けシステム／サービスを多く管理し、SBOMを多様なサプライヤーやユーザーと共有し、メリットを最⼤限享受できる活⽤モデルの検討。
 開発環境や構成管理ツール等との連携など、ツール環境に関する知⾒や課題の整理。
24

実証の全体構成
 実証の⽬的や産業分野ごとの法制度等を考慮し、以下の実施体制等により実証を実施。

 成果⽬標産業分野ごとのリスク、法制度に応じて、SBOMを⽤いた部品のリスク管理を効果的に⾏うための⽅法についてコスト・効果の⽐較評価を⾏い、現実的な適⽤範囲と課題について整理する。
– 実証を通じて、初級者向けSBOM導⼊ガイダンス、SBOMの適⽤範囲を例⽰するSBOM対応モデル、取引契約の例⽰によりSBOM導⼊を促進するSBOM取引モデルの主な契約事項を整理することを⽬的とする。
– 法的な要件化が進む医療機器分野、⾃動⾞分野および、効果が期待できるソフトウェア分野について、実ソフトウェアに対するサプライチェーンを考慮した体制により、評価を⾏う。
実施体制等（実証の実施者・関係者及び対象製品など）
–

分野

関連する
業界団体

医療機器

⽇本医療機
器産業連合
会

⾃動⾞

（⽇本⾃動
⾞⼯業会）

ソフトウェア

ソフトウェア協会

ユーザ

実証実施企業及び関係企業など
最終ベンダ（製品ベンダ、 ティア1
ティア2
インテグレータ）
サプライヤ
サプライヤ

ヒアリング協⼒︓ 近畿レントゲン⼯業
⼤学附属病院 （製品ベンダ）

個⼈(トヨタ⾃動⾞助⾔)（製品ベンダ）

トレンドマイクロ、
さくらインターネット、
法⼈
コラボスタイル(ヒアリング協⼒)(製品ベンダ、インテグレー
タ）ライフサイエンスコンピューティ
ング

東海理化

サードパティ
サプライヤ

Microsoft,
Google等

サニー技研

関連法制度
（前提となる基準等）

対象製品

(厚労省)
医療機器 基本要件基準 ⼀部改正案
JIS T 81001-5-1制定案
医療機器製販業者向けサイバーセキュリティ⼿引
書改訂(案)
⻭科⽤CT
医療機関向けサイバーセキュリティ⼿引書(案)(国際)N60 IMDRFガイダンス
N73 IMDRF追補ガイダンス案(⽶国) FDA 市販前ガイダンス案(国交省)道路運送⾞両の保安基準
BROADCOM(国際)UN-R155, 156,OSSベンダ等(⽶国)NHTSAガイダンス

⾃動⾞ヒー
ター
コントローラAdobe,
Amazon,Microsoft等

ネットワーク
脅威検知、
データセン
ター、業務フロー管理
SaaS(⽶国)NISTサプライチェーン
ガイダンス, FedRAMP

25

実証で抽出された主な課題と解決策（抜粋）
実証で抽出された課題に基づき、解決ノウハウの検討や今後の取組施策の整理。
解決ノウハウ（導⼊ガイダンスに反映予定）

今後の課題（国、⺠間）

⾃動⾞

実証から抽出した課題

医療機器

区
分

技術
管理

検出した脆弱性の対応要否、優先度の判断が困
難

医療機器分野の脆弱性対応フローなどを参考にアドバイザ 脆弱性管理の⾼度化、脅威情報の普及促●
リ、脅威情報を活⽤し、対応の要否、優先度を判断。
進

SBOMツールの使い分け・変更による負担増⼤

機能ニーズを洗い出し、ツール⽐較情報をもとに選択

CI/CDなど継続的なアップデートへの対応負担

ツールによる⾃動化可能な範囲で管理

CI/CDに対応した⾃動管理

SBOM初期導⼊、ツール等のコスト負担が⼤きい

ツールの効率的な導⼊⽅法、OSSツールの選択活⽤

OSSベースのツール整備

SBOMに要求される精査のレベルが不明確

SBOM対応モデルの選択肢やSBOMツールの機能に応じて精査の要否を判断する。

―● ●SBOM⽣成の対象範囲が不明確

OS,MWを含めて対象全体の上位構成を事前に明確化

―

● ● ●

ツールの環境構築、SBOM共有のコストが⼤きい

SaaS型SBOMツールで初期導⼊と共有の⼯数を低減

ユーザ組織によるSBOMの活⽤・管理が困難

SBOMツール導⼊、ベンダ⽀援の活⽤部品の脆弱性残存期間に応じたリスク評価

SBOMの履歴管理により脆弱性残存期間を特定―

サプライチェーンを通じた脆弱性管理
―

● ● ●
●
● ● ●

● ● ●
● ● ●

脆弱性の履歴評価●

開発部署、PSIRTなど部署ごとの脆弱性管理が⾮ 社内でSBOMを⼀元管理することで、脆弱性管理を効率
効率化

SBOMによる脆弱性の社内⼀元管理● ●サプライヤごとの部品粒度のバラつき

取得したすべての粒度をツールで⾃動管理脆弱性マッチングの⾼度化●

サプライヤのサポート切れなどのリスク対応

部品のEOL等に基づくサポート計画・管理を実施

取引

―

●

サードパーティからのSBOM取得が困難、バイナリ納 ソースコード取得とSBOMツールの適⽤、（バイナリ納品の品物の脆弱性の監視・修正が負担場合）SBOM提供と脆弱性修正を契約で要件化

―

● ● ●

サプライヤ部品の精査コストが⼤きい―● ●SBOMの提供と信頼性に関する責任を契約で規定

26

本実証結果等を踏まえた検討について


本実証結果等を踏まえ、導⼊の⼿引、対応モデル、取引モデルから構成されるSBOMに関するガイダンス（SBOM導⼊ガイダンス）を作成予定。



初級者向けSBOM導⼊の⼿引→ 対応モデル → 取引モデル を順次活⽤し、サプライチェーンにおける信頼を確保。

SBOM導⼊ガイダンスは、以下の３部から構成予定。
第１部 初級者向けSBOM導⼊の⼿引︓導⼊初期の課題、阻害要因を解消するための開発者向けのヒント・TIPS等。
効率的な適⽤⽅法。（実証の成果やNTIA SBOM Playbook等の関連する内容を盛り込む）
第２部 対応モデル︓業界として期待される開発者向けのSBOM対応レベル（ミニマム・コンセンサス）。
第３部 取引モデル︓対応モデルを契約でどのように担保するか契約担当向けの例⽰。要件・責任関係の明確化

SBOM導⼊ガイダンス（三部構成）
第１部
第２部
第３部
初級者向け
SBOM
SBOM
SBOM
対応モデル
導⼊の⼿引
取引モデル

導⼊初期の
障壁解消等

開発部⾨、製品セキュリティ担当部⾨、法務・知財部⾨など

導⼊初期の
障壁解消等

開発者向け

第２部
SBOM
対応モデル

開発部⾨、製品セキュリティ担当部⾨、法務・知財部⾨など

導⼊初期の
障壁解消等

最終ベンダ/
インテグレータ

サプライヤー
サプライヤー
ミニマムコンセンサス

第１部
初級者向け
SBOM
導⼊の⼿引

第１部
初級者向け
SBOM
導⼊の⼿引

第１部
初級者向け
SBOM
導⼊の⼿引

企業間
取決め

契約に
よる担保

契約担当
ミニマム
向け

第３部
SBOM
取引モデル

コンセンサス

開発者向け

第２部
SBOM
対応モデル

開発部⾨、製品セキュリティ担当部⾨、法務・知財部⾨など

ユーザ企業等
企業間
取決め

契約担当
向け

第３部
SBOM
取引モデル
契約に
よる担保

ミニマム
コンセンサス

開発者向け

第２部
SBOM
対応モデル
27

実証で抽出された主な課題と解決策（抜粋）（再掲）
実証で抽出された課題に基づき、解決ノウハウの検討や今後の取組施策の整理。
解決ノウハウ（導⼊ガイダンスに反映予定）

今後の課題（国、⺠間）

⾃動⾞

実証から抽出した課題

医療機器

区
分

技術
管理

検出した脆弱性の対応要否、優先度の判断が困
難

医療機器分野の脆弱性対応フローなどを参考にアドバイザ 脆弱性管理の⾼度化、脅威情報の普及促●
リ、脅威情報を活⽤し、対応の要否、優先度を判断。
進

SBOMツールの使い分け・変更による負担増⼤

機能ニーズを洗い出し、ツール⽐較情報をもとに選択

CI/CDなど継続的なアップデートへの対応負担

ツールによる⾃動化可能な範囲で管理

CI/CDに対応した⾃動管理

SBOM初期導⼊、ツール等のコスト負担が⼤きい

ツールの効率的な導⼊⽅法、OSSツールの選択活⽤

OSSベースのツール整備

SBOMに要求される精査のレベルが不明確

SBOM対応モデルの選択肢やSBOMツールの機能に応じて精査の要否を判断する。

―● ●SBOM⽣成の対象範囲が不明確

OS,MWを含めて対象全体の上位構成を事前に明確化

―

● ● ●

ツールの環境構築、SBOM共有のコストが⼤きい

SaaS型SBOMツールで初期導⼊と共有の⼯数を低減

ユーザ組織によるSBOMの活⽤・管理が困難

SBOMツール導⼊、ベンダ⽀援の活⽤部品の脆弱性残存期間に応じたリスク評価

SBOMの履歴管理により脆弱性残存期間を特定―

サプライチェーンを通じた脆弱性管理
―

● ● ●
●
● ● ●

● ● ●
● ● ●

脆弱性の履歴評価●

開発部署、PSIRTなど部署ごとの脆弱性管理が⾮ 社内でSBOMを⼀元管理することで、脆弱性管理を効率
効率化

SBOMによる脆弱性の社内⼀元管理● ●サプライヤごとの部品粒度のバラつき

取得したすべての粒度をツールで⾃動管理脆弱性マッチングの⾼度化●

サプライヤのサポート切れなどのリスク対応

部品のEOL等に基づくサポート計画・管理を実施

取引

サードパーティからのSBOM取得が困難、バイナリ納 ソースコード取得とSBOMツールの適⽤、（バイナリ納品の品物の脆弱性の監視・修正が負担場合）SBOM提供と脆弱性修正を契約で要件化
サプライヤ部品の精査コストが⼤きい

SBOMの提供と信頼性に関する責任を契約で規定――
今後の課題として脆弱性管理・マッ
チングに係るものが多い
―

●
● ● ●
● ●

28

サイバーセキュリティに関する⽶国国⼟安全保障省（DHS）との⼤⾂級MOC
 2023年1⽉6⽇、マヨルカス国⼟安全保障⻑官と⻄村経産⼤⾂が会談し、⼈権タスクフォースへの協⼒を確認するとともに、サイバーセキュリティに関するMOCに署名。
 今回のMOCでは、①「国家安全保障戦略」の改定を踏まえた経済産業省と国⼟安全保障省との協⼒関係の深化、②「開かれたインド太平洋（FOIP）」の実現に向けたインド太平洋における能⼒構築、③サイバーセキュリティ制度調和の促
進、の実現を⽬指す。
【MOC概要】経済産業省と⽶国国⼟安全保障省は、⾼度化し増加し続けるサイバー攻撃への対応のため、関係機関からの協⼒も得ながら、以下のサイバーセキュ
リティ分野について協⼒を⾏う。
＜協⼒分野＞
 運⽤⾯での協⼒
 制御システムセキュリティの向上
 インド太平洋地域等の能⼒向上に関する協⼒ サイバーセキュリティ関連規制及びスキームの＜MOC改定のねらい＞①「国家安全保障戦略」改定を踏まえた経済産業省とDHSとの協⼒深化②「FOIP」実現に向けたインド太平洋地域での能⼒構築③制度調和の促進＜今回のMOCにおいて追加された協⼒分野＞
・インド太平洋地域等の能⼒向上
・⽇⽶間のサイバーセキュリティ関連規制・制度の調和に向けた対話（SBOMやIoT機器ラベリング制度等の調和を想定）

調和のための対話促進
https://www.meti.go.jp/press/2022/01/20230110002/20230110002.html

29

QUADにおける取組 2022年5⽉、QUAD⾸脳会合にて、「⽇⽶豪印サイバーセキュリティ・パートナーシップ」を⽴上げ。
「⽇⽶豪印サイバーセキュリティ・パートナーシップ」共同原則
 重要インフラのサイバーセキュリティ
 サプライチェーンリスクのマネジメント
 ソフトウェア・セキュリティ
 ⼈材育成発展の強化の分野で協⼒。

ソフトウェア・セキュリティについては、以下の協⼒を⾏う。
ベースライン・セキュリティ標準の国内・国際的な実施及び継続的な整合化
政府調達におけるソフトウェア・セキュリティに係る枠組みの整合的な開発

30

サイバー攻撃は規模や烈度が増⼤。DXの進展に伴い、攻撃拠点、攻撃の影響範囲が拡⼤。
IT/IoT製品等の製造事業者は、製品・サービスのセキュリティ対策に責任を持つことが必要に。

経済産業省のサイバーセキュリティ政策ウェブページはこちら⇒
https://www.meti.go.jp/policy/netsecurity/index.html

31