■SBOMの概要

SBOM（Software Bill Of Materials）は、直訳では「ソフトウェアの部品表」、もう少しかみ砕くと「ソフトウェアコンポーネントやそれらの依存関係の情報も含めた、機械処理可能なインベントリー」を意味する言葉です。

ひと昔前まで、ソフトウェア製品は自社開発のソースコードのみで構成され、仕様や規格、構造、技術を独占的に保持し、情報を公開していない ものが大半でした。しかし開発の大規模化が進むにつれ、COTS（Commercial Off-The-Shelf）と呼ばれる購入品の利用や、近年ではOSSの活用なども増加しています。

また、サプライチェーンの概念が強いモビリティ業界等では、サプライヤーからの納品物を製品に組み込むケースも日常的ですが、そのサプライヤーでもCOTSやOSSを利用している場合があります（図表1）。さらに、COTSの中にOSSが含まれていたり、あるいはOSSが別のOSSを使っていたりする 可能性もあります。納品物はバイナリ形式で提供されることが多いため、発注側からはブラックボックスになって中身が不明ということが起こり得ます。

自社の製品やサービスに含まれているコンポーネントが把握できていないと、仮に、あるOSSに脆弱性が発生した場合に、影響の特定や対処に多大なコストを費やすことになります。また、OSSにはライセンスが付随するので、意図しないまま利用規約を逸脱して、コンプライアンス違反となる恐れもあります。こうしたリスクを解消するため、製品を構成する部品表を作成するというのがSBOMの考え方です。

SBOMというキーワードが脚光を浴びたのは、冒頭で挙げた2021年5月発効の米大統領令がきっかけで、その中では連邦政府に対するソフトウェアの納品時にSBOMの提出が義務付けられています。また、自動車関連ではサイバーセキュリティに関する法規として、国連からUN-R155/UN-R156がすでに発効されており、ここでも脆弱性管理が重要視されているため、その対策としてSBOMが注目されています。

国内では、経済産業省が「サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理⼿法等検討タスクフォース」を立ち上げていて、自動車と医療機器の2つの分野を先行モデルとして選定、これにソフトウェア分野を加えてSBOMに関する議論や実証実験を行っています。

■SBOMの記載内容とフォーマット

SBOMで最低限記載すべき内容としては、サプライヤー名、OSSのコンポーネント名とバージョン、作成者、依存関係、タイムスタンプなどが挙げられます。また、主要なフォーマットとしてはSWID・SPDX・CycloneDXの3つが広く知られています。図表2は、経済産業省が公開しているレポートからの引用で、SPDXとCycloneDXのサンプルです。

ここからは、実際にSBOMを作成・運用する際の課題と、それを解決に導くための提案をご紹介します。

■事例1　SBOM作成の「粒度」

SBOMにはセキュリティやコンプライアンス対応への活用が期待されますが、いざ作成という時に何をどこまで書くべきかを決めかねると言う話をよく耳にします（図表3）。

一例として、OSSが別のOSSを含むケースを考えてみましょう（図表4）。セキュリティの観点では、OSS AだけでなくOSS Bにも脆弱性が発生する可能性があります。またコンプライアンスの観点では、OSS AとOSS Bとでライセンス形態が異なる場合があります。結論としては、どちらの観点からもOSS BまでをSBOMに記載するべきといえます。

少し迷うのが、OSSを全体ではなく一部分のみ含んでいるケースです（図表5）。こうした場合に、部分流用したOSSまでを記載すべきかどうかは、以前から議論の対象になっています。

私の提案としては、SBOMを使って何を達成したいのかを明確にして、目的に応じた設計を行うべきと考えます。コンプライアンスの観点では、部分的な流用であってもライセンス違反となるリスクがあるため、SBOMに記載することを推奨します。

一方でセキュリティの観点では、部分的に流用したコードにピンポイントで脆弱性が発生する確率はかなり低いと判断することも可能です。一部分ではあっても完全に記載するのが望ましいのは確かですが、やみくもに網羅するのではなく、リスクとコストを考慮して適宜判断していくことが重要です。

■事例2　ツールを活用したSBOM作成

コンポーネントの数が非常に多い場合、手作業でのSBOM作成はかなりのコストが必要になりますが、市場にはSBOMの作成ツールがいくつか存在します。例えばソースコードをスキャンしてOSSを検出するツールでは、ベンダーが世界中のOSS情報を蓄積したデータベースを保持していて、それをスキャン結果と突き合わしてOSSの有無を判別します。

