A：
ソフトウェアタスクフォースというものが数年前に立ち上がって、昨日の10月下旬で11回目になります。SBOMの実証自体は2021年頃、今から二年前三年前ぐらいから取り組んでいます。それ以前は、OSSのセキュリティ、経産省サイバーセキュリティ課から出しているOSSの管理事例集のところで取り組みは行ってきました。その中でSBOMについては米国の大統領令も出てきましたのでその辺りから動きが活発化し、経産省も実証を踏まえて取り組みを加速させてきています。

A：
米国、EUをはじめ、関連する各政府など必要に応じてSBOMに関して会話させていただくこともあります。ご存知のとおり国によってSBOMもどこまで求めるかというところについて考え方の違いとか、時期にもよって考え方がいろいろとアップデートされてくるところもあります。その辺りは定期的に確認はしています。例えば、米CISA主催のSBOM-a-Ramaといったコミュニティ活動などがあげられます。PoCなども米国は実施されていたり、EUの各国で温度が高い方もいます。もちろんそれ以外の方でも感度高くやってらっしゃる方はいると思います。

A：
制度全体として各省庁がバラバラなことを言うわけにもいかないので、基本的には足並み揃えて、「この辺りはどうするか」「どのぐらい揃えていくか」とか、必要に応じて必要な対話というのは当然しなければならないと思っています。基本的な考え方としては「この医療機器ガイドでは全然違うことを言っています」とならないように、足並みは揃えて活動していきたいと考えています。

A：
SBOM関連の取り組みにおいては、米国やEUサイバーレジリエンスアクトの動向などは必要に応じて動向調査しています。当然SBOMはサプライチェーンセキュリティに関するものなので、国内だけで閉じず海外との連携、国際整合みたいなところが必要になってきます。そういったところは意識しながら取り組んでいます。

A：
SBOMの導入手引きにも書かせていただいていますが、EUや、米国、日本の規制など、意識していただきたいですが、まずそもそもとして３つほど意識していただきたいポイントがあります。①SBOMを使った脆弱性管理をより効率的に実施すること、②SBOMによりライセンス違反のリスクを低減させること、③開発の生産性を上げていくこと、これらの効果をSBOMで十分得ることができると考えています。自社のガバナンス向上のためにも、是非積極的に前向きに捉えて取り組んでいただきたいと考えています。

A：
ケースバイケースかと思います。SBOMを自ら作って公開しているコミュニティや人もいるとは思います。ただ公開する義務が必ずしも今後も発生してくるかは非常に難しいところで、導入手引きの中の誤解と事実のところでも書かせていただいていますが、必ずしも公開するというわけではありません。まずはサプライチェーン上の必要な方に必要なだけSBOMというものが共有されて運用されているのが最低限重要なことです。それをインターネット上の第三者に毎回必ず公開するかというところは場合によると思うので、必ず全部がインターネット上の第三者に公開しないといけないということではないと思います。それは立場などユースケースによるというところです。

A：
数字を直接お答えするのは難しいのですが、経産省がこれまで実証してきた自動車、医療機器、ソフトウェアの分野、特に医療や自動車に関しては人の命に関わるので、ソフトウェアの透明性や脆弱性の管理はしっかり対応する必要があります。ですのでこの辺りの分野は特に、実証も含めて進んできています。いろいろなSBOMフォーマットがありますが、一部の企業では特定のフォーマットで実験的に進めているところもあるので、比較的前向きに進んでいると思います。

A：
SBOMというのはそれ単体だけ見ても構成情報・部品情報しか書いていないので、ある部品が脆弱かどうかというのはSBOMだけ見てもわかりません。SBOMの中に書いてある部品が脆弱かどうかは、脆弱性データベースに問い合わせて初めて判断できるようになります。ツールを使って自動的に調べることもできますし、ツールでカバーできない場合は手動でやるしかありません。コストや費用対効果を考える必要がありますが、なるべく脆弱性のマッチングやSBOM対応というのは自動で処理することを最初に考えるべきかと思います。それを前提に考えたうえで、どうしても残ってしまうところや課題として対応しないといけないところについて手動で対応していくなどコスト効果を判断しながら導入を進めていくものと考えています。

