先日開催された「OSSマネジメントフォーラム2022」にて、Linux系VTuberの熊ケ谷リナ様にSBOM関連の内容についてご講演いただきました。また講演を終えた後には聴講者の皆様からの質問にもお答えいただきました。本ブログではその際にいただいた質問と、それに対する回答のサマリーを掲載します。核心に触れる質問を数多く頂戴しましたので、参考にしていただければ幸いです。
質問と回答
Q：SPDXやCycloneDXにはEOLを設定する項目はないと思いますが、どのようにEOLの管理をすればよいでしょうか。SBOMを作成してOSSなどのソフトウェアを洗い出したら、SBOMとは別にソフトウェアごとのEOLを確認・管理するようなイメージでしょうか。
A：
CycloneDXですと、ComponentにPropertyという追加情報を書くセクションがあるので、そこでカバーするんじゃないかと思っています。今はユーザー側が独自に設定せざるを得ないと思いますが、EOL管理という使い方でSBOMを使うことについて業界内でニーズが高まれば、CycloneDXの仕様を検討しているコミュニティチームがそれを拾い上げて正式なセクション（パラメータ）として採用してくれるとか、そういった流れはあるかもしれません。
難しいのは、EOLは提供側によってサポートレベルが異なることです。RHEL9だとフルサポートとメンテナンスサポートの期間が微妙に違ったりするので、そういったところをどう表現できるかが問題にはなりそうです。
Q：各自が独自に命名やバージョン表記をしてしまうと、内容のゆれが生じSBOM利用時に困ってしまうことはないのでしょうか。ツールなどで同じものとして分類されないなど。
A：
解決方法の一つとしてPURL（Package URL）があると思っています。これはSPDXもCycloneDXも記載することができるものです。rpmやpipなど、開発対象によってさまざまなパッケージマネージャがありますが、それぞれバージョン表記などの表記ルールはまちまちです。それを統一するのがPURLで、これを使ってパッケージの一意性を出していこうとする取り組みは行われています。独自開発の商用ツールなどがPURLの規則に対応できるかという話もありますので、このような表記ゆれや名寄せは課題になってくると思います。今後いろいろな観点での標準化が進めば良いと思っています。
Q：セキュリティ上の懸念ついては、SBOM同士の統合だけでなく、SBOMとNVDなどの脆弱性情報の統合も必要だと思っています。しかしこれが難しく、CPEの製品名とSBOMのコンポーネント名が完全一致することは稀です。ここに対して何か世の中に改善の取り組みはあるでしょうか？
A：
ご指摘のように、NVDに登録されている製品名（およびそれに紐づくCVE）の名寄せ問題は重大な問題点であると各団体で認識されており、取り組みが進んでいるかと思います。たとえば、今年（2022年）の9月に公開された文章で、OWASP、The Linux Foundation、Oracleなどの合同チーム「The SBOM Forum」からNVDに対する改善案が出ているようです。セミナー内でも少し触れたPURL（HW製品の場合はGTINやGMN）にNVDで活用できるよう提言するもので、SW、HW各領域でスタンダードとなっている（あるいは期待されている）識別子を使うことで、意図した脆弱性情報が引用できないことを解消しようとしているようです。
Q：Linux系のSBOMは、それ以外とは異なるのでしょうか？
A：
基本的には変わらないです。ただ当然書かれている内容は変わってきますので、（表記揺れなどに関しては）PURLやCPEでギャップは埋めていけたらいいと思います。一方で、業界ごとにSPDXなのかCycloneDXなのかという違いはあると思っています。私が主に扱っているエンタープライズ（サーバーなど）の領域に関していえば、CycloneDXの方がサービスを表現しやすいように思います。セッションでも話しましたが、コンポーネントのネストを視覚的に理解しやすい構造で表記できるので、ある程度の規模のITシステムはCycloneDXの方が書きやすいのかなという印象は受けています。
Q：頒布を前提とした際に、SBOMの保持期限や、保持しなくてはいけない期限、というのはありますでしょうか？
A：
具体的な保存期間は今後の各国契約事例や法整備によって決まってくるのかなと思います。参考としてSPDXを推奨するOpenChain 2.1（ISO/IEC 5230:2020）の中の要求事項として「供給ソフトウェアの最終提供以降、適切な期間、あるいは確認ライセンスの要求事項により定められた期間（どちらか長い方）」という記述があります。
Q：SBOMのフォーマットは業界ごとに異なるものになるのでしょうか？Linux系はCycloneDX、家電系はSPDXなど
A：
業界ごとに異なる、というよりいまだ主流が存在しないというのがあるかと思います。たとえば、HW製品などの製造業では元々OSSライセンスに関する課題があり、その流れでSPDX（これは元々OSSのライセンス問題を解消するために議論されていた）が比較的浸透しているかなと思いますが、今後ITシステム的な領域での脆弱性管理用途でSBOMが広がる場合、OWASP主導で脆弱性、セキュリティ的なサプライチェーンの問題を解消しようと立ち上がったCycloneDXがソフトウェア製品領域で主流になる可能性もあると思います。
Q：SPDX Liteを検討しています。CycloneDXを使用されていてよかったと感じた点はありますでしょうか？
A：
CycloneDXはレイヤーが深くてコンポ―ネントがネストしているようなシステムを表現しやすいので、そこは良い点かと思います。依存関係を表現することにおいては、SPDXもCycloneDXも各コンポーネントを紐づけしないといけませんので、この手間は両者でそんなに変わらないなという印象を受けています。最終的には作る側・管理する側が、どのフォーマットが読みやすいか（扱いやすいか）というのが比較ポイントになるのではないでしょうか。
Q：オススメのSBOM生成ツール、脆弱性検出ツールがありましたら教えていただけると幸いです。現時点では情報が少なくて情報収集に苦労しております。
A：
マルチプラットフォームで利用する場合、Microsoft社が公開しているsbom-tool（https://github.com/microsoft/sbom-tool）が試しやすいかなという印象です。あと、GitHub上で「SBOM」などのキーワードで検索するといろいろなSBOM生成ツールがヒットするので、使用される言語に対応したものがあるか、探してみるものありかと思います。脆弱性検査ツールは（私はRHEL系のMIRACLE LINUXをよく使うので）標準パッケージとして提供されていて、ある程度Webに情報があるOpenSCAPがとっつきやすいかなと思います。
Q：一万個とか多くの部品を含んだSBOM間で一致するものがあるか検出するには、項目内容の命名規約が完全一致する必要があります。一文字違っても不一致になりますので、何かそれを解決するツールなどの取り組みはあるのでしょうか？
A：
取り組みとしてはPURLなどのコンポーネントを一意に表現できる標準フォーマットの採用が各団体の取り組みとしてありますが、それを基準として受入検査を行う専用ツールは私はまだ知りません。
Q：SPDXやCycloneDXといったフォーマットで定義されている項目にくわえて、あるとよりよいと思った項目はありましたでしょうか。
A：
正式な仕様として、コンポーネントの提供元の保守期限、ポリシーなどを掲載できると良いと思いました。
Q：CycloneDXの提唱元のOWASPのDependencyTrackがSPDXを批判してサポートをやめてしまったりと、CycloneDXとSPDXはうまくいっていないと思っていました。統合する方向の活動があるとのことでしたが、関係は改善したのでしょうか。
A：
改善したかどうかの情報は持っていないです。ただ実務面では、結局は統合することになるのではないかと思っています。CycloneDXとSPDXは起こりや思想が若干違う部分があるので、相容れない部分はあると思います。OWASPはセキュリティ寄りの考え方で、システム全体を表現するんだという思想がある一方、SPDXはライセンス管理の目的から始まっています。ただCycloneDXのドキュメントを読んでみると、SPDXのIDを使えたりとか、SPDXで表現されているものをCycloneDXの中で活用することについて書かれていたりするので、実務面で絶対に相容れないということにはならないんじゃないかと思っています。
Q：米国のNTIAはフォーマットとしてCycloneDX、SPDXと並べてSWIDを挙げていますが、自分が見る範囲ではあまりSWIDを目にすることがありません。現状だと普及しそうなのはCycloneDXかSPDXのどちらかになりそうでしょうか。
A：
SWIDもSBOMとして機能するだけの仕様を備えているかと思いますが、本質的な目的はソフトウェアの一意の識別にあると思います。よって、SBOMのフォーマットとして普及していくのは現状ではCycloneDXやSPDXといったソフトウェアの構成要素、依存関係を記述することに適したフォーマットになっていくのではないかなと思います。一方、SWIDが使われなくなるかというとそうではないと考えており、PURLと同様にCPEに替わる一意なソフトウェア識別子として使われていくのではないかと思います。
Q：各顧客からSBOMのフォーマット（SPDX、SPDX-Lite、CycloneDX）がバラバラに請求される場合にどのような管理をしたらよいかアイデアあるでしょうか？
A：
CycloneDX CLI ではCycloneDX → SPDXの変換が可能です（ただし、現状では仕様の差異からSPDXに変換した際に一部の情報が失われる場合があるそうです）。それぞれの仕様のマッピングが一部コミュニティではすでに着手されており、将来的に相互変換可能なユーティリティが登場してくるのではと思います。
