【ルネサス×日立ソリューションズ】ルネサスエレクトロニクスにおけるSBOM管理、OSSコンプライアンスの取り組みセミナーレポート（2/2）

イベント概要

オープンソース・ソフトウェア（OSS）は、現在多くの産業で使われていますが、脆弱性やコンプライアンス面で、さまざまなリスクも存在しています。そんな中で注目されているのが、ソフトウェアを構成する要素を一覧できるリスト「SBOM（エスボム）」です。欧米の公的機関などでもSBOMの必要性が指摘されており、今後は国内のさまざまな企業・組織でも対応が求められる可能性があります。

本記事では、株式会社日立ソリューションズ主催「SBOMを語る3日間！OSSマネジメントフォーラム2022」より、ルネサスエレクトロニクスの伊藤義行氏の講演をお届けします。

前半を見る（1/2）

スピーカー

伊藤義行氏

ルネサスエレクトロニクス株式会社
渡邊歩（モデレーター）

株式会社日立ソリューションズ

セミナー内容

伊藤義行氏（以下、伊藤）：では、ここから車載機器における業界動向とルネサスのオープンソフトウェア提供物における対応事例を述べさせていただきます。

伊藤：ルネサスで実際にSBOMを要求された事例があります。SBOMを実際作ることになった場合には、社内で当然議論があります。人的リソースはアサインできるのか、実際SBOMを作れるのか、というところから議論になります。「お客さまからの提供要求はあるんですか？」とか、「実際どの程度作るのに人がかかるんですか？」「自動生成が可能ですか？」とか。また当社が作るソフトやパッケージも数多くありますので、「すべてにおいて個別に人を貼り付けてやらなくちゃいけないんですか？」いった話もあります。あとは製品をお客さまにお渡しした後、お客さまの製品開発の中でQ&Aが生じるというのは当然あるわけですけれども、ハードウェア製品に対するQ&Aにくわえて、ソフトウェアに関するQ&A、さらにSBOMに対するQ&A、あるいはSBOMのメンテナンスなどの話もあり、そういったところも「工数賄えますか？」というような議論は当然ながらあります。
これらを材料としたうえで、SBOMについて社内利用とするか、あるいは実際にお客さまにSBOM提供できますという形でご案内するか、というところの議論もありました。この判断材料としては、「お客さま要望の度合い」、「業界動向・競合他社の状況、実際それが競争優位に繋がるかどうか」、「社内の開発管理上のリスク管理に使えるかどうか」などがあります。このようなことを議論したうえで、SBOM管理して行きましょうというところにもっていった流れになります。

伊藤：続いて、車載機器における業界動向という形で大きな括りにさせていただいてますけれども、当社は組み込み系のLinuxについて、ここ20数年やらせていただいておりますけれども、私どもの見ている範囲でどうなってきたかという話をさせていただきます。SBOMの提供についてお願いをいただくようになったのは、大体2020年くらいからという形になります。ただ、その前の2015年ぐらいだったと思いますが、欧州系のTier1のベンダーさんから、SPDXフォーマットという、ライセンス情報をまとめるための業界標準のフォーマットでライセンス情報提供してくださいという話が出てまいりました。やや遅れたかなというところがありますが、日本のTier1様からも「提供物にOSSは入っていますか？入っているならどんなものですか？そのライセンス条件は何ですか？」というような話が出てまいりました。

2020年ぐらいにSPDXコミュニティ、あるいはOpenChainでの議論もありまして、トヨタはLinux系搭載製品に関してSBOMの提供をお願いしますというような議論が固まってきました。実際に商談の流れの中でも、Tier1様からはSBOMを提供してくださいという話をいただくようになりました。SBOMは色々なフォーマットがあり、大きなものになると、とんでもなく巨大な仕様のものになりますが、後述するSPDX Liteという比較的軽量な、手書きで書けて人の目で読めるというものがありますので、「そちらに関してまず提供してください」「SPDX Liteで構いません」という話をいただくようになりました。そして2021年に米国で大統領令があり、サイバーセキュリティ議論が盛んになり、「SBOMとは何か」というところが急速に盛り上がってきて、議論が固まってきました。自動車業界ではサイバーセキュリティ関係の法的要件としてある程度固まってきたものも実運用に入ってまいりましたので、これに関して「SBOMをどうして行くんだ」と言う話が、まあ盛り上がってきている状況になります。ただ実際のところ、まずは「SBOMとして使えるものをください」「ライセンス管理のためでいいですからください」、という状況が今の日本国内、あるいは欧州も含めてだと思いますが、色々と試している段階になります。今回の事例で多少述べさせていただく中にSPDX Liteというものを取り上げますけれども、これはエクセルシートで、「このパッケージのライセンスはこれです」といった情報を数個入力するという程度のものです。このレベルからスタートしているというのが車載機器向け製品の業界動向になります。