A：
ケースバイケースだと思います。素直なやり方で言えば、アプリを作っている人がそのままSBOMも作ってお客さま、納品先に納品するのが典型的な例として考えられます。ただ何らかの事情でそういうことができない場合、そういった時にはその受け手側、いわゆるその納品を受ける調達側で何らかの情報に基づいてSBOMを作るといった対応があると思います。そういうこともあり得るのでここはケースバイケースですが基本的にはどちらのケースもあり得ると思います。

A：
これも企業によると思います。SBOMや脆弱性管理の重要性から既存の契約の中で開示が必要とされている場合もあり得ます。アプリケーション開発元の企業ポリシーにもよりますが、必ずしも機密情報そのものに毎回抵触するというわけでもないので、契約とか企業の今まで持っている商習慣に合わせてできる範囲のところはどこなのか、対応できる範囲はどこなのかを、まずは前向きに検討する必要があると思います。どうしても一部は無理だということであれば、そこは改めて精査していただく必要があると思います。

A：
ソフトウェアであれば、基本的には対象にしていただくのがSBOMの大きな考え方になります。よくある誤解で、OSSだけ管理すればいいというお話がよくありますが、そうではありません。攻撃者の中には、OSSかそうではないかを意識して攻撃してくる人もいるかもしれませんが、そうではない人ももちろんいるわけで、SBOMというのはOSSも含めて本来なるべく広い範囲で対応していくというのが理想的な使い方と思います。何をどこまでそのSBOMの作成範囲にするのかというところにつきましては、当然議論もあるかと思います。その辺りの考え方を整理していくのが今後重要ではないかと考えています。この辺りは手引きの中でも対応範囲の話の中で触れていますので、その辺りの章を読んでいただければと思います。

A：
正確な機能の差異は、どの有償ツール、無償ツールを対象とするかに依存します。ただ、一般的な傾向としては、無償のツールを活用することで、ツール自体はコストをかけずに入手できるものの、有償ツールと比較して、導入・活用に関するマニュアルやサポートが限定的であることが多く、ツールの習得に多大なコストがかかる可能性があります。また、有償ツールと比較してサ ポート範囲や性能が限定的であることが多く、SBOM 導入の目的を達成できない可能性もあるため留意が必要です。SBOM の作成に当たっては、SBOM ツールを活用することで効率的に SBOM を作成することができますが、自社の SBOM 導入の目的を踏まえて使用するツールを選定する必要があるかと思います。

A：
SBOM導入の手引き公開は2023/7/28ですが、その後もソフトウェアの脆弱性に起因するセキュリティインシデントは発生している状況であり、SBOMはますます重要になっていると思います。また、SBOM導入手引きの改定についてですが、今後は必要に応じて適宜見直しを行っていきたいと考えております。

A：
総務省含む各省庁におけるSBOMの取り組みとうまく整合するよう、適宜情報連携など行いながら推進していく必要があると考えております。

A：
把握している限り、現在のところそのような補助金や支援制度はないかと思います。

A：
状況に依存するため、あくまで一例にはなりますが、まずは、SBOMは作成することが目的ではなく、SBOMを用いたソフトウェアの適切な管理が重要であるという視点があるかと思います。そのうえで、SBOM導入によって以下のようなメリットが存在することを理解することも重要です。
・脆弱性管理のメリット
ー脆弱性に関する情報を収集し、SBOM の情報と突合して脆弱性を検出することで、ソフトウェアにおいて脆弱性が残留するリスクを低減できる。
ーSBOM ツールなどを用いることにより新たな脆弱性をリアルタイムで検出し、影響を判断することで、初動期間を短縮できる。
ーSBOM ツールを用いた自動管理により、手動での管理と比較して、管理コストを低減できる。　など
・ライセンス管理のメリット
ーOSS の特定漏れによるライセンス違反のリスクを低減できる。
ーSBOM ツールを用いた自動管理により、手動での管理と比較して、管理コストを低減できる。　など
・開発生産性向上のメリット
ーコンポーネントに関する問題を早期に特定することで、開発遅延の発生を防ぐことができる。
ーコンポーネントに関する問題を早期に特定することで、対応コストを低減できる。
ー使用するコンポーネントを選定する際、類似製品に関する過去の SBOM を参照することで、選定に関する工数を削減できる。

