A：
NTIAが出しているSBOMの最小要素にあった「Know UnKnown」という用語で「わからないことをわかっているのであればそれをきちんと明記する」と言う意味になります。脆弱性があるかもしれないというときに、あるかもしれないということをきちんとSBOMに記載しておくところが、最小要素として含まれています。対象は脆弱性だけではなくて、例えば依存関係がわからないところがもしわかっていれば、それは「既知の未知」として管理することがNTIAの文書でも推奨されているような形になっています。

A：
一意のIDが付与されてはいますが、それが全世界で共通化というのが悩ましいところで、かつ今年実証として取り組んでいる部分です。多くのSBOMツールはPURL（Package URL）で脆弱性のIDが付与されます。一方で米国のNVD（National Vulnerability Database）ですと、ほとんどCPEというIDが付与されており、そこの間のマッチングが取りづらい状況になっています。ID自体は共通の一意性を持っていますが、全世界でそれが広く使われているのかという状態にはまだ達していない状況というふうに考えています。

A：
イメージはPURLに近いと思います。ただ、NTIAの最小要素ではそれにしなければならないとは書いていないので、誰が決めるかっていうとSBOMの作成者が決める形になります。最終的な脆弱性管理を考えるとそういったパッケージURL、CPEというようないわゆる脆弱性の部品IDを付与するのが良いと考えています。

A：
人の目で見るというところしか現状はないと思っています。実証の中で明らかになったレビューのポイント・観点は、何点か手引の中にも書いています。どことどう比べることでそのレビューをおこなうか、というところも手引に書いています。

A：
構成管理ツールと連携している場合にはコンポーネント特定できSBOMも効率的に作れると考えています。一方で、例えば自動車業界だとソースコードの授受はなくバイナリファイルだけ送ってもらってSBOMを作るというケースもありますので、バイナリファイルに関する解析をおこなう必要性が出てくると考えています。言い換えると完全にその構成管理ツールだけでSBOMを作れる状況というのは、結構稀有な状況と考えられます。

A：
個人的な意見を申し上げると統一化すべきと思いますが、統一化の動きは少ないと考えています。SBOMの発案者である米国のアランフリードマン博士という方からも、CycloneDXやSPDXがそれぞれのコミュニティで発達しているので競争や統一は民間に任せているというような意見もありました。なかなか政府として統一化に動き出すというのは難しいと考えています。

A：
例えばハードのBOMですと作って出荷したときの状態が表現され、更新されないものですが、SBOMはソフトウェアですのでアップデートしていくのが主流です。そうするとSBOMの内容も変わっていく必要があるので、ほかのBOMとは違いがあると思います。 SBOMだとソフトウェアが動的に変わるので、継続的にそのSBOMもアップデートしないといけないというところが一番大きいと考えています。手引の中でも、SBOMは作って終わりではなくて、それを作っていかに脆弱性管理をし、またSBOM自体をいかに管理していくかというところにもフォーカスを当てています。そのため、どう取り組んでいくべきかについては、脆弱性管理やライセンス管理という目的に対して、どうSBOMを作っていくかというところを意識する必要があると考えています。 実証で気づいた部分としては、方法論の面でいうとSBOMツールを使って管理していくことが非常に効率的です。手動で管理するのは非常に大変なので、ツールを使って管理をしていくことが一番最短の管理策になると現時点では考えています。

A：
その企業の規模や対象のソフトウェアによって一概には言えないところではありますが、個人的にはその専任者を設けるまでは行き過ぎというか、コストがかかってしまうと考えています。脆弱性管理やライセンス管理を目的とした、一つのツールがSBOMと考えているので、あくまでその方法だという観点で言うと、可能な限りコストは低い方がいいと考えます。いかにツールを効率的に使っていくかを意識し、文書など既存のリソースを活用しつつ、PSIRTの中で管理していくなど、もう少し効率的なやり方があるのではないかと考えています。

A：
手引書の中でまだ触れられていないところです。ご指摘いただいた契約や著作権に関する重要性が高まっているので、契約におけるSBOMの取り扱いが契約形態によって変わってきたり、OSSであってもどう使うのかは変わってくるので、整理の必要性を経産省担当も議論しているというところです。

A：
SBOMでは、あるソフトウェアが別のソフトウェアコンポーネントを内包しているなど、ソフトウェアコンポーネントの依存関係を示すことを目的としており、外部システムを介した間接的な依存関係や機能的な依存関係は要求されません。

A：
SBOMの「最小要素」としては、ハードウェアリソースに関する要素は含まれていません。一方で、組織内でSBOMを活用するうえでは、利用するハードウェアリソースに関する管理を行うことが望ましいです。

A：
ご認識のとおり、ソフトウェアのセキュリティ管理においては、オープンソースコミュニティへの働きかけが必要となります。米国では、政府機関のCISAがOSSのセキュリティに関するロードマップを発表し、OSSのセキュリティ支援におけるCISAの役割を明確化するほか、OSSコミュニティとの連携・働きかけについても示されています。

A：
実証においても同様の課題に直面し、有償ツールであっても、誤検知・検出漏れに対する人手での情報補完が必要となります。どのようなツールを用いる場合でも、完璧に精査することは難しく、誤検知や検出漏れが無いことを保証することは困難かと考えております。そのため、正確性の度合いと対応工数とのトレードオフを踏まえた精査が必要になると考えています。

A：
外部から調達するソフトウェアのSBOMについて、契約次第で、入手可能となるケースが今後想定されます。

A：
多くの有償SBOMツールは、いずれのフォーマットにも対応しています。一方で、無償のSBOMツールでは、SPDXのみ・CycloneDXのみのように、特定のフォーマットのみに対応したツールも存在します。

A：
経済産業省の手引において、SBOM導入に向けたチェックリスト（Excelファイル）を付けておりますので、ご確認ください。

https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html

A：
SBOMファイルをインポートできるツールはいくつか存在しますが、ツールによってはインポート機能が無い場合もあります。また、ツールによってインポートできるSBOM形式やフォーマットに制約がある場合もあります。

A：
Linux Foundationが実施した調査では、SBOM導入のメリットとして、「コンプライアンスおよび報告要件をよりよくサポートするコンポーネントに関する情報の提供」、「より多くの情報に基づいたリスクに基づく意思決定を可能にする情報の提供」、「脆弱性のタイムリーな認識」などのさまざまなメリットが挙げられており、SBOM導入によってソフトウェアの透明性が向上することが大きな利用効果であると言えます。

https://www.linuxfoundation.jp/wp-content/uploads/2022/05/LFResearch_SBOM_Report-ja.pdf

A：
ライセンス管理においてSBOMを導入する企業も存在します。また、開発生産性向上の観点で、効率的にコンポーネントに関する問題を特定するためにSBOMを導入する企業も存在します。

A：
ツールの習熟や環境整備で追加工数を要するものの、それ以外の点については、SBOMツールを利活用することで、手動での管理と比較して工数が低減するため、SBOM導入に係るプロセス全体において、SBOMツールを利活用することで効率化に繋がることが実証にて確認できました。

A：
経済産業省の手引では、サンプルソフトウェアに対して、SPDX、CycloneDX、SWIDタグ、SPDX-LiteのフォーマットでのSBOM例を示しています。ほかにも、例えばOWASPはCycloneDXに基づくSBOMの例をGitHub上で公開しています。

https://github.com/CycloneDX/bom-examples