SBOMに関する質問と回答まとめ（OSSマネジメントフォーラム2022 Day2）｜OSS管理ブログ｜ソフトウェア部品管理ソリューション

先日開催された「OSSマネジメントフォーラム2022」にて、ルネサスエレクトロニクスの伊藤様にSBOM関連の内容についてご講演いただきました。また講演を終えた後には聴講者の皆様からの質問にもお答えいただきました。本ブログではその際にいただいた質問と、それに対する回答のサマリーを掲載します。核心に触れる質問を数多く頂戴しましたので、参考にしていただければ幸いです。

質問と回答

ビルド時にリンクされないDLLや、独立アプリとして利用するコンポーネントなどを添付する場合、どのようにSBOM管理されておられますでしょうか？

A：
基本的に独立したアプリケーションに関しては独立したSBOMを提供することになります。SPDX-Liteの場合は製品やアプリケーションごとに生成し、それらの構成パッケージを1行ずつ記載して製品やアプリケーションの照会を行います。一方で、一部のツールチェーン、例えばYoctoプロジェクトの場合、ビルド時にメタファイルやレシピファイルを用いることで使用パッケージを組入れることも行われており、この場合Yocto環境の自動解析ツールによってSPDXファイルを起こせます。このようにSBOMを作成し、提供することも可能です。

Q：SBOMのメンテナンスに興味があります。Linuxは頻繁にバージョンが変わりますが、その度にSBOMの情報を変えているのでしょうか。あるいはLinuxカーネルは１つのバージョンに固定して、セキュリティパッチが出た場合にのみSBOM情報を変えているのでしょうか。

A：
Linuxの中でも、Linuxに関連するソフトウェア全般にバージョンアップが激しいという話はあります。セキュリティ対応が早い、というのがオープンソースソフトウェアの特徴でもあるので、更新に追いついていくことはセキュリティ対策上有利でもあります。もちろんお客さまによってはバージョンを固定したいというお客さまもいますが、基本的には新しいバージョンが出てきたとき、組入れに関してお客さまが新しいものを組入れる話もあります。ソースコードの開示物に関してはYoctoの環境で、その都度SBOMを生成する対応をすれば最新版のソースに応じたSBOMが生成されるので、ライセンス条件の変更に適合したSBOMが自動生成されます。それを新しい版と一緒に提供します。当然プロプライエタリなものに関しては下回りのLinuxが変わったときに対応が必要であれば修正を行いますし、修正を行えば当然ながらSBOMも修正します。またライセンス条件などで変更があれば修正を行います。一つのバージョンに固定するお客さまもいるがルネサスからは新しいものが出たら新しいものを提供しています。あるいは最終バージョン以降はお客さまでメンテナンスしてくださいという責務も当然あります。この場合、ソースコードを出しているので自前でSPDXを起こすことができますというご案内を含めて追従込みでお願いをしています。

Q：どうやってSBOMを管理していますでしょうか？ツール名などを教えていだたけないでしょうか。

A：
講演者が所属する部門では、現状、SBOMを提供する側ではあっても受け取る機会が少ないため、講演中紹介したYocto ProjectによるSPDX生成を随時行う以外にツールを用いていません。継続してOpenChain Projectなどで議論されている業界動向などを参照しツールを検討する方針です。

Q：SBOMを作成するにあたり、どういうチェック項目があるのか（管理のノウハウ的なものと注意点もあれば）ご教授お願いいたします。

A：
チェック項目については現在社内でしっかりまとめて共有しなくてはいけないなと思っているのですが、現状は手法や手順について共通のものとして作れている状況ではありません。SBOMを作成する際、最終的にライセンス情報をまとめるところまでツールで実施できず、目で見てどういう構成をしているかを開発元と相談し、SPDX-LiteをExcelで書くという泥臭い対応になってしまっている部分も現状の事例としてあります。これについては、例えばツールに関して議論しているOpenChainコミュニティの成果を利用するなどがあると思っており、このあたりがこれからの課題だと思われます。

Q：SPDX-Liteのデメリットには、どのようなものがあるでしょうか？

