今、「SBOM」（Software Bill of Materials、ソフトウェア部品表）という言葉が注目を集めている。いったいなぜSBOMは必要とされているのか。そして、SBOMを活用してソフトウェアのセキュリティ品質を高めるには、どのようなポイントに留意しなければならないのか。
大阪大学の最高情報セキュリティ責任者（CISO）でサイバーメディアセンターの猪俣敦夫教授を招き、ベリサーブのサイバーセキュリティ事業部脆弱性マネジメント課の藤原洋平氏と、同技術開発課の平山昌弘氏にSBOMの必要性について伺った。
サプライチェーンのつながりの中での脆弱性管理を支援するSBOM
――そもそも、SBOMとはどのようなものでしょうか。
猪俣氏：SBOMという言葉自体は頻繁に耳にしているかと思いますが、そもそもよくわからない、という声も多いようです。それでも昨今の状況を踏まえると、分野によっては迅速な対応が求められはじめています。
たとえば、私たちが見たこともない海外のお菓子を買うときには、成分表を見て何が入っているかを確認します。これを元に、砂糖が多かったり、知らない甘味料が含まれているようだったらやめておこう、といった判断が下せます。
食品を買うときには製造元だけを意識しがちですが、実際にはいろいろなルートでやってきた原材料が含まれています。メーカーだけでなく、こうした原材料の出元まできちんと追いかけることができれば、健康にいいのかどうかをより適切に判断できるかもしれません。これと同じ考え方をコンピュータに持ってきたものがSBOMといえます。
――なぜSBOMが必要なのでしょうか。
猪俣氏：ソフトウェアは今のところまだ人間が作り上げるものである以上、当然、少なくない脆弱性が出てきます。コミュニティが作り上げたオープンソースソフトウェア（OSS）はもちろん、OSSのライブラリをコンポーネントで組み込んだ有償のパッケージソフトウェアにおいても、作り込みの中でどうしてもバグは生じてしまいます。
しかも昨今のソフトウェアは、たくさんの小さな塊（コンポーネント群）の組み合わせによる巨大なコードで成り立っていることがほとんどです。しかも、それら塊は工業製品の場合、サプライチェーンを形成する各社で作られ、組み合わされたことによって依存関係も複雑化しています。
ここでもし、お菓子と同じようにソフトウェアの成分表記が見えるようになれば、どこにどのような脆弱性があるかが把握しやすくなり、状況が改善するかもしれません。それも、ある特定のタイミングだけでなく、診療カルテのように時系列を追って経過が記録されていれば、なお便利なはずです。それをコンピュータの世界に置き換えたものがSBOMです。
大阪大学 サイバーメディアセンター副センター長,情報セキュリティ本部CISO教授 猪俣 敦夫 氏
SBOMの必要性が強く認識されることになったきっかけは、Apache log4Jの脆弱性が発覚したことでした。脆弱性が発覚したら修正が必要ですが、先ほど言った通り、今やOSSの世界の開発スタイルは多岐に渡り、誰か一人に聞けばわかるというものではありません。その上開発はボランティアベースですから、すぐに対応してくれることもあるでしょうが、問い合わせをしても全く反応がない、ということも十分にあり得ます。
そんな中で、log4Jのライブラリがどんなシステムに入っており、どれだけ使われているかを調べるのは非常に大変な作業でした。米SANSがXで「これはまさに長距離マラソンのようなものだ」とつぶやくほど、果てしのない作業でした。
平山氏：あれはまさに、世界中で「お祭り」のような大騒ぎになりましたね。
特に難しいのは、ソフトウェアサプライチェーンの複雑なつながりの中でどうコンポーネントを管理していくかだと思います。A社から納品された部品にはB社のソフトウェアが組み込まれ、さらにB社のソフトウェアにはC社のソフトウェアが組み込まれているといった状況は珍しくありません。そんな中で、Ａ社は自社の製品に含まれるソフトウェアにどのようなコンポーネントが含まれているかを把握するのは非常に難しくなっています。
しかもソフトウェアは、リリース後も随時改良されていきます。B社のソフトウェアのバージョン1に脆弱性が判明すると、それを用いているA社のソフトウェアのバージョン2はもちろん、古いバージョンも影響を受けることになります。こういった関係性をたどるには、スナップショットのように最新の情報だけを把握するのでは足りません。脆弱性の影響範囲を把握し、管理するには、ソフトウェア開発のタイムラインやバージョンを意識したSBOM管理が必要だと考えます。
海外、そして自動車や医療分野で先行するSBOMの活用
――脆弱性対応という観点からはもちろん、海外では法制度上もSBOMが求められるようになっていますよね。
藤原氏：最も大きなきっかけになったのは、バイデン大統領が2021年5月に署名した、サイバーセキュリティに関する大統領令でしょう。サイバーセキュリティ強化の一環として、SBOMによる管理が盛り込まれました。これを踏まえたガイダンスが、米国の国家機関であるNITA(National Telecommunications and Information Administration)やNIST(National Institute of Standards and Technology )」などから出されています。
加えて欧州では、ソフトウェアを搭載する製品すべてを対象にした「Cyber Resilience Act」（CRA）が策定され、こちらでもSBOMが要求されています。
欧米では、こうした法規の制定前からソフトウェアサプライチェーンのサイバーセキュリティが注視され、継続的に取り組まれてきました。ですので、こうした法制度が整備されたからと言って新たな取り組みが始まるわけではなく、これまでの延長線上で対応しているように思います。一方日本企業は、CRAにどう対応するかで、急に慌てはじめたように見受けられます。
株式会社ベリサーブ サイバーセキュリティ事業部 技術開発課 平山 昌弘 氏
平山氏：CRAでは、脆弱性が発見されてから24時間以内に当局へ報告するという、非常に厳しい水準が要求されています。何らかのライブラリやコンポーネントに脆弱性が発覚するたびに、Log4Jのときのようなことをしていては、対応をする現場はとても耐えられないでしょう。その作業を効率化するためにもSBOMを活用し、スピーディに脆弱性を管理していくことが求められています。
――業界別に見ると、動きに差はあるのでしょうか？
藤原氏：自動車と医療という二つの分野で、特にSBOM導入の検討が進んでいるように思います。
自動車産業では、UN-R155というサイバーセキュリティに関する国連規則が2021年に発行されました。ISO/SAE 21434という国際標準規格を参照してサイバーセキュリティ対策を進めるよう求めており、そのISO/SAE 21434では、「継続的サイバーセキュリティ活動」に取り組むよう定められています。直接SBOMという言葉こそないものの、SIRTの活動を進める中でSBOMは有効です。
こうしたグローバルな動きを受けて、JASPARやJ-Auto-ISACといった国内の自動車業界の団体でも、自動車業界におけるSBOMのベストプラクティスをどうまとめていくべきかという議論がなされています。
株式会社ベリサーブ サイバーセキュリティ事業部 脆弱性マネジメント課 藤原洋平 氏
医療業界では、大阪急性期・総合医療センターで発生したサイバー攻撃をきっかけに、セキュリティ対策の機運が一気に高まりました。厚生労働省（厚労省）では国際医療機器規制当局フォーラム(IMDRF)のガイダンスを受けて「医療機器のサイバーセキュリティ導入に関する手引書」を発行しており、この中で、医療機器の製造販売者に対し、SBOMを作成して脆弱性管理を行うよう求めています。
猪俣氏：私自身、大阪急性期・総合医療センターの事案に関わりましたが、やはりあの事故をきっかけに厚労省はサイバーセキュリティへの取り組みをとても積極的に取り組むようになりました。やはり事故が起きると問題の深刻さに気づき、頑張れるだけ頑張りましょうというベストエフォートではなく、政府が法制度を整備していく流れになっています。
以前から医療機器については厳しい認定制度がありましたが、あくまで品質面に関する認定であり、サイバーセキュリティに関してはあまり考慮されておらず、かえってソフトウェアアップデートによって認定の取り直しなどが必要になる状況でした。しかし新しい制度では、医療機器ベンダーとその機器を使う医療現場においてきちんとSBOMを使ってソフトウェアの情報を記録し、管理していこうという枠組みが整備されつつあります。
医療現場では、私の好きな古いコンピュータだけでなくレガシーなソフトウェアがまだたくさん動いています。高価な機器も多いため、そう簡単に買い換えができないわけです。SBOMは、そんなレガシーな機器でも、「この機器は古いけれども、今の状況では安全ですよ」とトレースできるようにして、安全を保証していく手段の一つになると思います。これはベンダー側にとっても、ずるずるとサポートを続けるのではなく、EOL（End of Life）を明示できるという意味で、メリットになると思っています。
ただ、特に私たちが普段お世話になるようなクリニックなどの小規模な医療機関では、やりたくてもなかなかできないこともあるでしょう。診療報酬制度の改定を通して、デジタル化やSBOMのようなサイバーセキュリティ対策を施したのなら診療報酬を加点する、といった形で支援していく必要もあると思います。
広がるSBOMの適用分野、「手引」を参考に第一歩を
――今後、自動車や医療以外の業界でもSBOMは広がっていくでしょうか？
猪俣氏：事故が発生したら社会的インパクトの大きい分野であれば、対応が求められると思います。もともと厳しいソフトウェア管理の考え方を持っていた、お金が関わる業界はその一つでしょう。
私が気になっているのはQRコード決済の分野です。大小様々な決済システムがありますが、基本的に独自の仕様に基づいて開発している中で、コンポーネント管理は本当に大丈夫なのかが問われていくと思います。しかもこうした決済手段は、互いに乗り入れたり、地域通貨として活用される場面も増えています。もし事故が起これば、この分野でも、SBOMを用いて「うちはこういう形でソフトウェアを管理しています」と示すよう求められるかもしれません。
――すべての領域に適用されるものでもないのでしょうか。
猪俣氏：やはり自動車や医療、それに金融のように、国や業界が法制度やガイドラインをきっちり整備している業界では、SBOMによる管理が浸透していくと思います。
一方で、管理されるソフトウェアの大部分を占めるオープンソースコミュニティの分野というのは、開発者の自発的な意思や信頼関係に基づいてコミットしていくものですから、SBOM的な厳密な管理とはあまりそぐわないかもしれませんね。オープンソースコミュニティも反発とまではならないとは思いますが、いちいち管理されるのは嫌だなと思われるかもしれません。
――となると、SBOMは決して万能薬ではないわけですね。
平山氏：バズワード気味になっていますが、SBOMは決して銀の弾丸などではありません。言ってしまえばただの部品表です。部品表の概念自体は、ハードウェアのもの作りの世界では昔からありました。そのソフトウェア版だと捉えると、技術的に何か目新しいものがあるわけではありません。ただ、製造業の精緻なものづくりにも共通する原理原則の部分は非常にシンプルだと思っています。
――その前提に立った上で、SBOMをどう活用していくべきでしょうか。
猪俣氏：経済産業省では先日、「ソフトウェア管理に向けたSBOMの導入に関する手引」の最新版を公開しました。私も委員として策定に関わっています。
この数年で、SBOMとはそもそもどういうものかについては理解が進んできたと思います。しかし、そのSBOMをどう活用するのかが分かりづらいところがあり、この問題を解決するために最初のバージョンを出しました。その後一年にわたって議論を続け、「どう使うか」をより具体的にイメージできるよう改訂を加えたのが2.0です。
ソフトウェアには必ず脆弱性が出てきますが、脆弱性が出てきたときにどこへエスカレーションし、どう対応していけばいいのかが必ずしも明示されているわけではありませんでした。特にOSSの脆弱性公開時の対応は、非常に難解なことがあります。手引き書の七章では、そんな状況で、どう脆弱性を管理し、対応していけばいいのかを具体的に示しています。自社だけでなく、外部のライブラリを購入してサプライチェーンの中で作られているソフトウェアを想定し、SBOMをどう生成し、使っていくかというケーススタディも書かれているため、「SBOMを使うとこんなことができるんだ」とイメージしやすいと思います。
さらに付録として、SBOMに関するチェックシートも付属しています。このチェックシートは、自己採点して100点を取ってもらうことを目的としたものではありません。あくまで、自分たちは何ができており、何ができていないかを把握する点検表であり、これをベースに自分たちの環境に合わせ、項目を追加したり、修正していっていただければと思います。
――こうしたガイドがあると、活用の一歩は踏み出しやすそうですね。
平山氏：脆弱性がどんどん出てきていますが、今はまだ、それらはサプライチェーンの中で一覧化されていません。一覧化されていないものを見つけられるわけがなく、リスクが高いか低いかも判断できません。
まずは第一歩としてSBOMを管理し、そこを可視化していくべきだと思います。それも、単なる構成管理の台帳として静的に管理するのではなく、ソフトウェア開発のプロセスを反映させて、きちんとサプライチェーン全体を可視化し、運用していくことが重要だと考えています。弊社ではSBOMの構築支援だけでなく、ソフトウェア品質の向上で培ったノウハウを生かして、こうしたSBOM運用管理の課題を解決するためのサービスとして、「SBOM.JP」の提供を開始しました。サプライチェーン全体の安全性を確保し、潜在的な脆弱性をより効果的に管理することができます。
SBOM.JPのダッシュボード画面
猪俣氏：ソフトウェア開発では昔のようなウォーターフォールモデルではなく、効率のよいアジャイルなどのスタイルが取られるようになってきました。設計段階でも常に動的に変化していく中での品質管理は非常に難しく、日本におけるソフトウェア品質技術の開拓者でもあるベリサーブさんのような知見が求められるところです。さらにSBOMのような仕組みが提供されることで、最終的なソフトウェアのアウトプットの品質が非常に上がってくると期待しています。
また、SBOMという自分たちのプロダクトの部品表が、いかに自分たちの信頼性を高めるものかということを、経営者も知らないといけません。そこをよく知らないままでは、経営責任を問われかねません。その意味でSBOMは技術者向けの管理台帳ではなく、自分たちのソフトウェアの中身を保証するデューデリジェンス、品質保証書のようなものであり、自分たちの組織の評価につながるものだと認識いただきたいと思います。
