日本でも一部では実運用段階に入ったSBOM、今後の普及に向けた課題は何かを話し合ったOSSのサプライチェーン管理、取るべきアクションとは(4)

SBOMは、日本でも一部の企業では既に取り組みが進んでいる。では、一般的な普及に向けてはどのような課題があるのか。自動車業界、半導体/組み込み業界、システムインテグレーターと、異なる立場の関係者が話し合った。

» 2022年08月02日 05時00分 公開
[齋藤公二]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 オープンソースソフトウェア(OSS)のサプライチェーン管理における重要なトピックとして、前回解説した「SBOM(Software Bill of Materials:ソフトウェア構成表)」がある。2021年のサイバーセキュリティに関する米大統領令で取り上げられたことなどから、急速に注目が集まっている。

 ただし、SBOMとは「サイバーセキュリティだけ」のための「新しい」仕組みだというのは誤解だ。

 ソフトウェア納品の際に、利用しているOSSの情報を一定のフォーマットで提示するSBOMの仕組みは、以前から提案されてきた。目的は、セキュリティ脆弱(ぜいじゃく)性管理だけでなく、バグ対応やライセンスコンプライアンスを含めた包括的なサプライチェーン管理にある。

 では、SBOMは現在、どのように使われているのか。さらなる普及に向けてはどのような課題があるのか。自動車業界、半導体/組み込み業界、システムインテグレーターと、異なる立場の関係者が話し合った。

参加者:

伊藤義行氏

ルネサスエレクトロニクス オートモーティブソリューション事業本部 車載デジタルマーケティング統括部 プリンシパルスペシャリスト

田中美有氏

トヨタ自動車 知的財産部 知財企画室 ガバナンス推進グループ

渡邊 歩氏

日立ソリューションズ デジタルシフト開発支援本部 プロセス改善ソリューション部 部長 シニアOSSスペシャリスト

SBOMへの関心は、日本でも急速に高まっている

日立ソリューションズの渡邊氏

渡邊氏 まずはそれぞれの自己紹介から。私は日立ソリューションズで、お客さま向けに、OSSコンプライアンスの社内プロセスや体制作りを支援するコンサルテイングや、OSS管理ツールの販売などに携わっています。2022年4月からは、社内向けに、当社で開発するソフトウェアのOSSコンプライアンスを推進する事務局にも所属しています。

伊藤氏 ルネサスエレクトロニクスで自動車関係の組み込みソフトウェア開発をしています。また、Linux Foundationをはじめとするコミュニティーに対応する活動に携わっています。直近ではSPDX(SBOMのフォーマットの一つ)関係にプルリクエストを出すなどしています。

田中氏 トヨタ自動車で知財企画室 ガバナンス推進グループに所属しています。2020年1月にOSSチームに入り、OSSコンプライアンス業務に携わっています。OpenChainの活動にも参加しています。社内では開発エンジニアへのOSSの教育や社内体制の構築に関わっています。

渡邊氏 SBOMの重要性について、それぞれの企業の取り組みを踏まえて、ご意見をいただけますか。

ルネサスの伊藤氏

伊藤氏 個人的には、SBOMは今後OSSだけでなく、プロプライエタリなソフトウェアやADAS(自動運転支援システム)関係の組み込みソフトウェア全般に広がっていくと見ています。ただ現状は、お客さまから要望を受けたときにのみSBOMを提供しています。

 最近では、例えばYocto Projectのように、SBOMを自動生成できるOSSのコンパイル環境があります。こうしたツールでコンパイルし確認したことを、納品時に伝えておきます。すると、SBOMについて問い合わせを受けた場合に、「ソフトウェア提供時にお知らせしたOSSのツールチェーンでSBOMを生成可能ですので、ご自身でご確認ください」と答えられます。こうした対応をすることは多いです。ただ、OSSコミュニティーによる想定が不完全となり得る、実商用環境ならではの課題に向けた備えなど、今後に向けて関係者への働きかけを強めているところです。

トヨタ自動車の田中氏

田中氏 自動車業界全体が「100年に一度の大変革期」と言われる中、ソフトウェア開発は大規模化、複雑化しています。さまざまなサプライヤー、ベンダーと協力して開発を進めていて、「サプライチェーンのどこで、どんなソフトウェアをどう使っているのか」への関心は急速に高まっています。不具合や脆弱性の早期発見を主な目的に、SBOMを活用する動きも進んでいます。お客さまへの情報公開の観点でも、SBOMの重要性は高まっています。

米国では対応必至、トヨタも実運用を始めている

渡邊氏 半導体業界や組み込み業界では、地域や事業ごとに取り組みに温度差があるという状況ですか。

伊藤氏 米国では対応が迫られていますが、国内では取り組みが一部始まったところですね。欧州はルールが整備されればすぐに取りかかるといった印象です。一方、新興国では「SBOM? 何それ」という状況。かなり温度差がありますね。