A：
SPDX-Liteは主要項目を抜き出したフォーマットになっています。SPDXフルセットの場合は非常に細かく書けます。構成しているファイル一つひとつに対してのライセンス条件やその文言について非常に細かく網羅的に書けます。ファイル間の依存関係も解析してなるべく細かく書こうという形式で出てきます。SPDX-Liteは手で書ける範囲ですので、それらの細かい情報はさて置き「パッケージ全体ではどうか」「リリース物としてどうか」という記述を行うフォーマットに特化しています。ソースコードの中身やファイルの中身を追いかけていくことはできません、というのがデメリットになるかと思います。

Q：いまルネサス様が提供しているSBOM、特にSPDXのものを取得したい場合には、どのようにすればよろしいですか？

A：
オープンソースでルネサスが開示しているものに関してはYocto環境の判例があります。Yocto環境内のドキュメントでSPDXの起こし方が記載されていますので、それをもとにSPDX生成してくださいというのが標準的なご案内になっています。一方、プロプライエタリなものに関するSPDX-Liteに関しては業務の一環として商談の中で提供させて頂いています。これは営業経由でご請求頂いています。これも評価環境という形でクリックするだけでダウンロード可能なライブラリがありますが、そちらに関してはSBOMへの対応は遅れています。

Q：SBOMを作ったあと、具体的にどういった場面で役に立つのか、活用のされ方を教えてください。

A：
今のSPDXを含めたSBOMはライセンス条件のチェックを行うのが基本的な用途です。将来的には今回の講演で紹介したように、SBOMを集計することでどのソフトウェアパッケージがどの製品に使われているかを機械的にチェックできます。またセキュリティインシデントが報告されたときにツールを掛ければ自動的に、ここの製品に含まれているこのパッケージはこの脆弱性情報に当たる可能性がある、というのがわかります。さらにコンパイル情報もSBOMの中に持っておけば、コンパイル情報の中からそのセキュリティインシデントが発生する条件に合致するコンパイル条件であったかどうかを機械的に集計して実製品への影響の有無を判断できるます。これらがもともとのSBOMの定義となっておりますが、現状はセキュリティ情報の拡充について議論している最中になります。

現状は、例えばライセンス条件で「GPLv3は使いたくない」という話があったときに、「このパッケージにはGPLv3のこれが含まれているので評価用でお使いください」といったご案内ができます。このようにライセンス情報が詳細化されていればライセンス条件に合わせて議論ができますので、このような面でSBOMを活用できると思います。

Q：OSS脆弱性問題が発生した場合、SBOMをどのように利用して対応されていますでしょうか。また顧客に提供したソフトウェアへの脆弱性対応についてはどのようにされていますでしょうか。SBOMの活用という観点で教えていただければ幸いです。

A：
講演者が所属する部門では、現状、SBOMをライセンス情報の提供手段として用いており、セキュリティ管理との連携は今後の課題となっております。しかしながら、SPDXコミュニティでセキュリティ情報についての議論が広範に行われていることなどから、SPDXを中心にSBOMを提供・更新していくことで業界動向に沿ったセキュリティ対応との連携が実現できることを期待しています。

Q：バイナリに対するSBOMに興味があります。バイナリを構成するソースコードが一意に決まるようにすべてのソースコードのハッシュを保存する必要はあるのでしょうか。また、バイナリは静的リンクにしておく必要があるのでしょうか。動的リンクの場合、依存するライブラリ、OSなどの記述を行っておけばよいのでしょうか。

A：
バイナリパッケージのBuild情報、Link情報、使用したソースコード（公開されているもの以外に、対外的に非公開のものを含む）とのトレース可能性は、SPDXコミュニティなどSBOMの記法・定義を議論している皆様の間でも現在議論している最中、という認識でおります。講演者としても個人的に議論状況を追い続けることができればと考えております。

Q：御社ではGPLなどソースコード開示を求められるライセンスのOSSを活用する際、どのような方法で開示を行っていますか？

A：
講演者の所属する部門では、GitHubなど大手ソースコード共有ベンダー、eLinuxなどLinux Foundation関連の公開サイト、自社で展開している質疑フォーラムを用いた公開を実施しております。なお、当社がリリースしたOSSを装置製造系のお客さまが製品に組み込まれる場合には、当該のOSS管理についてお客さま側で対応をお願いしております。