たとえツールを使用しても、以下の説明にあるように抜け漏れや勘違いなどの問題が発生します。そのため、現状では完全自動化は困難で、どうしても手作業でのチェックが必要になることは留意すべきと考えます（図表6）。

ある開発者が、IDE（Integrated Development Environment（統合開発環境））を使ってソフトウェアを作成したとします。最近のIDEは非常に優秀で、必要なソースコードを自動生成してくれます。開発者はそれをOSSとして公開、SBOMツールのベンダーはこの自動生成された部分もOSSとして自社のデータベースに登録します。図表7の赤いパズルのピースが該当部分です。

ここで、別の企業が先ほどの開発者と同じIDEを使ってソフトウェアを開発、その際にやはり一部を自動生成した場合に、全く同じソースコードが作成される可能性があります。これをSBOMツールでスキャンすると赤いピースが検出され、既存のOSSが含まれると判断されてしまいます。実際にはあくまでも自社開発のソースコードで、IDEが生成した赤いピースも流用には当たらないのですが、知らない間にOSSを使っていたのかと勘違いしてしまうようなケースも起こりうるのです。

■事例3　サプライチェーン各社でのSBOM作成

モビリティ業界ではOEMやサプライヤーなど、複数階層でのサプライチェーンが構築されていると思います。脆弱性の管理は個社ごとの対応も必要ですが、サプライチェーン全体で運用・管理しようとする場合にSBOMは大変有効になってきます（図表8）。

ただし、SBOM自体が発展途上にある現段階で、その粒度やフォーマットをs各社で統一するのは非常に困難です。これを打開するためには、SBOMの目的や使用するツール、運用のノウハウなどの情報を非競争領域として共有し、業界全体で考えていくことも必要になると思います。

先述の経済産業省による実証実験の他にも、各種業界団体などでガイドラインの作成や基準の策定が進んでいるので、これらが正式に発行された際には積極的に情報交換していけると良いのではないかと考えています。

■事例4　SBOMのバージョン管理

SBOMは開発過程の過去から現在まで、どの段階のものも任意に参照できるようにしておくことが重要です。特にモビリティ分野では複数のサプライヤーが関わることに加え、欧州や米国などのリリース先によって仕様が異なる、あるいは販売時期によってソフトウェアのバージョンが変わることもあるため、これらを確実に把握、管理するためにSBOM自体のバージョン管理を行うことを推奨します（図表9）。

SBOMの作成方法や記載内容に関する議論が活発化している反面、SBOM自体の管理については二の次になる傾向があるので、そこもしっかり考えていく必要があります。

■事例5　SBOMによる脆弱性対応

SBOMは脆弱性の対応に有効ですが、万能ではありません。SBOMツールを利用した場合には脆弱性情報を明示してくれることもありますが、手作業で追加したコンポーネントに関しては脆弱性とのマッチングが必要で、これには一定のノウハウやスキルが求められます（図表10）。

よくある例として、OSSの名称には「揺れ」があるため、それが原因で脆弱性を見落とすことがあります。またバージョンによって脆弱性の有無や修正パッチのリリース状況が異なるため、うまく特定ができない場合もあります。

図表11は、その具体例です。ピンクの部分はCVE(Common Vulnerabilities and Exposures)による脆弱性の説明で、「1.0.2h and previous versions」、つまり1.0.2hよりも古いバージョンには全て脆弱性が影響するとされています。しかし、下のオレンジ部分にあるセキュリティアドバイザリーの情報には「Affected 1.0.2 to 1.0.2h」、「Affected 1.0.1 to 1.0.1t」と書かれていて、実は脆弱性が影響しない1.0.1uというバージョンが存在していました。現在はこの表記は修正済みですが、過去にはこうした例もあるので、脆弱性のマッチングにはバージョンや表記揺れにも注意していただきたいと思います。

SBOMとは別に、脆弱性の対応状況やステータスを機械処理するフォーマットとしてVEX（Vulnerability Exploitability eXchange）というものがあります。先ほどご紹介したCycloneDXはVEXに対応しており、脆弱性情報をダイレクトに掲載できます。またSPDXでも、備考欄などを活用して脆弱性情報を付与することが可能です。

脆弱性のマッチングをする際には、コンポーネントの名前だけではなく、コミュニティサイトや著作者情報を参照して総合的に判断することが必要です。またツールを使用する場合も、その正確性をきちんと確認することを推奨します。

SBOMの概念と重要性はかなり浸透してきていますが、その実践にはまだまだ課題もあると感じています。今後のSBOM活用に向けては、現在も各国の省庁やコミュニティで活発な議論が行われていますので、本講演もその一助となれば幸いです。