渡邊氏 自動車業界はどうでしょうか。SBOMが広まったきっかけはありますか。

田中氏 当社では、OSS情報をもらうときに「SPDX Lite」を使っています。情報をやり取りする際には2つのレベルで取り組みを進めています。

 1つは、会社間でベーシックなルールを決めて合意すること、もう1つは、当社とサプライヤーのエンジニアの実務者同士でのやり取りの中で運用ルールを決めることです。最初に、会社間の契約として「どんなOSSを使っているか」という点を明確にしたことがスムーズな利用につながったと思っています。

渡邊氏 OSSの利用情報を開示することに抵抗を感じるサプライヤーはいないのですか。

田中氏 部品を発注するときにOSSの情報を出すことも条件に含んでいます。SPDX Liteのフォーマットに従って、全てのサプライヤーと情報をやりとりすることについては、特に抵抗なく行っていただいています。

渡邊氏 自動車業界では、SBOMに対する理解がかなり進んでいるのですね。驚きました。

伊藤氏 自動車関係は早いですね。トヨタさんは特に国内で早いほうで、欧州に比べても早かったと記憶しています。欧州でSPDXなどのSBOM記述フォーマットが指定され始めたのは、早い企業で約5年前ですが、それより前はWordファイルなどでリストをやりとりしたり、契約書にライセンスリストをつけたりするケースが多かったです。当時は、ユーザーの調達担当者とサプライヤーの営業担当者が、OSS利用における課題感を共有し始めた段階でしたが、そこからSBOMに行き着いたという印象です。特に、SPDXの利用は米国よりも欧州が先行していました。

渡邊氏 当社の事例も紹介します。日立ソリューションズはシステム構築やパッケージ開発、組み込み開発などを行っていますが、SBOMの重要性はトレーサビリティにあると感じています。先日のLog4jの脆弱性対応が典型的です。当社が提供したソフトウェアに当該ライブラリが使われていないか、影響範囲まで含めて全部調べる必要に迫られました。実際には、SBOMを十分に利用できず、多くの手作業が発生してしまったのですが、有効に活用できていれば非常に効果があることを実感する、いい機会になりました。

「Log4j」のような脆弱性情報を素早く把握できるメリットも

伊藤氏 脆弱性の問題については、誰が対応するのかが議論になりますよね。コミュニティーレベルで対応するのか、ローカルなパッチを当てて現場で対応するのか、さまざまな議論がある中で、今は個別対応している状況です。SBOMがあれば、OSSのツールチェーンの中で誰に責任があるのかが見えやすくなり、対応が早くなります。組み込み業界では、そうしたメリットは既に理解されていると思います。

渡邊氏 では、SBOMに期待すること、SBOMが果たすべき役割についてご意見をいただけますか。

伊藤氏 今のSBOMはバイナリの取り扱いが上手ではないですよね。組み込み関係でいえば、ソースコードの脆弱性情報が製品に含まれるバイナリファイルに該当するのか、コンパイルオプションが影響することがあります。そのため、脆弱性の情報が出た場合に「われわれの製品にはこれは関係ない」と断言できません。組み込みのようにオンラインでパッチをダウンロードできない製品の場合は、それによってサービスを停止するかどうかまで影響します。そこでSPDXコミュニティーでは、SBOMにバイナリパッケージでの利用情報を組み込んで、バイナリパッケージに対しても情報を追跡できないかを議論しているところです。

渡邊氏 機能を拡充しすぎると、汎用(はんよう)のフォーマットとして利用しにくい面も出てくる気がします。議論の際に気をつけていることはありますか。

伊藤氏 NTIA(米商務省国家電気通信情報局)がSBOMの最小要素を提示した際にも述べていましたが、SPDXコミュニティーではソフトウェアからSPDXが自動的に生成されることを重視しています。一方、日本側から提案したSPDX Liteのように、手書きで人の目で見ても分かることも重要です。簡単に書けるものと細かく書けるものは両立すると思っていて、今後は、ツールで自動生成するものは情報がリッチになり、最低限のものは少ない情報を取り扱うかたちで残るのではと考えています。フォーマットを議論すると同時に、ツールとどうつないでいくかも一緒に考える必要があると感じています。

渡邊氏 ツールのあり方についてはOpenChain Japan Work Groupでも議論したいところです。田中さんはいかがですか。

田中氏 実装コストに懸念を抱くサプライヤーさんが多いのではと感じています。その辺りの理解促進活動を、コミュニティーを通じて進めていくことを期待しています。また国内での普及が進む過程で、ソフトウェア開発や調達に関わる人が本格的なSBOM運用に備えておける仕掛けをコミュニティーでできたらと思います。細かいところでは、サプライヤーさんは必ずしも、SPDXで決められたルール通り情報を入力してくれるわけではないのですが、その情報を手作業で直すといった手間がかからないようにする仕組みなどです。

