[SBOMツール連載 Part.1]SBOMツールとは（基本機能、分類、選び方など）

2023年の間に「SBOM」って何回言ったかなぁ、なんてボーっと考えている渡邊です。

自分の名前でも日常会話で使う言葉でもない特定の用語にここまで翻弄される日々が来るとは、人生ってわからないものですね。ということで、どうせならもっと浸ってやろうじゃないか2024年。SBOMツール連載を始めてみることにしました。

SBOMツールとは

世の中にはさまざまなSBOMツールが存在します。 当社が取り扱っているような有償のSBOMツールもあれば、OSSで公開されている無償のSBOMツールもあります。 たくさん種類があるけれど、いったいどれを使えばいいのだろう？と悩んでいる方も多いのでは。 今回は、そもそもSBOMツールを選ぶにあたって重要な「解析機能」の種類について述べていきます。

SBOMツールの基本機能

SBOMツールの基本的な機能は、解析、分析、レポートの3種類に分類されます。

• 解析機能

  解析機能とは、対象物（ソースコード、バイナリファイル、コンテナイメージなど）を解析し、内包するコンポーネントを特定する機能です。 SBOMの基礎となる「コンポーネントの一覧」を作成するステップだと捉えてください。 詳しくは後述しますが、ここでおこなう解析のアプローチの違いが、解析結果の解析粒度や曖昧性に影響します。

• 分析機能

  分析機能とは、解析によって得られたコンポーネントの一覧に基づき、各コンポーネントに適用されるライセンスや影響を受ける脆弱性の有無などのリスクを分析・評価する機能です。 公開脆弱性情報を常時監視して、自身のプロジェクトに影響を及ぼす脆弱性があれば通知してくれる機能などもここに含まれます。 ツールごとの特徴が出る部分であり、例えばライセンスの解釈に関する情報を提供するツールがあったり、独自に調査した脆弱性の詳細情報や対策を提供するツールがあったりします。 また、脆弱性のスコアリングやトリアージのやり方も、各ツールがそれぞれ工夫を凝らしています。

• レポート機能

  レポート機能とは、解析および分析の結果を出力する機能であり、レポートはSBOMファイルとしてエクスポートできます。 SPDXやCycloneDX、各ツールの独自フォーマットなどの形式でSBOMを出力できます。

上記以外の機能として、チケット管理システムと連携し脆弱性などのIssueをチケットとして発行することができたり、Gitホスティングサイトと連携しコンポーネントのバージョンアップのプルリクエストを自動生成することができたり、SAST機能を持っていたりと、エンジニアが欲しい機能がたくさん実装されたリッチなツールもあれば、解析機能など特定の機能のみをサポートしているシンプルなツールもあり、自分のやりたいことや目的に合わせて、最適なツールを選定する必要があります。

解析方法の種類と特徴

職業柄、お客さまのSBOMツール選定をお手伝いする機会が多いのですが、意外と皆さんが「わかっていない」ポイントがこの「解析方法の種類」です。 ツールベンダーさんによって異なる名称を使っている場合もありますが、世の中のSBOMツールの解析アプローチは、基本的に下図のいずれかに分類され、ツールによって、「ファイルマッチングと依存関係情報解析とバイナリ解析の機能を備えている」ものや、「依存関係情報解析のみ」のものなどがあります。

現在のように高性能なパッケージマネージャーが存在しない頃からある、歴史のあるSBOMツールは、「ファイルマッチング」や「スニペットマッチング」の解析方法をサポートしています。 これらは、ファイルそのものやソースコードの一部分の識別情報（ハッシュ値のようなもの）を利用してOSSの検出をおこなう方法で、曖昧性を含んではいるものの、特に粒度の細かいマッチングをおこなうことができる点が特長です。 また、開発言語やパッケージマネージャーの種類に依存しない解析ができるため、汎用性が高いと言えます。
（ファイルマッチングやスニペットマッチングができるツールの例：Black Duck、Mend社のソフトウェアコンポジション解析ツール、FOSSIDなど）

ライセンスヘッダマッチングは、ソースファイルに書かれているライセンスヘッダを文字列検索する手法で、ライセンスコンプライアンス遵守の目的で使用されます。 ほかの解析方法とは違い、得られる結果は「含まれているOSSライセンスのリスト」であり、「コンポーネントのリスト」ではないため、この解析方法だけではSBOMを作成することはできません。
（ライセンスヘッダマッチングができるツールの例：FOSSologyなど）

依存関係情報解析は、昨今の無償SBOMツールの多くが採用している方法で、パッケージマネージャーの設定情報からOSSコンポーネントを特定します。 検知の曖昧性が低く（≒誤検知が少ない）、実用性が高い一方で、サポートされているパッケージマネージャーを使用していない場合は使用できません。
（依存関係情報解析ができるツールの例：FOSSA、Snyk、Microsoft SBOM tool、Trivyなど）

SBOMツールの選び方

解析方法の種類や特徴を理解したうえで、どうやってツールを選べばいいかというと、まずは対象物（ソフトウェア）が「パッケージマネージャーを使用しているか」が最初の観点になります。 Node.jsベースでnpmを使っているとか、Pythonのプログラムでpipを使っているとか、そういう場合であれば「依存関係情報解析」のアプローチがおすすめです。 誤検知ゼロとは言いませんが、ツールを実行するだけでかなり正確なコンポーネントのリストが得られ、SBOMが生成できます。

パッケージマネージャーを使っていない場合は「依存関係情報解析」では満足な解析ができません（解析のヒントになる情報が無いので）。 この場合、「ファイルマッチング」や「スニペットマッチング」ができるツールを選んでください。 特に、ローカルにダウンロードしたOSSを改変して使用しているような場合には、「スニペットマッチング」のアプローチが必須です。

開発を外部に委託している場合で、バイナリファイルしか納品されないケースでは、「バイナリ解析」をおこなうしか手段がありません。 この場合の注意事項として、バイナリ解析は曖昧性が高い（≒解析の精度が低い）ため、あくまで最終手段と捉えていただいて、もしソースファイルが取得可能なのであれば、ファイルマッチングなど、ほかの解析方法を優先しておこなうことをお勧めします。

また、そのほかの注意点として、組織内の各プロジェクトがそれぞれの事情で別々のSBOMツールを選定し利用してしまうと、PSIRTなどの組織による情報の一元管理が難しくなります。 このような場合は、複数の解析方法を備えているツールを採用することで、プロジェクトごとの最適な解析方法の提供と情報の一元管理を両立させることができます。

まとめ

解析方法の違いについてご理解いただけたでしょうか？ SBOMツールの種類がたくさんあってできることや違いがわからない場合は、まず「このツールはどの解析方法をサポートしているのか」から考えてみると、自分のやりたいことにマッチしているかどうかが考えやすくなると思います。 ご参考になれば幸いです。