Q：SBOMフォーマットはSPDXほか、それそれの互換性はあるのでしょうか？またSPDXでも互換は問題ないですか？（v2.X→v3.Xなど）

A：
SBOMの代表的なものとしてSPDXとCycloneDX、SWID tagがあります。SPDXコミュニティの中でもCycloneDXとの相互互換性、特にCycloneDXにしてからSPDXに戻したときに、情報が落ちないかというのを今議論している状況です。相互互換性は対応しなくてはならないとの問題意識はコミュニティの中でも持っています。現段階では記述の詳細部分に若干差異があるので、情報が行って戻ったときにデータが抜け落ちたり、あるいはNOASSERTION（未定義）になってしまったりすることがあります。SPDXのバージョン間での互換性に関しては、今バージョン3に向けて検討していますが、その中でmandatoryやoptionalの定義が若干変わっています。厳密に言うと、新たにmandatoryになったものが抜け落ちているところが出てくると互換ではないという話にはなります。ただSBOMとして、これはSPDXバージョン2ですという宣言がありますので、そのファイルが渡されたときにツールはSPDXバージョン2として扱うので問題ありません。そのような運用になっています。

Q：複数の導入元からSBOMを受け取ったり、複数のツールでSBOMを生成したりする際に、本来は同じOSSが、それぞれのSBOMで異なる名前で登録されていることが起きます。これを1つに名寄せしないと、ライセンスや脆弱性の把握が困難になりますが、うまくできずに苦労しています。ルネサスで何か工夫されていることはございますか？

A：
SPDXコミュニティでもCycloneDXなどSBOMフォーマット間の相互運用性について議論が行われていると伺っております。現状、業界動向を追い続け情報を確保するしていくことで解決を期待する段階かと考えております。

Q：SBOMの自動生成について質問です。自動生成後に精度的な問題から手動で内容を検証する必要はあるのでしょうか？

A：
ソースコード中に、ライセンス表記のないドキュメントファイルが混在しているケースなどで、ツールが期待するライセンス判断を実施しない場合があります。そのような場合、SPDX Liteなど手書き生成可能なSBOMを代替で提供する、SPDXの記載を手作業で修正のうえFile AnalyzedタグをFALSEに修正する、などの手段が考えられます。講演者が所属する部門では、SPDX Liteでの代替を実施した経験がございます。

Q：ツールでSPDXを自動生成すると、多くのフィールドがNOASSERTIONになっていて、実質的に情報がないことがよく起きます。社外からSBOMの提供を求められる際に、現状でこれは問題にされるのでしょうか。ベストエフォートで受け入れられるものでしょうか。

A：
ツールが良くなっていくことを期待したい、という部分はあります。一方で、ソースコードをリリースしているものに関しては「ソースコードが原本です」という言い方もできてしまう、というのが半導体ベンダー側から見た立場です。NOASSERTIONが出てしまった場合、ベストエフォートで対応できるようであればなるべく対応します。場合によってはSPDX-Liteに手書きで「意図はこうです」という形で書かせてもらうこともあります。ただし一般的にNOASSERTIONで情報が無い場合、異なるライセンスのものが混じっていることがあります。例えばdocumentディレクトリがあってCCBY0と書いてあるが、ほかはGPLとMITのデュアル（ライセンス）であり、それらが混じることでNOASSERTIONとなることがあります。その場合には手作業でSPDXを起こすときに、これらを区分けしてSPDXを生成するなどします。このように個別対応を現状においては行うことになります。

Q：SPDXでライセンスを管理する際に、その時点のSPDX License Identifierがないライセンスはどのように管理されているでしょうか。SPDXドキュメント中で独自のIDを定義することもできますが、これをルネサス全体で管理されていますでしょうか。

A：
SPDXの仕様上、質問頂いた内容の場合、Concluded LicenseなどにはNOASSERTIONとしたうえで、Extracted TextおよびLicense Nameに名称を記載、License Commentに概要を記載することになるかと存じます。

SBOMに関する質問と回答まとめ（OSSマネジメントフォーラム2022 Day2）