オープンソース成分はお好き？「ソフトウエア成分表-SBOM」について というエントリを書いたのは、2021年10月のことになります。その後、米国でも、日本でも、SBOMに関していろいろいな進展を見ることができるようになっています。あと、2021年5月の米国の大統領令を落としていましたので、まず、それから見ていきます。
1 「国家サイバーセキュリティ向上の大統領令」(2021年5月)
大統領令については、「国家サイバーセキュリティ向上の大統領令」(EO 14028、2021年5月)があります。この大統領令は、
- ポリシー
- 脅威情報を共有するバリアを除去
- 連邦政府サイバーセキュリティの現代化
- ソフトウエアサプライチェーンの強化
- サイバー・セーフティ・検討委員会の設立
- 連邦政府のサイバーセキュリティ脆弱性およびインシデント対応のプレイブック標準化
- 連邦政府ネットワークにおけるサイバーセキュリティ脆弱性・インシデントの探知の改善
- 連邦政府の捜査・復仇能力の改善
- 国家セキュリティシステム
- 定義
- 一版規定からなりたっています。
この大統領令では、まず、SBOMを
(j) 「ソフトウェア部品表（Software Bill of Materials）」または「SBOM」という用語は、ソフトウェアを構築する際に使用される様々なコンポーネントの詳細とサプライチェーン関係を含む正式な記録を意味する。 ソフトウェア開発者およびベンダーは、多くの場合、既存のオープンソースおよび商用ソフトウェアコンポーネントを組み立てることによって製品を作成する。 SBOMは、製品に含まれるこれらのコンポーネントを列挙する。 これは、食品のパッケージに記載されている原材料のリストに似ている。 SBOMは、ソフトウェアを開発または製造する人、ソフトウェアを選択または購入する人、ソフトウェアを運用する人にとって有用である。 開発者は、製品を作成するために、利用可能なオープンソースやサードパーティのソフトウェアコンポーネントを使用することが多い。SBOMによって、構築者は、それらのコンポーネントが最新であることを確認し、新しい脆弱性に迅速に対応することができる。 購入者は、SBOM を使用して脆弱性分析やライセンス分析を行うことができる。 ソフトウェアを運用する者は、SBOM を使用して、新たに発見された脆弱性の潜在的なリスクにさらされているかどうかを迅速かつ容易に判断することができる。 広く使用されている機械可読の SBOM 形式は、自動化とツールの統合によってより大きな利益をもたらす。 SBOM は、他のアプリケーションやシステムから容易に照会できるリポジトリにまとめて保存されることで、より大きな価値を得ることができる。 ソフトウェアのサプライチェーンを理解し、SBOM を取得し、それを使用して既知の脆弱性を分析することは、リスクを管理する上で極めて重要である。
と定義しています。そのうえで、
—
(a) 連邦政府によって使用されるソフトウェアのセキュリティは、連邦政府がその重要な機能を果たすために不可欠である。 商用ソフトウェアの開発には、透明性、攻撃に対するソフトウェアの能力に対する十分な焦点、悪意のある行為者による改ざんを防止するための適切な管理が欠けていることが多い。 製品が安全かつ意図したとおりに機能することを保証するため、より厳格で予測可能なメカニズムを導入することが急務である。 クリティカル・ソフトウェア」、つまり信頼に不可欠な機能（システム特権の昇格や、ネットワーキングおよびコンピューティング・リソースへの直接アクセスの許可または要求など）を実行するソフトウェアのセキュリティと完全性は、特に懸念される問題である。 したがって、連邦政府は、重要なソフトウェアへの対応を優先して、ソフトウェア・サプライ・チェーンのセキュリティと完全性を迅速に改善するための措置を講じなければならない。
(b) 本命令の日付から 30 日以内に、商務長官は、NIST 長官を通じて、連邦政府、民間企業、学界、その他適切な関係者から意見を募り、既存の基準、ツール、および本節 (e) 項の基準、手順、または基準に準拠するためのベスト・プラクティスを特定するか、新たに開発するものとする。 ガイドラインには、ソフトウェア・セキュリティの評価に使用できる基準を含め、開発者及び供給者自身のセキュリティ慣行を評価する基準を含め、安全な慣行への適合を実証する革新的なツール又は方法を特定するものとする。
(c) 本命令の日付から 180 日以内に、NIST 長官は、ソフトウェアのサプライチェーンセキュリティを強化し、本条項の要件を満たすための予備的なガイドラインを、本条第(b)項に記載された協議に基づき、可能な限り既存の文書を活用して公表するものとする。
(d) 本命令の日から360日以内に、NIST所長は、本条(c)項に記載のガイドラインの定期的な見直しと更新の手順を含む追加ガイドラインを公表するものとする。
(e) 本条(c)項に基づく予備的ガイドラインの公表から90日以内に、商務長官は、NIST長官を通じ、NIST長官が適切と考える省庁の長と協議の上、ソフトウェア・サプライチェーンのセキュリティを強化する慣行を特定するガイダンスを発行するものとする。 当該ガイダンスには、本条(c)項および(i)項に従って公表されたガイドラインを組み込むことができる。 当該ガイダンスには、以下に関する基準、手順、または基準を含めるものとする：
(i) 安全なソフトウェア開発環境：
(A) 管理上分離されたビルド環境を使用する；
(B) 信頼関係の監査
(C) 多要素、リスクベースの認証、および企業全体にわたる条件付きアクセスを確立する；
(D) ソフトウェアの開発、構築、編集に使用する環境の一部であるエンタープライズ製品への依存関係を文書化し、最小限に抑える；
(E) データを暗号化すること。
(F)運用と警告を監視し、サイバーインシデントの試みと実際に対応すること；
(ii) 本条第(e)項(i)号に定めるプロセスへの適合を証明する成果物を作成し、購入者が要求した場合には、これを提供すること；
(iii) 自動化されたツールまたは同等のプロセスを採用して、信頼できるソースコードのサプライチェーンを維持し、それによってコードの完全性を確保すること；
(iv) 既知および潜在的な脆弱性をチェックし、脆弱性を修正する自動化ツールまたは同等のプロセスを採用すること；
(v) 購入者から要求があった場合、本節(e)(iii)および(iv)に記載されたツールおよびプロセスの実行の成果物を提供し、評価および軽減されたリスクの概要説明を含む、これらの措置の完了に関する概要情報を一般に公開すること；
(vi) ソフトウェアコードまたはコンポーネントの正確かつ最新のデータ、出所（すなわち、起源）、およびソフトウェア開発プロセスに存在する内部および第三者のソフトウェアコンポーネント、ツール、およびサービスに関する管理を維持し、これらの管理の監査および実施を定期的に実施すること；
(vii) 各製品のソフトウェア部品表（SBOM）を購入者に直接提供するか、または公開 Web サイトで公開すること；
(viii) 報告および開示プロセスを含む脆弱性開示プログラムに参加すること；
(ix) 安全なソフトウェア開発慣行への適合を証明すること。
(x) 製品の一部で使用されているオープンソースソフトウェアの完全性と出所を、実行可能な範囲で保証し、証明すること。
(f) 本命令の日付から 60 日以内に、商務長官は、通信情報担当次官補および米国電気通信情報局長官と連携して、SBOM の最小要素を公表する。
(g) 商務長官は、本命令の日付から 45 日以内に、NIST 長官を通じて、NSA 長官を通じて行動する国防長官、CISA 長官を通じて行動する国土安全保障長官、OMB 長官、および国家情報長官と協議の上、本条 (e) 項に従って発行されるガイダンスに含める「重要なソフトウェア」という用語の定義を公表するものとする。 この定義は、機能するために必要な特権またはアクセスのレベル、他のソフトウェアとの統合および依存関係、ネットワーキングおよびコンピューティング・リソースへの直接アクセス、信頼にとって重要な機能の実行、および侵害された場合の損害の可能性を反映するものとする。
(h) 本条(g)項によって要求される定義の公表から 30 日以内に、CISA 長官を通 じて行動する国土安全保障長官は、NIST 長官を通 じて行動する商務長官と協議の上、本条(g)項に従って発行された重要ソフトウ ェアの定義に適合する、使用中または取得手続き中のソフトウ ェアおよびソフトウエア製品の分類のリストを特定し、各省庁に提供す るものとする。
(i) 本命令の日付から60日以内に、商務長官はNIST長官を通じ、CISA長官を通じた国土安全保障長官およびOMB長官と協議の上、最小特権、ネットワーク・セグメンテーション、および適切な構成の適用を含め、本条(g)項に定義される重要ソフトウェアのセキュリティ対策の概要を示す指針を公表するものとする。
(j) 本節第(i)項に記載されたガイダンスの発行から30日以内に、OMB内の電子政府室長を通じて行動するOMB長官は、各省庁が当該ガイダンスに従うことを要求するための適切な措置を講じるものとする。
(k) 本節(e)項に記載された指針の発行から30日以内に、OMB内の電子政府室長を通じて行動するOMB長官は、本命令の日付以降に調達されたソフトウェアに関して、各省庁が当該指針を遵守するよう求める適切な措置を講じるものとする。
(l) 省庁は、本節(k)項に従って発行された要件に準拠するための延長を要求することができる。 このような要求は、基本的な要件を満たすための計画を伴う場合に限り、ケースバイケースでOMB長官によって検討されるものとする。 OMB長官は、四半期ごとに、APNSAに対し、許可されたすべての延長を特定し説明する報告書を提出しなければならない。
(m) 省庁は、本項(k)に従って発行された要件について、免除を要求することができる。 免除は、OMB長官がAPNSAと協議の上、ケース・バイ・ケースで検討するものとし、例外的な状況かつ限られた期間のみ、また潜在的なリスクを軽減するための計画が付随している場合にのみ認められるものとする。
(n) 本命令の日付から1年以内に、国土安全保障長官は、国防長官、司法長官、OMB長官、およびOMB内の電子政府室長と協議の上、FAR審議会に対し、各省庁が購入可能なソフトウェアの供給者が、本条(g)項から(k)項に従って発行された要件を遵守し、かつ遵守していることを証明することを要求する契約文言を勧告するものとする。
(o) 本節(n)項に記載された勧告を受領した後、FAR審議会は勧告を検討し、適切かつ適用法に合致する場合、FARを改正するものとする。
(p) 本条第(o)項に記載されたFARを改正する最終規則の発行後、各省庁は、適切かつ適用法に合致するように、改正されたFARの要件を満たさないソフトウェア製品を、すべての無期限納入・無期限数量契約、連邦供給スケジュール、連邦政府全体取得契約、包括購入契約、および複数契約から削除するものとする。
(q) OMB 長官は、OMB 内の電子政府室長を通じて、本命令の日付より前に開発・調達されたソフトウ ェア（レガシーソフトウェア）を使用する政府機関に対し、本条第(k)項に従って発行された要件に準拠する か、またはこれらの要件を是正または満たすための措置の概要を示す計画を提出するよう求めるものとす る、 さらに、レガシーソフトウェアを含むソフトウェア契約の更新を希望する機関に対し、本項第(l)号または第(m)号に従って延長または免除が認められない限り、本項第(k)号に従って発行された要件に準拠するよう求めるものとする。
(r) 本命令の日付から 60 日以内に、商務長官は、NIST 長官を通じて、NSA 長官を通じて、国防長官と協議の上、推奨される手動または自動テスト（コードレビューツール、静的および動的解析、ソフトウェア構成ツール、侵入テストなど）の種類を特定することを含め、ベンダによるソフトウェアソースコードのテストに関する最低基準を推奨するガイドラインを公表するものとする。
(s) 商務長官は、NIST 長官を通じ、NIST 長官が適切と考える他の省庁の代表者と連携して、モノのインターネット（IoT）機器のセキュ リティ機能とソフトウェア開発の実践について一般消費者を教育するために、既存の消費者向け製品ラベリング・プログラ ムを参考にしたパイロット・プログラムを開始し、製造業者と開発者がこれらのプログラムに参加するインセンティブを与える方法を検討するものとする。
(t) 本命令の日付から 270 日以内に、商務長官は、連邦取引委員会（FTC）の委員長および NIST 長官が適切と考える他の機関の代表者と連携して、NIST 長官を通じて、消費者向けラベリング・プログラムのための IoT サイバーセキュリティ基準を特定し、そのような消費者向けラベリング・プログラムが、適用法に合致する既存の類似の政府プログラムと連携して運営されるか、またはそのようなプログラムをモデルとして運営されるかどうかを検討するものとする。 基準は、製品が受けた可能性のあるテストと評価の包括的なレベルを反映するものとし、製造業者が製品のセキュリティについて消費者に知らせるために使用している既存のラベリング方式を使用するか、またはそれと互換性のあるものとする。 NIST 長官は、すべての関連情報、表示、インセンティブ・プログラムを検討し、ベスト・プラクティスを採用するものとする。 この検討は、消費者にとっての使いやすさと、製造業者の参加を最大化するためにどのような措置を講じることができるかという判断に重点を置くものとする。
(u) 本命令の日付から 270 日以内に、商務長官は NIST 長官を通じ、FTC 議長および NIST 長官が適切と考える他の省庁の代表者と連携して、消費者向けソフトウェア表示プログラムのための安全なソフトウェア開発慣行または基準を特定し、そのような消費者向けソフトウェア表示プログラムが、既存の同様の政府プログラムと連携して運用されるか、またはそのようなプログラムをモデルとして運用されるかどうかを、適用される法律と整合性を保ちながら検討するものとする。 基準は、安全な慣行の基準レベルを反映するものとし、実行可能であれば、製品が受けた可能性のある、より包括的なレベルの試験および評価を反映するものとする。 NIST 長官は、すべての関連情報、ラベリング、インセンティブ・プログラムを調査し、ベスト・プラクティスを採用し、推奨ラベ ル、または可能であれば段階的なソフトウェア・セキュリティ評価システムを特定、修正、または開発するものとする。 この検討は、消費者にとっての使いやすさに重点を置き、参加者を最大化するためにどのような手段を講じることができるかを判断するものとする。
(v) これらのパイロット・プログラムは、OMB Circular A-119 および NIST Special Publication 2000-02（Conformity Assessment Considerations for Federal Agencies）に沿った方法で実施されるものとする。
(w) 本命令の日付から1年以内に、NIST長官はパイロット・プログラムのレビューを実施し、民間部門および関連機関と協議してプログラムの有効性を評価し、今後どのような改善が可能かを決定し、APNSAに概要報告書を提出するものとする。
(x) 商務長官は、本命令の日付から1年以内に、商務長官が適切と考える他の省庁の長と協議の上、APNSAを通じて、本条に基づく進捗状況をレビューし、ソフトウェア・サプライ・チェーンの安全確保に必要な追加措置の概要をまとめた報告書を大統領に提出する。
となっています。
ソフトウェア・サプライチェーンのセキュリティを強化する慣行を特定するガイダンスを発行するものとされ(e)、そのなかにSBOM が明確にされなければならないとされています。なお、一版のサプライチェーンについては、「サプライチェーン大統領令・2021年戦略的競争法案-第8回 産業構造審議会 通商・貿易分科会の資料から」で、サプライチェーン大統領令(2021年2月)を分析しています。
2 米国の動向
米国の参考文献については、後述のMETIのガイドラインの7.3 参照文献に詳しいです。
2.1 NTIAのドキュメント
2.1.1ドキュメント一覧
NTIAとは、 米国商務省電気通信情報局(National Telecommunications and Information Administration)の略称で 米国大統領に対して電気通信および情報政策に関する助言を行う行政機関です。
ガイドラインとしては、
- Roles and Benefits for SBOM Across the Supply Chain（2019年 11 月）-ソフトウェア開発者、購入者、利用者のそれぞれの視点で、SBOM を利用することのメリットをまとめた文書。メリットは、コスト、セキュリティ、ライセンス、コンプライアンス、サプライチェーンにおけるソフトウェアの安定性ごとに整理されている。
- 「SBOM概観」(SBOM の検討背景、ソフトウェアエコシステムにおける SBOM の役割や有効性、SBOM の概要をまとめた文書。)
- SBOM FAQ（2020 年 11 月）-SBOM の概要、利用効果、SBOM の生成や配布等に関してまとめた FAQ 集。
- Sharing and Exchanging SBOMs（2021 年 2 月）-SBOM データがサプライチェーン上でどのように共有されるかに関するオプションを説明した文書。
- SBOM Tool Classification Taxonomy（2021 年 3 月）SBOM ツールの分類を示した文書。ツールの利用目的を SBOM の作成・利用・変換の 3 つに分類し、それぞれの目的におけるツールのタイプが整理されている。
- Software Identification Challenges and Guidance（2021 年 3月）
ソフトウェアコンポーネントを国際的に一意に識別するための課題を説明した文書。課題を解決するための対処方法・ガイダンスを示すことを目的としている。 - SBOM at a Glance（2021 年 4 月）(日本語訳)-SBOM の活用方法、ソフトウェアサプライチェーンの透明性確保において SBOM が果たす役割、参考となる文書についてまとめた文書。SBOM に含めるべき情報も整理されている。なお、JPCERT/CC によって日本語訳された文書も公開されている。
- SBOM Options and Decision Points（2021 年 4 月）-SBOM に関して現在の手法で実現可能なことや、SBOM のサプライヤー及び利用者の間でのニーズの明確化を支援することを目的とした文書。
- The Minimum Elements For a Software Bill of Materials(SBOM)（2021 年 7 月）-SBOM の最小要素を定義した文書。最小要素は 3 つのカテゴリーに分けられ、各カテゴリーの概要や SBOM に含めるべき具体的な項目が定義されている。(以下、NISTのところで紹介)
- Vulnerability-Exploitability eXchange (VEX) – An Overview （2021 年 9 月）
特定のソフトウェアコンポーネントが脆弱性の影響を受けるかどうかを判断する指標である VEX について、その概要を説明した文書。VEX は、特定の製品に存在する脆弱性の状態を表すもので、文書では 4 段階で状態を表す方針が示されている。 - How-To Guide for SBOM Generation（2021 年 10 月） SBOM 生成の手引として SBOM 生成のための情報収集方法と、具体的な SBOM 生成方法の2 つの観点をまとめた文書。本手引は、NTIA によるヘルスケア分野の SBOM PoC を通じて策定されたが、ヘルスケア分野だけでなくあらゆる業界における SBOM 生成においての活用が期待されている。
- Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)（初版︓ 2019 年 11 月、改定︓2021 年 10 月）
SBOM の概念や関連用語、ソフトウェアコンポーネントの表現に関する基本的な考え方を示すとともに、SBOM の作成プロセスを示した文書。 - SBOM Myths vs. Facts（2021 年 11 月）-SBOM のメリットを正しく示すことを目的に、SBOM に関する代表的な誤解（神話） と、その誤解を解くための事実を整理した文書。
- Software Suppliers Playbook: SBOM Production and Provision（2021 年 11 月）-ソフトウェアサプライヤーを対象とした SBOM 生成に関するプレイブック。本プレイブックでは、「SBOM作成手順」、「SBOM 作成に当たって考慮すべき事項」及び「SBOM に関する補足事項」の 3 つの事項についてまとめられている。
- Software Consumers Playbook: SBOM Acquisition,Management, and Use（2021 年 11 月）
ソフトウェア利用者を対象とした SBOM 利用に関するプレイブック。本プレイブックでは、「サプライヤーから SBOM を取得する際の注意点」、「SBOM 活用のプロセス及びプラットフォーム」、「SBOMの知的財産及び機密保持」に関する注意点等がまとめられています。 - Survey of Existing SBOM Formats and Standards – Version 2021（初版︓ 2019 年、改定︓ 2021 年）既存の SBOM フォーマットや基準に関する調査結果や今後の課題に関して整理した文書。既存の SBOM フォーマットについては、SPDX、CycloneDX、SWID の 3 つについて、概要、ユースケース、特徴等がまとめられている。
2.1.2 SBOMの最小要素
下記のNISTの文書でも、引用されているので、「SBOM のための最小要素-国家サイバーセキュリティの向上のための大統領令14028にもとづく」(https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf)を読んでみます。
背景
この文書は、大統領令14028において、通信・情報担当次官補および米国電気通信情報局（NTIA）長官と連携して、商務長官に対し、命令から60日以内にソフトウェア部品表（SBOM）の最小要素を公表するよう指示したのに基づいて作成されたものです(Ⅱ 背景)。
構成は、サマリー、背景、範囲、最小要素、最小要素を越えて、今後のSBOMの取組、結論からなりたっています。
この文書では、
SBOMは、ソフトウェアを構築する際に使用される様々なコンポーネントの詳細とサプライチェーンの関係を含む正式な記録である。
としており、本レポートは、これらの最小要素を確立するだけでなく、最小要素についてどのように考えるべきかの範囲を定義し、ソフトウェアのサプライチェーンにおける透明性を高めるためのSBOMの使用事例を説明し、将来の進化のための選択肢を示すものとされます。
大統領令において
私たちがデジタル・インフラに寄せる信頼は、そのインフラがいかに信頼でき、透明であるかに比例すべきである
サプライチェーン内およびサプライチェーン間のコンポーネントと接続に透明性を持たせることは、サプライチェーン内の弱いつながりを発見し、それに対処するために
重要である。
とされています。
そして、SBOMモデルは、コンポーネントのメタデータを追跡し、他の情報源へのマッピングを可能にし、サプライチェーンを移動して展開されるソフトウェアにメタデータを結び付けることによって、この体系的な共有を実現するものです。このモデルをグローバルに拡張するためには、ソフトウェア・コンポーネントの特定の側面を普遍的に識別および定義し、下流のユーザーがデータを効果的かつ効率的に消費できるようにするという問題に対処する必要があるとされています。
範囲
検討されている事項は、
- 基本をどのように発展させることができるか、また、予測可能なSBOMフォーマットを持つことと、問題の技術や消費者のニーズに応じた柔軟性の必要性との間の緊張関係についての指針
- SBOMは、特定された脆弱性を基礎とする出発点であること
- SBOM の柔軟性と採用の可能性を最大化するために、リンク可能でモジュール化されたアプローチが推奨されること。
になります。その一方で、検討されていない事項・限定事項としては
- 規制要件や調達要件の問題を含め、連邦政府の要件は本報告書の範囲外であること
- 実践、脅威情報または研究のためにSBOMデータを集中化またはプールすることの潜在的な利点については触れていない。
- 「ソフトウェア」は、ハードウェアの問題は取り扱われていないこと
があげられています。
最小要素
これは、データフィールド、オートメーションサポート、実践とプロセスからなりたっています。これらを個々に記述すると以下のようになります。
| データフィールド | サプライヤー名 | コンポーネントを作成、定義、識別するエンティティ の名前。 |
| コンポーネント名 | オリジナルのサプライヤーによって定義されたソフト ウェアの単位に割り当てられた呼称。 | |
| コンポーネントのバージョ ン | プライヤーが、以前に特定されたバージョンからの ソフトウェアの変更を特定するために使用する識別子 。 | |
| その他の固有識別子 | コンポーネントを識別するため、または関連データベ ースの検索キーとして使用されるその他の識別子。 | |
| 依存関係 | 上流部品XがソフトウェアYに含まれるという関係を 特徴づけること。 | |
| SBOMデータ作成者 | このコンポーネントの SBOM データを作成するエンテ ィティの名前。 | |
| タイムスタンプ | SBOM データアセンブリの日時を記録する。 | |
| オートメーション・サポート | SBOM は、相互運用可能なフォーマットの 1 つで、組織の境界を越えて伝達されなければならない | ソフトウェアパッケージデータエクスチェンジ（SPDX） |
| サイクロンDX | ||
| ソフトウェア識別（SWID）タグ | ||
| 実践とプロセス | 頻度 | ソフトウェアコンポーネントが新しいビルドまたはリリースで更新された場合、ソフトウェアの新バージョンを反映するために新しい SBOM を作成しなければならない。 |
| 深さ | SBOMには、すべての一次（トップレベル）コンポーネントと、それらのすべ ての推移的依存関係を記載する。 |
|
| 未知であることが知られていること(Known Unknowns) | SBOM作成者は ” 未知であることが知られていること”を明示的に特定しなければならない。 | |
| 配布および配信 | SBOM は、それを必要とする人が適時に利用できるようにする必要があり、適切なアクセス権限と役割が設定されていなければならない。 | |
| アクセス制御 | アクセス制御が望まれる場合は、SBOMデータをユーザーのセキュリティツールに統合するための具体的な許容範囲や便宜を含め、条件を指定しなければならない。 | |
| ミスの許容 | 漏れや誤りを許容すべきである。 |
ここで、実践とプロセスというのは、SBOMを要求または提供するための方針、契約、または取り決めにおいて、多くの要素が明示的に対処されるべき、というものてす。
最小要素を越えて
ソフトウェアサプライチェーンの透明性を拡大し、ソフトウェアの安全性を確保するための可視性をサポートするためには、さらにやるべきことがあるとして、より広範な SBOM の使用事例をサポートするための、さらなる追加と包含について説明がなされています。
そのうちの最小要素に加えての推奨要素としては
| 推奨データフィールド | コンポーネントのハッシュ | 暗号化ハッシュは、このマッピングを支援する基礎的な要素を提供し、またリネームやホワイトリスト登録の際にも役立、また、特定のコンポーネントが使用されたという信頼性を提供する。 |
| ライフサイクル段階 | SBOMデータがいつ、どこで、どのように記録されたかを簡単に伝える手段があると便利である。 | |
| その他の構成要素の関係 | SBOMの最小要素は、従属関係という1つのタイプの関係によって接続されている。 | |
| ライセンス情報 | ライセンス管理は SBOM の初期のユースケースであり、大規模で複雑なソフトウェアポートフォリオを持つ組織が、特にオープンソースソフトウェアの多様なソフトウェアコンポーネントのライセンスと条件を追跡できるように支援する |
などがあげられています。
また、検討すべき事項としては、
- クラウドベースのソフトウェアとSaaS(とくに、 リスク管理の役割は異なる ソフトウェアは顧客のインフラストラクチャー上で実行されているわけでも、顧客の管理下で実行されているわけでもない/。脆弱性やリスク情報を理解し、それに基づいて行動する責任は、サービスプロバイダにありること)、
- SBOMの完全性と真正性(ソフトウェアの世界では、完全性と真正性は署名と公開鍵基盤によってサポートされることが多いこと)、
- 脆弱性とSBOM(主なセキュリティ使用事例は、ソフトウェアのサプライチェーンにおける既知の脆弱性とリスクを特定すること、SBOMの脆弱性データは、よほど特殊な条件やプロセスが整っていない限り、完全かつ最新のものであるとは想定できないこと)
- 依存性における脆弱性と悪用可能性
- レガシーソフトとバイナリ解析
- 実施における柔軟性と均一性
があげられています。
今後について
また、同報告書は、SBOMの今後についてSBOM がすべてのセキュリティ攻撃やサプライチェーン攻撃を解決するわけではないということを前提に、
- ソフトウェア・サプライ・チェーンを保護するためのより完全なアプローチの基礎は、ソフトウェア・ライフサイクル全体から、暗号学的な保証付きで詳細を安全に取得することである。
- データを効果的に使用するには自動化が必要であり、自動化には自動消費とポリシー施行の両方の可能性が必要であること。
- 個々のコンポーネントの血統と出所に関するデータ、コンポーネントのそれぞれの出所の追跡、およびソフトウエアのライフサイクル全体にわたるその保管の連鎖が含まれるデータは、SBOMアプローチに適合する。
- 最新のアプリケーション開発とクラウドネイティブアーキテクチャのユニークな性質は、ソフトウェアの透明性についてもさらに考慮する必要がある
について触れています。
2.2 NISTの対応
サプライチェーンにおけるソフトウエア・セキュリティ(SBOM)
上記大統領令に関して、NISTの準備しているホームページばこちら。
2.2.1 項目の位置づけ
NISTのソフトウエアサプライチェーンについての項目をまとめると
| ソフトウエアサプライチェーン-セキュリティガイダンス | |||
| サプライチェーンのソフトウエアセキュリティ | |||
| ガイダンス・目的・範囲・読者 | |||
| EO-重要ソフトウエアおよびEO重要ソフトウエアのためのセキュリティ手段 | |||
| 生産者および利用者のためのソフトウエアサイバーセキュリティ | セキュアソフトウエア開発実務への適合の認証 | ||
| ソフトウエア検証 | |||
| 進化する標準・ツール・推奨実務 | ソフトウエア成分表(SBOM) | ||
| 拡張されたベンダーリスク評価 | |||
| オープンソース・ソフトウエアコントロール | |||
| 脆弱性管理 | |||
| 追加の存在する産業標準・ツール・推奨実務 | |||
| FAQ | |||
| 開発者(Producers)および購入者のソフトウエアサイバーセキュリティ | |||
| 重要ソフトウエア | 重要ソフトウエア定義 | ||
| 重要ソフトウエアのセキュリティ手段 | |||
| ソフトウエア検証 | 序 | ||
| 背景およびアプローチ | |||
| ベンダーや開発者のコードの検証のための推奨される最低限度の標準 | |||
| FAQ | |||
| 消費者のためのサイバーセキュリティラベリング | |||
| 費者サイバーセキュリティラベリングパイロット版(アプローチと貢献) | |||
| ワークショップ | |||
| IOT製品基準 | |||
| 消費者ソフトウエア基準 | |||
| ニュース・アップデート・・・(略) | |||
| ワークショップ・ニュース・・・(略) | |||
で、そのなかの標準・ツール・推奨慣行のなかに、SBOMがまとめられています。NISTは、ソフトウエアライフサイクルのなかで、SBOM の実際をまとめています。
その図は、
となっています。この図は、ソフトウエアのライフサイクルのなかで、個々の段階で、留意すべき点をあげています。
このページで、引用しているのは、上記のNTIAのSBOMの必要最小限度の要素になります。
データフィールド： データフィールド：追跡すべき各コンポーネントに関する基本情報の文書化
自動化のサポート： 自動生成と機械可読性により、ソフトウェアエコシステム全体への拡張を可能にする。
実践とプロセス： SBOM要求、生成、および使用の運用の定義
となっています。
もっとも
SBOM およびそれが連邦買収者に提供することを意図している透明性の向上は、補完的な能力であり、代替的な能力ではない。
ということが強調されています。
そして、連邦機関は、可能かつ適用可能な場合には、以下の推奨される SBOM 能力を考慮すべきであるとして基礎的能力、能力の維持、能力の強化を考えるべきであるとしています。
図示すると、こんな感じです。
2.2.2 SBOM能力
基礎的能力
- SBOM が業界標準のフォーマットに準拠していることを確認し、バージョンの自動取り込みと監視を可能にする。米国電気通信情報局（National Telecommunications and Information Administration）によると、許容可能な標準形式には現在 SPDX、CycloneDX、および SWID が含まれる。
- 供給者のオープンソースソフトウェアコンポーネントの統合カタログを含む、NTIA の推奨最小要素(上述)を満たす SBOM を提供する。
- 購入ソフトウェア、オープンソースソフトウェア、社内ソフトウェアを含む、すべてのクラスのソフトウェアについて SBOM が利用可能であることを確実にする。
- 容易にアクセス可能でデジタル署名された SBOM リポジトリを維持し、SBOM をソフトウェア購入者と直接、または公開 Web サイトで公開することによって共有する。
能力の維持
- SBOM データを、取得主体のリスク態勢を知らせる追加データ要素とともにすることで、文脈を明らかにする。追加データ要素には、プラグイン、ハードウェアコンポーネント、組織管理、およびコミュニティが提供するその他のコンポーネントが含まれる。
- 脆弱性検出を SBOM リポジトリと統合して、サプライチェーン全体にわたって該当するサイバーセキュリティリスクに対する自動アラートを可能にする。
- 現行の SBOM が、サプライヤによる商用ソフトウェアコンポーネントの統合について詳述していることを確認する。
- SBOM コンポーネントレベルでベンダの脆弱性開示レポートを維持する。
能力の強化
- SBOM の脆弱性開示が買収組織に及ぼす影響を動的に監視するためのリスク管理および測定能力を開発する。さらなるリスク暴露および重要度の計算のために、資産目録と整合させる。
- 技術的および法的に実行可能な場合には、ベンダー提供の SBOM が利用できない場合（レガシーソフトウェアなど）に、ソフトウェアインストールパッケージのバイナリ分解を実行して SBOM を生成する。
3 わが国の議論
3.1 経済産業省
さらに、我が国でも幾つかの動きが出ています。
- METI ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver. 1.0 の公表
- 薬機法とSBOM導入
を見ていきましょう。
3.1.1 METI
これは、「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver. 1.0」「付録チェックリスト」というものです(2023年7月)。
手引きは、背景と目的、概要、基本指針・全体像、環境構築・体制整備フェーズにおけるる実施事項・認識しておくべきポイント、SBOM 作成・共有フェーズにおける実施事項・認識しておくべきポイント、 SBOM 運用・管理フェーズにおける実施事項・認識しておくべきポイント 、付録 チェックリスト・用語集等からできています。
3.1.1.1 環境構築・整備フェーズ
これはさらに適用範囲の明確化・ツールの選定、ツールの導入・設定、ツールに関する学習に分けて論じられます。
| 適用範囲の明確化 | 対象ソフトウェアの開発言語、コンポーネント形態、開発ツール等、対象ソフトウェアに関する情報を明確化する。 |
| 対象ソフトウェアの正確な構成図を作成し、SBOM適用の対象を可視化する。 | |
| 対象ソフトウェアの利用者及びサプライヤーとの契約形態・取引慣行を明確化する。 | |
| 対象ソフトウェアのSBOMに関する規制・要求事項を確認する。 | |
| SBOM導入に関する組織内の制約（体制の制約、コストの制約等）を明確化する。 | |
| 整理した情報に基づき、SBOM適用範囲（5W1H）を明確化する。 | |
| SBOMツールの選定 | 対象ソフトウェアの開発言語や組織内の制約を考慮したSBOMツールの選定の観点を整理する。（選定の観点の例：機能、性能、解析可能な情報、解析可能なデータ形式、コスト、対応フォーマット、コンポーネント解析方法、サポート体制、他ツールとの連携、提供形態、ユーザーインターフェース、運用方法、対応するソフトウェア開発言語、日本語対応等） |
| 整理した観点に基づき、複数のSBOMツールを評価し、選定する | |
| SBOMツールの導入・設定 | SBOMツールが導入可能な環境の要件を確認し、整備する。 |
| ツールの取扱説明書やREADMEファイルを確認して、SBOMツールの導入・設定を行う。 | |
| SBOMツールに関する学習 | ツールの取扱説明書やREADMEファイルを確認して、SBOMツールの使い方を習得する。 |
| ツールの使い方に関するノウハウや各機能の概要は記録し、組織内で共有する。 |
3.1.1.2 作成・共有フェーズにおける実施事項・認識しておくべきポイント
これは、さらに解析・作成・共有にわけて論じられています。
| コンポーネントの解析 | SBOMツールを用いて対象ソフトウェアのスキャンを行い、コンポーネントの情報を解析する。 |
| SBOMツールの解析ログ等を調査し、エラー発生や情報不足による解析の中断や省略がなく、解析が正しく実行されたかを確認する。 | |
| コンポーネントの解析結果について、コンポーネントの誤検出や検出漏れがないかを確認する | |
| SBOMの作成 | 作成するSBOMの項目、フォーマット、出力ファイル形式等のSBOMに関する要件を決定する。 |
| SBOMツールを用いて、当該要件を満足するSBOMを作成する。 | |
| SBOMの共有 | 対象ソフトウェアの利用者及び納入先に対するSBOMの共有方法を検討した上で、必要に応じて、SBOMを共有する。 |
| SBOMの共有に当たって、SBOMデータの改ざん防止のための電子署名技術等の活用を検討する。 |
3.1.1.3 SBOM 運用・管理フェーズにおける実施事項・認識しておくべきポイント
| SBOMに基づく脆弱性管理、ライセンス管理等の実施 | 脆弱性に関するSBOMツールの出力結果を踏まえ、深刻度の評価、影響度の評価、脆弱性の修正、残存リスクの確認、関係機関への情報提供等の脆弱性対応を行う。 |
| ライセンスに関するSBOMツールの出力結果を踏まえ、OSSのライセンス違反が発生していないかを確認する。 | |
| SBOM情報の管理 | 作成したSBOMは、社外からの問合せがあった場合等に参照できるよう、変更履歴も含めて一定期間保管する。 |
| SBOMに含まれる情報やSBOM自体を適切に管理する。 |
となっています。
3.1.2 薬機法とSBOM導入
3.1.2.1 改訂手引き書までの流れ
これは、ざくっとした表現になっていますが、具体的には、厚生労働省医薬・生活衛生局医療機器審査管理課・厚生労働省医薬・生活衛生局医薬安全対策課「医療機器のサイバーセキュリティ導入に関する手引書の改訂について」令和５年３月31日・薬生機審発 0331 第 14 号・薬 生 安 発 0 3 3 1 第 ７ 号でもって、
一般社団法人日本医療機器産業連合会の医療機器サイバーセキュリティ対応ワーキンググループにおいて、Software Bill of Materials(SBOM)の取扱いやレガシー医療機器の取扱い、脆弱性の修正、インシデ ントの対応等を検討し、改訂版の「医療機器のサイバーセキュリティ導入に関する手引書」として、別添のとおり取りまとめましたので情報提供します
となっています。でこの、「医療機器のサイバーセキュリティ導入に関する手引書（第２版）」が非常に情報量が豊富なドキュメントとなっています。
個人的には、IoTの法律問題を「IoTの脆弱性と安全基準との法的な関係」としてInfoComreviewに掲載してもらったところです。
まず、医療機器ですが、これは、医薬品、医療機器及び再生医療等製品の研究開発の促進のために必要な措置を講ずることを目的とするのが、医薬品医療機器等法(医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律（昭和三十五年八月十日法律第百四十五号）、以下、薬機法という)によって規制されています。薬機法は、医療機器を
ヒトまたは動物の疾病の診断、治療又は予防を目的とし、ヒトまたは動物の構造・機能に影響を及ぼすことが目的とされている機械器具（再生医療等製品を除く）で、政令で定めるもの
と定義しています（同法2条4項）。薬機法において、医療機器については、そのレベルごとにクラス分けがなされており、それぞれに許認可およびその審査の機関が、異なっています（クラス分けについて同法２条５－７項）。これらに対する規制の枠組は、複雑なので、省略します。
医療機器の安全性を確保するための基準は、「薬事法第 41 条第３項の規定により厚生労働大臣が定める医療機器の基準の一部を改正する件」（平成 26 年厚生労働省告示第 403 号）による改正後の「医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律第４１ 条第３項の規定により厚生労働大臣が定める医療機器の基準」（平成 17 年厚生労働省告示第 122号。以下「医療機器の新基本要件基準」という。）によって定められているところです。当該基準は、第1章 一般的要求事項(第1条―第6条)と第2章 設計及び製造要求事項(第7条―第16条)からできています。
一般的要求事項との関係でいえば、そのような脆弱性が存在することが、新基本要件基準の「医療機器の既知又は予測することができる全ての危険性及び不具合は、通常の使用条件の下で、合理的に実行可能な限り低減され、当該医療機器の意図された有効性と比較した場合に受容できるものでなければならない。」（同６条 医療機器の有効性）という基準に即さないとならない考えられます。
設計及び製造要求事項との関係では、「医療機器は、意図する性能を発揮するために必要な調整、較正及び保守が安全に実施できるよう設計及び製造されていなければならない。」（同９条６項）、「電子プログラムシステムを内蔵した医療機器は、ソフトウェアを含めて、その使用目的に照らし、これらのシステムの再現性、信頼性及び性能が確保されるよう設計されていなければならない。また、システムに一つでも故障が発生した場合、実行可能な限り、当該故障から派生する危険性を適切に除去又は軽減できるよう、適切な手段が講じられていなければならない。プログラムを用いた医療機器については、最新の技術に立脚した開発のライフサイクル、リスクマネジメント並びに当該医療機器を適切に動作させるための確認及び検証の方法を考慮にいれた上で、その品質及び性能についての検証が実施されていなければならないこと。」(プログラムを用いた医療機器に対する配慮(同基準１２条))といえるかが、問われるということになります。
これらがより具体的に記載されたのが、「医療機器におけるサイバーセキュリティの確保について」（平成 27 年４月 28 日付け薬食機参発 0428 第１号・薬食安発 0428 第１号・厚生労働省大臣官房参事官（医療機器・再生医療等製品審査管理担当）・医薬食品局安全対策課長連名通知）ということになります。そこでは、
２．具体的な対策について
サイバーリスクが懸念される医療機器のうち、少なくとも、無線又は有線により、他の医療機器、医療機器の構成品、インターネットその他のネットワーク、又は USB メモリ等の携帯型メディア（以下「他の機器・ネットワーク等」という。）との接続が可能な医療機器について、製造販売業者は下記を踏まえて必要な措置を行うこと。
① 他の機器・ネットワーク等と接続して使用する又は他からの不正なアクセス等が想定される医療機器については、当該医療機器で想定されるネットワーク使用環境等を踏まえてサイバーリスクを含む危険性を評価・除去し、防護するリスクマネジメントを行い、使用者に対する必要な情報提供や注意喚起を含めて適切な対策を行うこと。
具体的には、当該医療機器と接続できる範囲を限定する、使用するソフトウェア等は製造販売業者が信頼性を認めたものに限定するなどのような対策が考えられる。
② ①の必要なサイバーセキュリティの確保がなされていない医療機器については、使用者に対してその旨を明示し、他との接続を行わない又は接続できない設定とするよう必要な注意喚起を行うこと。
③ 「医療情報システムの安全管理に関するガイドライン」を踏まえ、医療機関における不正ソフトウェア対策やネットワーク上からの不正アクセス対策等のサイバーセキュリティの確保が適切に実施されるよう、医療機関に対し、必要な情報提供を行うとともに、必要な連携を図ること
とされています。さらにその後、「医療機器のサイバーセキュリティの確保に関するガイダンスについて」（平成 30 年 7 月 24 日付け薬生機審発 0724 第１号・薬生安発 0724 第１号・厚生労働省医
薬・生活衛生局医療機器審査管理課長・医薬安全対策課長連名通知）で、とりまとめられることになります。
これは、平成 29 年度日本医療研究開発機構医薬品等規制調和・評価研究事業「医療機器に関する単体プログラムの薬事規制のあり方に関する研究」の研究報告 に基づいているそうです。
この内容は、本ガイダンスは、「サイバーセキュリティ通知により示された製造販売業者が行うべきサイバーセキュリティへの取組について、医療機器への開発・設計（市販前）及び市販後の対応をより具体的にするための情報を提供すること」を目的として「検討が必要となる医療機器および仕様環境の特定」のもと、
- 「3 サイバーセキュリティ対応」
- 「4 市販後の安全性確保について」
- 「5使用者等への情報提供」
について検討しています。
令和2年には、「国際医療機器規制当局フォーラム（IMDRF)による医療機器サイバーセキュリティの原則及び実践に関するガイダンスの公表について（周知依頼)」（令和 2 年 5 月 13 日付け薬生機
審発 0513 第１号・薬生安発 0513 第１号・厚生労働省医薬・生活衛生局医療機器審査管理課長・医薬安全対策課長連名通知)」が発出されています。
この周知依頼は
国際的な規制調和の推進の観点や国境の枠組みを超えて医療機器のサイバーセキュリティに係る安全性を向上させる観点から、我が国においても、今後３年程度を目途に、医療機器製造販売業者に対してIMDRFガイダンスの導入に向けて検討を行っているところです。
そのため、医療機器のサイバーセキュリティの更なる確保に向けた医療機器製造販売業者等の体制確保を円滑に行えるよう、別添のとおり、国立医薬品食品衛生研究所医療機器部が作成したIMDRFガイダンスの邦訳版を参考として情報提供いたします
というものです。このガイダンスに述べられている医療機器へのサイバー攻撃に対する国際的な耐性基準等の技術要件を我が国へ導入して整備することを目的に、「医療機器のサイバーセキュリティ導入に関する手引書」が主に医療機器製造販売業者向けのとして取りまとめられました。これは医療機器のサイバーセキュリティに係る必要な開発目標及び技術的要件等を検討したものです。
この手引き書が、改訂されたのが、改訂版の「医療機器のサイバーセキュリティ導入に関する手引書」ということになり、これが周知されたのが、当初の通知ということになります。
この文脈からいうと、上記の薬機法の基本要件の解釈に際して参考になるものというのが、この「手引書」ということになるものと考えられます。
3.1.2.2 改訂手引書の内容
この手引き書は、背景、適用範囲、用語および参考定義、一般原則、市販前の考慮事項、市販後の考慮事項、業許可に関する考慮事項にわけて論じられています。あと付属書があり、そこでは、SBOMがふれられています。
ア)市販前の考慮事項
これは、さらに医療機器の市販前の設計・開発段階において、製造販売業者の実施すべき事項として
A. セキュリティ機能の製品への組込み(製造販売業者が自社製品の設計で考慮することが望ましい設計原則-医療機器セキュリティ開示書（Manufacturer Disclosure Statement for Medical Device Security：以下 MDS2 という）のセキュリティ機能に対応-など)
B. 最新の技術に基づくリスクマネジメント手法の適用(製品のライフサイクル全般への対策および説明-脆弱性の特定・リスクの推定および評価・コントロールの採用・コントロールの有効性の評価・監視・協調的な情報開示を通じた情報の提供・活動の文書化)
C. セキュリティ試験(セキュリティコントロールが効果的に実施されていることを証明するとともに、セキュリティの対応状況を評価することによって、既知の（すでに確認され、国際的に広く開示されている）脆弱性（少なくとも重大（「致命的（Critical）」又は「ハイリスク」）と判定された脆弱性）がコードに含まれていないことを証明する必要)
D. 医療機器をセキュアに運用するための医療機関及び使用者に対する情報提供の準備(製品のセキュリティポリシーの規定・計画および必要のプロセスおよび組織の確立・維持/顧客向け文書の準備/規制当局への申請文書)
E. 市販後活動のための計画の立案
があげられています。製造販売業者は、これらの市販前の要素を検討する際、医療機器の意図する使用環境に加え、合理的に予見可能な誤使用のシナリオを充分に評価するとされています。この顧客向け文書の準備においては、SBOMとの関係が触れられています。これは、あとで別途に見ます。
イ)市販後の考慮事項
これについては、
- 使用環境と意図(製造販売業者は、自らの責任範囲を明確にして、医療機関におけるサイバーセキュリティを確保するために、医療機器を医療機関へ導入する際の求めに応じて、医療機器製品のシステム構成図、SBOM 及び MDS2 等の顧客向け文書を提供する-ここでも、SBOMとの関係が触れられています。この点は別に取り上げます。)
- 情報共有(製造販売業者は、医療機器について、市販前に立案されたサイバーセキュリティマネジメント計画に基づき、市販後に国内外で確認されたサイバーセキュリティの脅威及び脆弱性に関する情報並びにその他の医療機器
の適正なセキュリティ対策のために必要な情報を、医薬品医療機器等法に基づき継続的に収集、分析するとともに、それを医療機関へ提供する -修正策がすぐに利用できない場合等、必要に応じて脅威の緩和策及び方法も含める) - 協調的な脆弱性の開示(脆弱性情報を開示するタイミングは注意を要する。脆弱性の影響が大きく一般的である場合は、自社の対策だけでなく、場合によっては分野を超えた連携が必要な場合がある。この場合、製造販売業者は、規制当局等と連携して、必要な調整を実施する協調的な脆弱性の開示（CVD：Coordinated Vulnerability Disclosure）のプロセスを確立し、例外なく実施する)
- 脆弱性の修正(製造販売業者は、製造業者、販売業者、貸与業者及び修理業者と協力し、医療機関と連携して、遅滞のない修正によって安全確保を行う。修正には、患者への通知を含む広範な対応が含まれる)
- インシデントへの対応(インシデントに対する緊急対応、予防的計画的な活動となるセキュリティ点検、規制当局等への不具合等の報告、JPCERT/CC、ISAO 等への情報共有を含むコミュニケーション)
があげられています。
なお、レガシー医療機器という項目も存在しています。ここでは、
製品寿命終了（EOL）及びサポート終了（EOS）について、設計開発の段階において TPLC に関するリスクマネジメント原則に基づき、予め計画し定める。製造販売業者は、EOL について、販売時及び変更があった場合、顧客に通知する。EOS 以降は、顧客に責任が完全に移転するため、顧客が十分に対応可能な期間を配慮する必要がある。このため、製造販売業者は、遅くともEOL までに顧客に通知し、その後変更があった場合も通知する。
とされています。これは、一版のソフトウエアについても検討されなければならない問題になります。利用しているものの対応責任のレベルと情報収集義務・行政報告義務について個々の検討をなすというアプローチは、非常に参考になります。
ウ)業許可に関する考慮事項
これは、製造販売業者が、販売業者又は貸与業者を介して医療機関（直接使用者の場合も含む）へ医療機器を提供する際には、安全性情報の提供、収集その他の安全確保に必要となる処置を実施することになる。その
ため、サイバーセキュリティ対応においても、他の安全確保処置と同様に販売業者等を含めたステークホルダーによる連携をとる。
医薬品医療機器等法にて
- 医療機器の製造販売をするときは、その医療機器に関する最新の論文その他により得られた知見に基づき、注意事項等情報（添付文書）について、PMDA ホームページにおける公表等の手段を用いて公表する。
- 製造販売業者は、医療機器を購入し、借り受け、譲り受けようとする者（電気通信回線を通じて医療機器プログラムの提供を受けようとする者も含む、以下「販売業者等」という）に対し、注意事項等情報（添付文書）の提供を行うために必要な体制を整備する。
- 製造販売業者は販売業者等とともに、医療機器の有効性及び安全性等の医療機器の適正な使用のために必要な情報を収集、検討するとともに、さらにこれらの情報について、販売業者等に対して提供するよう努める。
- 販売業者等は、医療機器の製造販売業者等が行う医療機器の適正使用に必要な情報の収集に協力するよう努める。
という規定は、サイバーセキュリティ対応においても求められる、とされています
3.1.2.3 改訂手引書の内容とSBOM
改訂手引き書においては、その付属書で、SBOMの概念的な説明がなされています。
A ソフトウエア部品表(SBOM)の扱い
ここでは、SBOMの全体的なフレームワーク、 SBOMの作成、SBOM の要素と推奨フォーマット、SBOMの提供、SBOMの事例(構成)からなりたっています。この附属文書は、SBOMの基本的な要素をわかりやすくまとめているものといえるでしょう。
SBOM提供の責任
結局、ソフトウェアを構築する際に使用される様々なコンポーネントの詳細とサプライチェーン関係を含む正式な記録であるSBOMは、医療機関、医療機器の使用者が、その資産を効果的に管理し、医療機器及び接続されるシステムに対して識別された脆弱性の潜在的影響を理解し、医療機器の安全性及び性能を維持するための対応を可能にするものです。そして、
医療機器製品に実装されている自製（開発委託したものも含む）、オープンソース及び市販のソフトウェア部品（製品コンポーネント）の透明性を確保するための SBOM
は、顧客向けの文書として、注意事項等情報及び取扱説明書に加えて、製造販売業者が提供する医療機器のインストール及び設定に係る技術文書、並びに運用環境のための技術的要求事項等のひとつとして顧客に提供されなければならないとされています(同改訂手引き書 5.5)。
製造販売業者は、使用するソフトウェアのサプライヤーとの使用許諾、契約等によって、当該ソフトウェア部品の最新の SBOM、EOL及び End of Support（以下「EOS」という）を把握し、当該医療機器の SBOM には、ソフトウェア及びそのバージョン、部品間の関連性等を特定可能にする情報を含め（附属書 A「ソフトウェア部品表（SBOM）の扱い」参照）、製品のアップグレード等の計画の根拠とすることになります。
3.1.2.4 改訂手引書の内容と脆弱性
改訂手引書は、SBOM に関しても非常に積極的な記載がなされていると評価することが可能ですが、さらに、ソフトウエアの脆弱性の取扱という観点からも非常に興味深い記述を沢山含んでいるようにおもいます。とくに、EOL製品についての考え方は、非常に興味深いようにおもいます。この点については、別の機会において、具体的な検討をなしたいと考えています。
