SBOMの本質を大阪大学 猪俣教授が語る――「うちのソフトは大丈夫なんです」とユーザーにどう証明する？：単なる「技術屋のドキュメント」ではない

大阪大学 情報セキュリティ本部 猪俣敦夫教授がベリサーブのプレスセミナーに「ソフトウェアの視える化により変革する社会システムとどう付き合うべきか」と題して講演した。SBOMは単なる「技術屋のドキュメント」を超え、それによって企業や組織が評価されるべきものではないかと考えているという。

[宮田健，＠IT]

　2024年9月5日、検証／品質向上支援サービスを提供するベリサーブは、ソフトウェアサプライチェーン管理パッケージ「SBOM.JP」を10月から提供開始することを発表するとともに、注目度が高いSBOM（Software Bill of Materials、ソフトウェア部品表）に関して国内外での動向を解説するプレスセミナーを開催した。大阪大学 情報セキュリティ本部 猪俣敦夫教授が「ソフトウェアの視える化により変革する社会システムとどう付き合うべきか」と題してSBOMがビジネスをどう変革していくかを語った。本稿では講演内容を要約する。

大阪大学 情報セキュリティ本部 猪俣敦夫教授

食品の内容物表記は当たり前だが、ソフトウェアは？

　大阪大学で猪俣敦夫教授は、サイバーメディアセンター 副センター長、大学における情報セキュリティ対策室室長、そしてOU-CSIRT（Osaka University-Computer Security Incident Response Team）の隊長を務めている。かつては大阪急性期・総合医療センターにおけるインシデント調査委員会の委員長を務めていた。

　SBOMは医療業界でも注目されており、猪俣氏はオフェンシブセキュリティの視点からも、既に利用しているソフトウェアには脆弱（ぜいじゃく）性が存在するという前提に立つ。そして、攻撃者の視点を基に防御する必要性を語る。

　猪俣氏はまず、お菓子や食品などの内容物表記を例に出す。特に海外ではこれらの表記を基に有害性をチェックしているが、普通の人が成分表を見ただけでは理解できない。欧州ではフランスを中心とした6カ国で「Nutri-Score（ニュートリスコア）」という、A〜Eの5段階の栄養スコアがあり、利用者に取っての判断基準になるよう導入が進んでいる（参考）

　原材料がトレースできることによって安全性を判断できる――それと同じことを“ソフトウェア”で行うのが、SBOMだ。特にオープンソースソフトウェア（OSS）のライブラリやコンポーネントは、多くの関係者が集まって作られている。小さなかたまりがたくさん組み上げられることで巨大なコードが出来上がるので、「お金を払って導入する製品やパッケージよりも複雑だ」（猪俣氏）

Log4jやXZ Utilsでも――脆弱性やバックドアを見つけるのは相当大変だ

　ソフトウェアは作り込みの中で、必ず不具合や脆弱性が存在する。その組み合わせであるライブラリやコンポーネントの依存関係、サプライチェーンの関係が複雑化しており、どこかのタイミングで混入した脆弱性が、ソフトウェア製品や成果物のどこまで影響を及ぼすのかを把握するのは非常に難しい。

　2021年12月に大きな衝撃となった「Apache Log4j」に関連する脆弱性（CVE-2021-44228）の対処が長引いていたことも記憶に新しく、その対応は「長距離マラソンのようなもの」とも表現されている（参考）。

　猪俣氏は加えて、ファイル圧縮ツール「XZ Utils」の脆弱性（CVE-2024-3094）における問題の根深さについて言及する。

　このツールは多くのメンテナーがボランティアで管理するOSSとして運営されているが、そのメンテナーの一人が2年近くOSSに貢献して信頼を得たその後に、バックドアコードを難読化し、ひっそりとプログラムに混入させたということが発覚した。コードレビューでも発見されないようにプログラムが巧妙に隠され、たまたま挙動のおかしさに気が付いたために発覚したという、大変危うい事件だ。発覚に至ったいきさつは、発見者がmastodonに投稿している。

　猪俣氏は「バグを見つけるのとは訳が違う。この事例では、“見つからないように作っている”ので発見が難しい。メインのパッケージではなくライブラリの一部に混入しており、ある一定のバージョンのみが影響を受ける。埋め込まれたプログラムがシステムのどこに含まれるのかを判断するのは相当大変だ」と指摘する。