またSBOMに関しては、SPDXコミュニティにおいても「これからSBOMとして必要なものは何か」ということを議論している段階です。世界的にSBOMへの対応としてかっちり固まったものがあるとか、これを出せば大丈夫という定番があるとか、そういうわけではないということに関しては述べさせていただこうかと思っています。

伊藤：続いて、当社のSBOMの対応事例という形で話を進めさせていただきます。実際のところソースコードをリリースする場合と、プロプライエタリなパッケージバイナリーを提供する場合とがあります。当社が半導体製品と一緒に提供するソフトウェアは非常に複雑な構成だという話を前の方のページで述べさせていただきましたが、それらの中にもソースコードをリリースするもの、バイナリだけのものもあります。

Linuxのカーネルはソースコード開示しなければならないライセンスを持っていますのでソースコードをリリースする場合もあります。ソースコードをリリースする場合で言うならば、お客さま側でSBOMを作成することも可能ですので、お客さま側で作ってくださいという場合も実のところあったりはします。またSBOMの自動生成もソースコードが手元にあるのであれば可能な場合もあります。

またリリース物とSBOMを、ソフトウェア開発部隊とお客さまの間にいるようなマーケティング部隊のような部門でチェックするといったことも可能になりますので、社内活用としてSBOMを使うこともできます。

また当然ながら、一般的にOSSを取り扱う上ではライセンス条件がお客さまの要望にちゃんと合致しているかには注意が必要です。使用するパッケージの取捨選択をする時にライセンス条件を確認しないで間違えると、「GPLのこのバージョンはライセンス条件が当社の方針と合いません」といったことに気づかずに出してしまったりします。このような話はそもそも提供する側が開発の段階で確認しておく必要があります。これもSBOMを使えばリリース前にチェックできますので、SBOMをライセンス記述のクロスチェック機能として使うこともできます。

また、ありがちなのが、標準BSPを複数のお客さまに配っていくとか、あるいは、ルネサス社内においてあるプロジェクトで使ったオープンソースソフトウェアを別プロジェクトで流用するような場合です。このような場合は、「ライセンス条件の見落としがないか？」「ライセンス条件、ちょっと厳しいものがあるんだけど、今回のお客さまは大丈夫か？」といったところを管理する必要があり、ここをSBOMで管理をするといったような話もございます。また当然SBOMをメンテしなくてはいけないという話もございます。

伊藤：あとバイナリーリリース物ですね。これは基本的にはプロプライエタリソフトウェアでライセンス条件は単一ですので、記載は容易な事が多いです。SBOMとしてセキュリティ要件を記載することを将来の機能として期待されているという話はこの後させていただきますけれども、現状ライセンス条件を記載するということであるならばプロプライエタリソフトウェアは記載が容易なはずです。ただ実際のところ、複雑な製品群になってまいりますと中に含まれているリファレンスコード、あるいはサンプルソフトウェア、ドキュメント類など、ライセンス情報が異なるようなファイルがリリースパッケージの中に含まれている場合があります。

こういった製品パッケージ全体にツールをかけてもSBOMができない場合があります。ライセンス条件について、このファイルはこれ、このファイルはこれと、多量にバラバラと出てきて、パッケージ全体に対するライセンス条件が定まらないといったようなことがありがちです。そういった場合は、当然SBOMをそのライセンス条件ごとに分けます。このアプリはこう、このサンプルはこう、という形で記載します。これらについて、手書きで作る場合やツールを使う場合もそうですが、複雑化すればするほど工数がかかってきますので、製品パッケージの構成とOSSのライセンス条件はしっかりと見ておかないといけません。