A：
直接的なご回答が難しい部分もありますが、例えば、SBOM導入の手引きについては、J-Auto-ISAC様の以下のWebサイトにてご紹介頂いております。

https://j-auto-isac.or.jp/news/2023/10/18/565/

A：
SBOMとは、Software Bill of Materialsのことで、ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リストのことを言います。 ツールの機能については、一般論になりますが、SBOM ツールが有する機能として、コンポーネントの解析機能、脆弱性情報・ライセンス情報の自動マッチング機能、リスクの定量化機能、依存関係や脆弱性情報などの可視化機能、脆弱性情報・ライセンス情報の自動追跡機能、新たな脆弱性が検出された際のアラート機能、アドバイザリー情報の自動レポート機能、SBOM データのインポート機能などが挙げられます。SBOM ツールによって対応している機能が異なるため、SBOM 導入の目的や SBOM 適用範囲を踏まえ、どの機能が必要であるかを整理することが望まれます。

A：
どこまで対応するかは状況によるかと思います。部品特定の範囲は、例えば、委託開発先やサードパーティベンダーのソフトウェアから利用される部品を特定するかどうか、直接利用する部品のみを対象とするか、再帰的に利用する部品も対象とするかなどによって、脆弱性管理できる部品の範囲は異なります。

A：
SBOMに関するツールの提供形態についてのご質問と捉えご回答いたします。ツールによりますが、提供形態としては両方存在し得えるかと思います。

A：
SBOMの対象としたソフトウェアの内容が動的に変わるほか、脆弱性の情報も日々更新されることを踏まえ、SBOM に含まれる情報は定期的に更新し、管理する必要があるかと思います。自動で脆弱性情報が更新・通知される SBOM ツールを用いることで、新たな脆弱性に関する情報を即座に把握することができます。ツールを用いた自動管理ができない場合、担当者を別途設置するなど運用面でカバーすることとなりますが、ツールでの管理と比較して対応工数を要することに留意が必要です。

A：
現状では、JVN や米国 NVD のような脆弱性情報データベースにおける「影響を受けるソフトウェア」の粒度が体系化されていないため、コンポーネントの粒度を限定すると脆弱性の特定で漏れが生じる可能性がある。そのため、OSS のみならず、自社製品なども含めてコンポーネント情報を保持することが有効です。

A：
たとえば、SWID タグは、組織が管理対象とするデバイスにインストールされたソフトウェアを追跡することを目標 として開発されております。2012 年に ISO で定義され、2015 年に ISO/IEC 19770-2:2015 として更新されております。

A：
SBOM導入手引きの「7.3.2 SBOMに関するツール」では一例をご紹介しております。

A：
米国 NTIA の SBOM の「最小要素」には「自動化サポート」のカテゴリーが含まれ、SBOM の自動生成や可読性などの自動化をサポートすることが考慮されています。具体的なデータフォーマットとして、これまで国際的な議論がなされてきた SPDX（Software Package Data Exchange）、CycloneDX、Software Identification Tags（SWID タグ）の 3 つのフォーマットが位置づけられています。またこれら 3 つのフォーマットに加え、SPDX に基づき日本が開発したフォーマットである SPDX-Lite も存在します。SBOM のデータフォーマットは組織を越えて SBOM をやりとりするための一つの規格であり、データフォーマットの選定と SBOM に含めるべきデータフィールドの決定は、SBOM 利用者とサプライヤーとの間で合意の上、決定することが望まれます。

A：
内容にもよりますが、1件あたり数分程度の短いものもあれば、それ以上確認に時間がかかったものもあります。検出される脆弱性の件数が多い場合には、誤検知の可能性の確認などが必要になりますので、定常的な精査は難しいと思います。