これから始める人へのアドバイス「まずはSPDX Liteを書けるように」

渡邊氏 コストを誰がどう負担するかは難しい問題です。われわれSIerのようにソフトウェアをつくる立場からすると、SBOMの作成によって対応コストは確かに増えます。ただ、それが悪いことではなく、きちんと対応していることが逆にSIerとしての評価を高める手段になったり、ソフトウェアを使う人がSBOM対応のメリットを理解したりするようになると、SBOMへの期待がより高まります。「やらなきゃいけないことが増えただけ」ではなく「脆弱性対応がスムーズになる」「情報のやりとりに手間がかからなくなる」といったメリットが広まっていくことが大事だと考えてやっています。

 当社では経営層の理解もあり、SBOMに対応するコストを投資と捉えることができました。ですが、ソフトウェアを開発する側だけでなく利用する側にも、SBOMへの対応でメリットが生まれるということへの理解が求められると思います。

伊藤氏 組み込み業界でもOSSは不可欠な存在ですが、OSSにまつわる対価については明確な指針やルールがないと感じています。お金のやり取りをどうするかは今後考えていく必要があります。

田中氏 SBOM対応が追加の仕事になると抵抗感が出てくると思います。ただ、OSSを使う以上は頒布になるので、情報を提供する必要があります。SBOMを提供することで「仕事が楽になる」「工数が減る」という本来的なOSSの活用のあり方を実現する方向に進めばよいと感じています。「強制される」ではなく、皆が腹落ち感を持てる理解活動、啓発活動が大事だと思います。

渡邊氏 構造化されているSPDXは「とても難しいもの」というイメージが強く、それが阻害要因の一つになってきたと思います。日本からSPDX Liteを提唱した理由もここにあります。「実は簡単にできる」ということを知って、苦手意識を払拭(ふっしょく)してもらうのはポイントかもしれませんね。では、これからSBOMを始める企業へのアドバイスをいただけますか。

伊藤氏 まずはSPDX Liteを書けるようになりましょう、と言いたいです。実際に流通が始まっていますから、ビジネスをする上で必要な知識です。また、OSS管理のSW360など、OSSツールを標準に沿って使うことが重要です。コストをかけずにSBOMへの対応ができるようになります。

田中氏 私も、Excelでも何でもいいのでSPDX Liteをまず書いてみることをお勧めしたいです。SW360などのツールを使って自動でSBOMを生成できることを知らない方も多くいらっしゃいます。簡単にできるんだ、業務で本当に必要なんだ、ということをしっかり発信していくことが必要だと思います。

渡邊氏 お客さま向けにコンサルをしていると「SBOMに対応したいです」という声はかなり増えました。ただ、その中身を細分化してみると「構成管理をしたい」「標準的なフォーマットでSBOMを作りたい」「脆弱性対応をしたい」などさまざまな要素があります。そこで提案しているのは「SBOMを使って何をしたいのか」をはっきりさせることです。課題がクリアになり、優先順位も分かるようになります。

伊藤氏 営業や調達など、エンジニアだけでなく、ソフトウェアビジネスに関わる人皆がSBOMを知り、それが実ビジネスでどう役立つかを腹落ちして議論できるようになりたいですね。

渡邊氏 当社が発信しているOSS管理ブログの「SPDX LiteでSBOMを作ってみよう」という記事を見て、使ってくれる人が出てきました。OpenChainも含めてさまざまなコンテンツがいろいろなところに出てきて、それを見ながら実践できるような環境になっていくといいと思います。

 伊藤さんや田中さんがおっしゃるように、入り口のハードルを下げながら、メリットの理解や取り組みを通して納得感を持つことが大切だと思います。業務のプロセスとしても「SBOMを作ること」「SBOMを管理すること」「SBOMを求められたら提供すること」がセットになり、当たり前の取り組みになっていけばいいと思います。すると、サプライチェーンの下流からボトムアップで取り組んだり、国の主導でトップダウンで取り組んだりする中で「皆がSBOMに取り組んでいく世界」が実現していくはずです。OpenChainでも、そこまでの橋渡しができればいいと思っています。

l特集:OSSのサプライチェーン管理、取るべきアクションとは

オープンソースソフトウェア(OSS)の利用が多くの企業で本格化し、ライセンスやセキュリティ、品質などのリスクが表面化しようとしている。「OSS=フリーソフトウェア」という認識ではこの状況に追いつくことができない。しかもOSS利用は企業内の異なる事業部、グループ内企業、開発パートナーなどに広がっている。企業はこれをサプライチェーンとしてとらえ、リスクを適切に管理していく必要がある。では、どう行動すべきか。本特集では、OSSの推進とマネジメントを行う社内組織「OSPO(Open Source Program Office)」、およびソフトウェア構成表「SBOM(Software Bill of Materials)」に焦点を当て、これらの現実の姿を解説および座談会で解き明かす。



Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。