A：
当時SPDXがちょうど国際標準化されまして、我々としてSPDXが標準になっていくという仮説を立ててSPDX選びました。

A：
タイミングについては、そのソフトウェアのバージョンアップがなされた場合や、今だと少ないと思いますが、バージョンアップがなされたタイミングでサプライヤーの方からSBOMが提供されるというケースもあると思いますので、そのタイミングでSBOM自体もバージョンアップするのが必要と考えています。

A：
脆弱性管理もツールでやった方が効率的というのが実証の一つの結果でしたので、方法論的に言うと、ツールを活用し、その後に脆弱性管理も適切に実施することが効率的と考えています。

A：
ツールによっては、そのツールが作ったものではない別のところで作ったSBOMをインポートして管理をすることができる機能が最近登場しています。例えば、ツール上で、そのインポートしたSBOMの情報がわかる形で表示がされるようになっているので、スキャンして作った情報と外から持ってきた情報は画面上では分けて表示することが可能です。大体どのSBOMツールでも、インポートの機能があるものに関しては、同様の表示をすることができます。

A：
実証の中では安定していたと思う一方で、いわゆるランタイムライブラリのような実行環境に依存するライブラリが検出できなかったりということもありました。そういった意味では、必ずしもずっと安定するというのは言い切れないと思います。ツールの中で調整ができるようにはなっていますので、同じ環境で同じツールで同じことをやったときに、安定して同じ結果はおそらく出ると思います。またそれをチューニングした結果もそれ以降解析には反映することができるものがあります。

A：
ツールによると思いますが、NTIAが指定している最小要素のデータフィールドを出力できない場合には、そのツールを使っていても最小要素を満たさない形になるので、別のツールを使っていただく形が良いと思います。我々も実際に悩んだ部分であり、設定によって実は出力できるということも多々あると思うので、そういったところは調べるなりドキュメント見るのが必要と思います。それでもわからないという場合は代理店などSBOMに関するコンサルティングを行っている会社などに聞いていただくというのが良いと考えます。

A：
SBOM自体のハッシュ値ということだと思いますが、それを共有して改ざん防止するというのも一案と思っています。ブロックチェーンの話が出ているのは、サプライチェーン構造がかなり複雑で、それ全体でSBOMを共有しようとしたときにメリットがあるというところからです。ある種、壮大なビジョンとして分散型台帳を用いた共有というのが語られています。なのでダメというわけではないです。

A：
OSSのEOLは難しいです。正直なところ、EOLの表示の仕方がきちんとフォーマットが決定していなくて、それぞれのコミュニティで全然違う形で情報を出してきたり、EOLになっていてもいきなりそれが撤回されたり、またパッチを当ててくれたりするので、実は膨大にあるOSSの情報を機械的に収集してEOLの情報を抽出してそれをユーザーにお知らせするというのはかなり情報の揺れがあり難しいです。私たちの知る限りでEOLの情報を自動で完璧に判別できて、その情報をお伝えできるツールというのは市場には存在していない認識です。 ではどうするかというと、自分が使っているOSSについて、それを調べてくれるようなサービスとか、自動で情報収集するようなアプローチというのがとれるかと思います。

A：
さまざまなアプローチがあると思っていて、一つは出力結果、ログの出力結果を見ていただいて、なぜノーアサーションになっているのかというところを確認いただくのが一番いいと思います。もし、それが誤りだという場合には、ツールの設定を改めて見ていただいて、きちんとした設定や環境で情報が生成されているのかというところを確認いただく必要があると考えます。 これはツールに依存する部分なので、このノーアサーションというのがどういった背景で出ているのかというのは、ツールによります。解析方法も大きく関わってくるので、解析方法を確認したうえでもう一度レビューいただくというのも一つの手と考えます。

A：
現状だと明確な指針がないと思っていますし、そのSBOMの深さの問題はかなり国際的にも議論になっているところです。一方でEUの方でサイバーレジリエンス法の素案が発表されていて、その中ではトップディペンデンス、要するに最上位のコンポーネントについて洗い出すというところが規定されていて、それがいずれ法律になる可能性が高いというところです。

A：
VEXの運用を開始している組織もおり、例えば、SiemensやRed Hatといったベンダーは、VEX情報を公開しています。CISAが定めるVEXの最小要素では、CVEなどの脆弱性の識別子をVEXステートメントに含めることを必須要素として求めているため、最小要素を満足したVEXであれば、SCAツールを使わずともCVE情報との突合が可能となります。

A：
正確に記述することが望ましいですが、提供されるSBOMの内容や精度によっては、必ずしも正確に記述することが難しいケースがあるかと考えています。また、必ずしも1つのファイルに集約する必要は無いと考えていますが、集約したほうが管理は容易になるかと考えています。

A：
同様の課題が実証でも明らかになっており、手引に記載のとおり、SBOMツールでコンポーネントの EOLを特定できない場合、別途個別に（手作業で）調査する必要があると考えています。

A：
多くの有償SCAツールは、商用モジュールや商用コンポーネント、プロプライエタリのソフトウェアを検出可能です。

A：
SBOM情報として識別子の情報が含まれており、その識別子がCPEで記述されている場合は、SBOM情報にCPEが含まれます。ただし、CPEは、脆弱性の識別子であるCVEが付与された製品のみに付与されるため、すべてのコンポーネントに適用されない場合があります。そのため、PURLといったそのほかの識別子を用いてSBOMを作成しているケースもあります。

A：
実証では、誤検出や検出漏れの確認に30分程度を要したコンポーネントも存在しました。SBOMの深度や確認の深度にも依存しますが、複数のコンポーネントを有するソフトウェアの場合、一定程度の工数が必要になると考えています。

A：
必ずしも1つのファイルに集約する必要は無いと考えていますが、集約したほうが管理は容易になるかと考えています。また、SBOMファイルをインポートできるツールはいくつか存在しますが、ツールによってはインポート機能が無い場合もあります。また、ツールによってインポートできるSBOM形式やフォーマットに制約がある場合もあります。

A：
多くの有償SBOMツールでは、SBOM情報の管理機能も含まれています。

A：
一般的な話になりますが、やはり有償ツールの方が解析性能が高いです。複数の解析方法を組み合わせて解析する有償ツールも存在するため、有償ツールの方が詳細な情報が取得できる場合が多いです。

A：
ご認識のイメージのとおりですが、パッケージ自体の更新に限らず、パッケージの脆弱性情報が新たに見つかることで更新されるケースも存在します。

A：
多くのSBOMツールで、最小要素を満たしたSBOMの出力が可能です。

A：
依存関係の情報を含めてSBOM情報を出力できるツールが多いですが、すべての階層構造を正確に抽出できるか、という点については、ツールの性能に依存します。

A：
有償のSBOMツールは多数のソフトウェアを扱う大規模企業に多く導入されている印象です。具体的な定量値はわかりませんが、利用するソフトウェア数が多いほうがツール導入の費用対効果が高いと考えています。一方で、中小規模の事業者が導入していないかと問われると、決してそうではなく、扱うソフトウェア数が限定的であっても、そのソフトウェアがクリティカルなシステムに用いられ、適切な脆弱性管理を要する場合、ツールを導入しているケースもあります。