A：
SBOM 適用項目のうち、SBOM のフォーマット・項目や SBOM の活用範囲を決定するために、対象ソフトウェアの SBOM に関する規制・要求事項を確認し、整理することが望まれます。規制・要求事項において、SBOM のフォーマット・項目や SBOM の活用範囲が規定される可能性もあるため、対象ソフトウェアに関する規制・要求事項について随時情報収集し、求められる場合には具体的な要求事項を整理することが望まれます。 SBOM 適用項目の検討に当たっては、当然ながら、SBOM 導入に向けた組織内の制約も加味する必要があります。最も想定される制約としては、組織内の体制に関する制約やコストに関する制約が挙げられます。これらの制約が厳しい場合、限定的なSBOM適用項目しか選択できない可能性もあるところ、SBOM 適用範囲の整理のために、あらかじめ組織内の制約を確認・整理することが望まれます。整理したこれらの情報を踏まえ、上述した SBOM 適用範囲の 5W1H の各観点について、適用項目を検討・明確化することが望まれます。SBOM 適用範囲は対応したいリスクの範囲やレベルによって変わることに注意が必要です。

A：
世の中には、SBOMフォーマット間でSBOM情報を変換するようなものも存在します。

A：
まずSBOM 導入に先立ち、SBOM を作成するソフトウェアの範囲を決定するとともに、SBOM を導入することで解決したい自組織の課題と、それを踏まえた SBOM 導入の目的を明確化することが必要です。例えば、膨大な数のコンポーネントが存在する大規模製品について、コンポーネントの依存関係も含めた SBOM を作成し、共有するという目的があった場合、有償の SBOM ツールを用いて SBOM を作成・管理することが想定されるかと思います。 SBOM 導入の目的に応じて、作成すべき SBOM の項目、フォーマット、作成範囲、共有範囲など、SBOM の適用範囲が大きく異なるため、SBOM を導入する組織は、まず、SBOM 導入により解決したいソフトウェア管理に関する自社の課題を整理するとともに、SBOM 導入の目的を明確化したうえで、SBOM を作成・運用・管理することが求められると考えております。

A：
SBOM導入の有無について、組織の規模については特に限定する必要はないかと思います。

A：
SBOM のフォーマットでは、情報なし（NOASSERTION）も許容されるが、SBOM 作成と共有の目的を鑑み、正確な情報を不足なく SBOM に記載することが望まれます。SBOMツールは、有償・無償含めて多数存在します。SBOMツールの選定については以下の事項の実施について、SBOM導入手引きでも触れられています。
□ 対象ソフトウェアの開発言語や組織内の制約を考慮した SBOM ツールの選定の観点を整理する。（選定の観点の例︓機能、性能、解析可能な情報、解析可能なデータ形式、コスト、対応フォーマット、コンポーネント解析方法、サポート体制、他ツールとの連携、提供形態、ユーザーインターフェース、運用方法、対応するソフトウェア開発言語、日本語対応など）
□ 整理した観点に基づき、複数の SBOM ツールを評価し、選定する。
【SBOM 導入に向け認識しておくべきポイント】
・複数の SBOM ツールの使い分けは非効率となる場合があるため、目的に対して最小限のSBOM ツールを用いた運用となるかどうかなども考慮することが望ましい。
・有償の SBOM ツールは一般に高価である。一方で、無償の SBOM ツールは、ツール自体のコストは無料であるものの、環境整備や学習に当たっての情報が不足しており、導入・運用に大きな工数を要する可能性がある。
・ 有償の SBOM ツールと比較して、無償の SBOM ツールの機能・性能は限定的である場合が多く、例えば、再帰的な利用部品が検出できない、読み込み可能な SBOM フォーマットに制限がある、ライセンスの検知漏れが発生する、導入環境が限定されるなどの課題がある。
・オンプレミス型の SBOM ツールでは、導入環境が制約される場合がある。また、SaaS 型のSBOM ツールでは、機密性の高いソースコードの情報が外部に送信される構造になっていないかを確認する必要がある。
・SBOM 導入が原因で開発効率が著しく下がることのないよう、既存の開発プロセスへの組込が容易な SBOM ツールを選定し、開発者に負担をかけない運用を心がけることが必要である。
・SBOM ツールの選定にあたり、無償トライアルなどを利用して実際の使用感を体験することが効果的である。観点の設定や選定に難しさを感じる場合には、複数の SBOM ツールを扱う販売代理店に相談し、各ツールの特徴や長所・短所を比較評価しながら選定することも一案である。

A：
あくまでも１つの考え方にはなりますが、SBOMで用いられる複数の部品ID標準（CPE, PURLなど）について、SBOM作成時の部品ID選択の考え方の整理しつつ、脆弱性DBのAPI・ツールを用いて脆弱性マッチングを行う方法などを特定することが必要ではないかと思います。