　これを解決するには、食品の成分表や病院の電子カルテのように、中身がどのようなもので構成されているか、さらには時系列で情報がひも付けられた1つの記録が必要だ。それが、SBOMの考え方だ。

ゆりかごから墓場まで……とならないソフトウェア

　猪俣氏は続けて、ソフトウェアは使い続けることができるものの、明確な耐用年数があることを述べる。それは「EOL」（End of Life）や「EOS」（End of Support）で表され、「xeol」のようなソフトウェアのEOLを検出するツールも存在する。また、PCI DSS v3.2.1（2024年3月31日終了）などのように、基準にも終了時期が設定され最新版へのアップデートが必要だ。自社のシステムにおいて、EOLやEOSを迎えたコンポーネントやライブラリがないかどうかをチェックするためには、自組織だけでなくベンダーの助けも必要となるが、ベンダー自身も追い切れていない場合も多い。

　「顧客に向けて『うちのソフトウェアは大丈夫なんです』『正しい製品なんです』と保証する、何らかの仕掛けが絶対必要になってくる。そこで、自分たちの製品はいまこうなっているという、記録のようなものが提示できれば、それはソフトウェアにおける一種のカルテとして、非常に有効なのではないだろうか」（猪俣氏）

　経済産業省は2024年8月29日、「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0」を公開した（参考）。2023年に公開されたv1.0ではSBOMの定義やその意義などが解説されていたが、v2.0ではそれに加え、SBOMをどう使うか、脆弱性の管理プロセスやエスカレーションに関してより具体的な記述が増えている。「ケーススタディーなどにも触れており、読みやすい内容となっている」（猪俣氏）

　猪俣氏は特に付録として公開されている資料に言及し、「チェックリストとしてxlsxファイルが提供されている。全部チェックが付くことを目的とするのではなく、現状を把握するための点検表として使ってほしい」と評価する。

公開されている「SBOM導入に向けた実施事項チェックリスト」

厚生労働省もSBOM活用に積極的に

　猪俣氏は、SBOMに関しては多くの国で取り組みが進んでおり、欧米での状況を把握することの重要性を説く。米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が主催するイベント「SBOM-a-Rama」では、医療業界におけるSBOM活用の講演が組まれている。

　日本においても医療業界におけるサイバーセキュリティ対策が強化されつつある。それは猪俣氏もインシデント調査委員会として携わった事故をきっかけとしたものだが「それ以降、厚生労働省も対策に積極的になった」と猪俣氏は明かす。

　医療機器は高価な機械も多く、EOL／EOS後も活用される状況から、国際医療機器規制当局フォーラム（IMDRF）から「医療機器サイバーセキュリティのためのソフトウェア部品表の原則および実践」という文書が公開され、これを厚生労働省が翻訳し公開している。その中では、医療機器製造業者とヘルスケアプロバイダー（医療現場）におけるSBOM活用のフレームワークが明記されている。

　「レガシーを保障する上で、SBOMの記録を使って『確かに古いが安全なものとして使われている』と言えるようなドキュメントを、証明書の一つとして使う。このような部分でもSBOMの意味はあると考えている」（猪俣氏）

「医療機器サイバーセキュリティのためのソフトウェア部品表の原則および実践」に記載されたSBOMフレームワーク

GitHubでもSBOMフォーマット一つ、SPDXでエクスポートできる

　なおSBOMは幾つかのフォーマットがあるが、いまではGitHubでも依存関係グラフをSBOMフォーマットの一つ、SPDX（System Package Data eXchange）でエクスポートできる（参考）。

　このように官民が活用を推奨しているSBOMについて猪俣氏は「デューデリジェンス（Due Diligence：当然の努力）だ」と考えているという。

　「SBOMは利害関係者、ソフトウェアのライセンス、使用権利といったものに活用されるべきだと考えている。これまでSBOMはソフトウェアの単なる仕様説明書のように捉えていたかもしれないが、自社製品の中身はこのようなもので構成されているといった“品質保証書”になり得る。つまり、SBOMは単なる『技術屋のドキュメント』を超え、それによって企業や組織が評価されるべきものではないかと考えている」（猪俣氏）