本当はお客さまに提供する前の社内のソースコードでSBOMをツールでパッと生成してしまって、それをお渡ししてしまえば楽という議論があるんですけれども、社内の事例ではソースコード構成がSBOMの中に透けて見えてしまうという点からお客さまに提供するものとして適していないという話もありました。それを受けてやはり手作業で起こすこととし、今までやってきた製品を改めて見直すといったことも事例としてあります。

LINUX BSP開発者向けツールチェーン：YOCTO PROJECTのスライド

伊藤：ソースコード提供の場合にはツールをかけてしまえば一発ですよという話があり、世の中にはSBOM対応のツール、プロプライエタリ市販品含めて色々あるかと思います。ルネサスの今回の事例では、ソースコードからターゲットの半導体に乗せるためのバイナリを生成するツールチェーン（ビルド環境）のところで業界標準ツールを使っていました。これが非常に優位に働きました。

Yoctoプロジェクトというものですけれども、これは標準でcreate-spdxというクラスを持っていて、標準状態でSPDXファイルを起こしてと言えばツールやコンパイル条件をすべて舐めてSPDXファイルを起こしてくれましたので、これをお客さまに提供すれば良いだけでした。

Linux関連は行数が非常に大きいということを冒頭で紹介しましたが、そのような巨大なものに関しても自動で生成できるので、ここではあまり工数がかかりませんでした。また、お客さまにこの方法でSPDXファイルを起こせますのでSBOMとしてお使いください、というご案内もできました。

伊藤：一方で、プロプライエタリなライブラリに対する適用事例ですけれども、トヨタの皆さんとのコミュニティでの議論として、SPDX LiteというSPDX標準の主要な一部の項目を抜き出したフォーマットを利用するというものがありました。これですと手書き可能ですし、法務部門とか知財部門の方が受け取っても目で追えるレベルのものになっていますので、簡易版のSBOMとして標準的に使われるのではないかなと考えております。

伊藤：ではこのSBOMについて、ここまでライセンス管理ということで述べさせていただきましたけれども、今後どうなるんだろうという話をさせていただきます。SPDXコミュニティで議論していますので、短い時間ですが紹介させていただきます。

ISO/IEC 5962:2021 SPDX SPECIFICATIONのスライド

伊藤：SPDXはISO/IEC 5962:2021です。Linux FoundationのSPDXコミュニティがSBOMを記述するフォーマットとして策定しており、CycloneDX、SWIDと並ぶ形で列挙されているというものになります。

伊藤：先ほど申し上げましたように、SPDX LiteというSPDXの主要項目を抜き出したフォーマットがあります。これをAnnex GとしてISO標準の中に入れたのはOpenChainの日本のワークグループです。サブワークグループが仕様をまとめてSPDXコミュニティに提案し、SPDXの2.2に取り入れていただいて、それがそのままISO標準になったという形になっています。ISO標準の一部ですので、これを自動車業界のSBOMとして使いましょうという話はできるかなと考えています。SPDXは今後バージョン2.3、3.0へと進んでいきますけれども、当然メンテしなくてはいけません。

伊藤：SPDXは非常に大きいので、バイナリパッケージを提供してくださっている我々のパートナー様、あるいはルネサスの社内でプロプライエタリなパッケージを起こしているような場合、SPDXの巨大な物をいちいち起こすのはちょっとたまりませんという話があった時に手書きでも作れますよという形でご案内をすることは、ルネサスの社内での事例としてございます。あるいは、インテグレーションを行う自動車業界のTier1様が「SPDX Liteで構いませんからSBOMを提供してください」という形で、実際に使われているという事例もございます。

伊藤：SPDXは今ISO標準でバージョン2.2という話がありましたけれども、今年になってバージョン2.3というものが決まりました。来年に向けてバージョン3.0という話になっています。今のバージョンはライセンス情報を中心にした記述になってますけれども、セキュリティ情報に関する記述も追加されていくので、「この製品に含まれているこのソフトウェアパッケージの脆弱性情報は、この製品に影響する・しない」というのを機械的に判断できるように対応して行くという議論がおこなわれています。

その中で、SPDXのファイルの全体構成を変えなくてはいけないね、という話がございまして、プロファイルという概念で用途別・更新頻度別にSPDXファイルを若干変えていく議論もおこなわれています。ソースコードからSBOMを分析して作成する話もありますし、ビルド情報からコンパイル情報を取り出して別のSBOMとして提供するといったような議論もございます。