A：
例えば、米国 NTIA による SBOM の「最小要素」の定義によれば、SBOM単体では脆弱性の対応可否についてまでは含んでいないかと思います。

A：
以下のNTIAのSBOM Myths vs. Factsでも触れられていますが、SBOM が攻撃に利用される可能性はあるものの、SBOM により透明性を確保することによる「攻撃者からの防御」におけるメリットの方が大きいと捉えられています。攻撃者にとって、SBOM やソフトウェアの透明性に関する情報の効果は限定的であり、一般的に攻撃者は SBOM を必要とせず、例えば、WannaCry によるランサムウェア攻撃は、攻撃のための前提条件として SBOM は必要ではないと述べられています。
NTIA, SBOM Myths vs. Facts

https://www.ntia.gov/files/ntia/publications/sbom_myths_vs_facts_nov2021.pdf

A：
SBOM適用の範囲に関するご質問と捉え、ご回答いたします。
SBOM 導入組織は、SBOM 導入により解決したい自社の課題と SBOM 導入の目的を踏まえ、SBOM の適用範囲を明確化する必要があります。SBOM 適用範囲は以下 に示す 5W1H の観点に分類することができ、各観点において複数の適用項目（選択肢）が存在し得ます。
・SBOM の作成主体（Who）
・SBOM の作成タイミング（When）
・SBOM の活用主体（Who）
・SBOM の対象とするコンポーネントの範囲（What、Where）
・SBOM の作成手段（How）
・SBOM の活用範囲（Why）
・SBOM のフォーマット・項目（What）
SBOM 適用範囲は、これらの適用項目の組合せによって定まります。どの適用項目を選択するかにより、SBOM 導入に要するコストが異なることに留意が必要です。また、一つの観点に対し、複数の適用項目を選択する可能性もあります。適用項目の決定のために、SBOM の対象ソフトウェアに関する情報や、SBOM 導入に関する社内の制約を整理することが求められます。

A：
SBOM導入手引きのなかにも記載させておりますが、手動管理と比較した場合については、以下、一例としてご参考頂ければ幸いです。
【ソフトウェア管理におけるSBOM活用のメリット】
情報量が膨大となるソフトウェア管理に対し、機械処理可能な SBOM を導入することで、ソフトウェア管理に要する対応コストや人的コストを低減することができ、これにより開発生産性向上に繋がる。事実、経済産業省が実施した医療機器分野を対象とした実証では、SBOM を活用した脆弱性管理を行うことで、手動での管理と比較して、管理工数が 70%程度低減した。

A：
米国内において実態としてどこまでの範囲を求めているのかはお答えが難しいところがありますが、例えば、先日公表されていたFAR改正のパブコメ段階のもの以下のように触れられています。あくまでも１つの参考情報としてご確認ください。

https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_bunyaodan/software/index.html

===一部抜粋===
（3） Software bill of materials （SBOM）.
（i） The Contractor shall maintain, and upon the initial use of such software in the performance of this contract, provide or provide access to the Contracting Officer a current SBOM for each piece of computer software used in performance of the contract. Each SBOM shall be produced in a machine-readable, industry-standard format and shall comply with all of the minimum elements identified in Section IV of The Minimum Elements for a Software Bill of Materials （the current version at the time of solicitation） published by the Department of Commerce at https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom, except for frequency which is addressed in paragraph （c）（3）（ii） of this clause. These minimum elements establish the baseline technology and practices for the provisioning of a SBOM that enable computer software transparency, capturing both the technology and functional operation.
（ii） If a piece of computer software used in the performance of the contract is updated with a new build or major release, the contractor must update the computer SBOM in paragraph （c）（3）（i） of this clause to reflect the new version of the computer software and provide （or provide access to） the updated SBOM to the Contracting Officer. This includes computer software builds to integrate an updated component or dependency.
（iii） If an SBOM has been provided to the contracting officer at the basic contract level, the SBOM does not need to be provided to the contracting officer for each order.

A：
状況によるかと思います。たとえば、仮に何らかの契約のもとにSBOMの公開をされているという状況があるのであれば、その内容にも依存するかと思います。