【要点抽出】ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver. 1.0

ニキヌス

前回まとめたサイバーセキュリティ2023でも述べた通り、国としてSBOM推進に力を入れ始めています。その一環で、この手引きが出たので読んでみました。

https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html

何の本？

SBOMの概要と、SBOM導入のための3フェーズを解説した本です。
経済産業省から出ており、「主にソフトウェアサプライヤーを対象としたもの」「SBOM初級者に向けた内容」とのことです。

構成は？

本文は全54ページです。
SBOM導入プロセスを3つのフェーズに分けて、以下4～6章でそれぞれ解説しています。
また、SBOM自体がまだまだ浸透していない用語だからか、2章のSBOMの概要説明にもかなりのページ数を割いています。

  1. 背景と目的

  2. SBOMの概要

  3. SBOM導入に関する基本指針・全体像

  4. 環境構築・体制整備フェーズにおける実施事項・認識しておくべきポイント

  5. SBOM作成・共有フェーズにおける実施事項・認識しておくべきポイント

  6. SBOM運用・管理フェーズにおける実施事項・認識しておくべきポイント

２．SBOMの概要

このnoteのタイトルで本記事を開いたくらいですから、読者はSBOMについて「ソフトウェアの部品表である」「バイデン大統領がなんかやれと言ってる」あたりの認識はあると思います。
ひとまずその前提で、SBOMのメリット・効果は以下です。

  • ソフトウェアに含まれるコンポーネントの脆弱性の影響分析を短縮

  • コンポーネント管理の工数削減

  • ライセンス違反リスクの低減やライセンス管理工数の低減

  • コンポーネントの問題を早期に特定することで開発生産性が向上

  • ソフトウェアのEOL管理の容易化

そして、SBOMには少なくとも以下の情報を含むべきとされています。

表 2-3 米国NTIAによるSBOMの「最小要素」の定義 より

また、SBOMの作成者について、ソフトウェアコンポーネントのサプライヤがSBOMを作ってくれるのが理想ですが、現状では必ずしもそうではないことも留意が必要です。
つまり、誰も作ってくれない場合は、自分が作ったわけではないサブコンポーネントのSBOMを自分で作らねばならないこともある。ということです。

この他、本書ではSBOMフォーマットの例としてSPDX、SPDX-Lite、CycloneDX、SWIDタグが紹介されていますが、ここでは割愛します。

３．SBOM導入に関する基本指針・全体像

「SBOMを何のために作るのか、目的を最初に考えようね」くらいのメッセージなので割愛します。

４．環境構築・体制整備フェーズにおける実施事項・認識しておくべきポイント

4.1. SBOM適用範囲の明確化

まず最初にやることは、SBOM導入についての5W1Hの整理です。

  • Why
    何のためにSBOMを作るのか(上述のメリットから選択）

  • What、Where
    何の・どこまでの範囲のSBOMを作るのか、何の要素を含むか、何のフォーマットを選択するか

  • Who
    誰がSBOMを作るのか（自組織、契約したサプライヤ 等）、誰がSBOMを活用するのか

  • When
    いつSBOMを作るのか（ビルド時、納入時 等）

  • How
    どうやってSBOMを作るのか（自動、手動）

その整理に必要なインプット情報として以下を洗い出す必要があります。

  • 対象ソフトウェアで使っている開発言語や開発ツール等。
    SBOMツールの選定基準に関わる。

  • 対象ソフトウェアの構成図（※）。
    SBOMの作成範囲に関わる。

  • 対象ソフトウェアの利用者及びサプライヤーとの契約形態・取引慣行。
    SBOMの作成範囲に関わる。

  • 対象ソフトウェアのSBOMに関する規制・要求事項。
    SBOMの作成理由や活用主体に関わる。

  • SBOM導入に関する組織内の制約（体制、コスト等）

※「ソフトウェアの構成図」については、多分、対象システムの構成と読み替えたほうがよさそうです。
「〇〇システムにはaソフトウェアとbソフトウェアがあって、それぞれX社とY社が作ってて…」みたいな全体像をとらえた上で、じゃあこのソフトウェアのSBOMを作りましょう。となるイメージかと思います。

4.2. SBOMツールの選定

有償ツールは高価であり、無償ツールは導入ロードが高い、検出精度が悪い、脆弱性情報とのマッチングができない、等の注意点があります。
それぞれ一長一短であり、明確には書かれていませんが、なんとなく無償ツールはやめとけ的なニュアンスを感じます。
ツール選定時の観点は以下です。

  • 機能
    コンポーネントの解析機能、脆弱性情報・ライセンス情報の自動マッチングや追跡機能、リスクの定量化機能、依存関係や脆弱性情報等の可視化機能、新たな脆弱性が検出された際のアラート機能、アドバイザリー情報の自動レポート機能、SBOMデータのインポート機能等

  • 性能
    誤検出、検出漏れ、新たな脆弱性情報の取り込みスピード

  • 解析可能な情報
    解析できるコンポーネントの情報

  • 解析可能なデータ形式
    対応するファイル形式、パッケージマネージャーの種類、ソフトウェアが動作可能なOS・CPUアーキテクチャ等

  • コスト
    ライセンス費用の算出方法

  • 対応フォーマット
    上述のどのフォーマットに対応しているか

  • コンポーネント解析方法
    後述します。

  • サポート体制

  • 他ツールとの連携
    開発環境、ビルドツール、ソフトウェアバージョン管理ツール、コミュニケーションツール等との連携可否

  • 提供形態
    パッケージ版かクラウド版か。クラウド版ではソースコードの流出につながらないか注意

  • ユーザーインターフェース
    CLIのみかGUIもあるか

  • 運用方法
    SBOMツールを実行するが開発担当者か別の解析チーム的な部隊かにより、重視する機能が変わる

  • 対応するソフトウェア開発言語

  • 日本語対応（そもそもまだ少ない）

コンポーネント解析方法は大きく以下の3パターンがあり、SBOMツールはそれらを組み合わせて解析するようです。

  • コードマッチング(完全一致、スニペット、バイナリパターン）
    バイナリパターンの場合、ソースコードがない場合でもバイナリファイルのみで解析できるメリットがありますが、精度はかなり低いようです。

  • 依存関係検出
    この方式が誤検知の可能性が最も低いです。

  • 文字列検出
    ライセンス文字列から解析する方式です。

4.3. SBOMツールの導入・設定
4.4. SBOMツールに関する学習

各SBOMツールの手順に沿って導入したり、使い方を学んでねくらいの内容です。
ただ、ここでも無償ツールについては、経産省が試行した際に苦労したのか、「ツールの構築や設定に関する情報が不足している場合があるため、試行錯誤的に設定を行うための負担を強いられる可能性がある」と強調されています。

５．SBOM作成・共有フェーズにおける実施事項・認識しておくべきポイント

5.1. コンポーネントの解析

解析自体はツールがやってくれますが、その結果見えた様々な「思ってたんと違う」ポイントと、それに伴いアウトプットの精査が必要であることが書かれています。
思ってたんと違うポイントは、例えば以下です。

  • シンボリックリンクやランタイムライブラリ等、実体がSBOMツールのスキャン対象に含まれないコンポーネントは検出されない

  • 下位のコンポーネントに関する検出漏れ率が高い

  • SBOMツールが知らないOSSは検出できない

  • バージョン情報の誤検出がある

  • 解析環境によって結果が異なる

  • パッケージマネージャ（npmなど）と検出結果が異なる

  • 一見SBOMツールが正常終了しているように見えても、エラーで一部の解析をスキップしていることがある

こうした想定外の部分を認識したり補完するためにも人手による精査が必要であり、結構なロードがかかります。
精査の観点は以下の図がまとまっていたのでそのまま紹介させていただきます。

図 5-1 コンポーネント解析結果の確認の観点及び確認方法　より

5.2. SBOMの作成

アウトプットする項目、ファイル形式等の要件を、SBOMの作成目的に応じて決めます。この際の考慮事項は以下です。

  • コミュニティや個人に対してSBOMの提供を依頼すべきか否かについては、契約やライセンスの問題があることに注意

  • 第三者から提供されたコンポーネントを自組織にて改変して使用している場合は、提供を受けたSBOMをそのまま利用できなくなることに注意

  • SBOMの作成日時は記録すること

  • プロジェクト名称等の情報について、SBOM利用者が活用しやすい名称とすること

5.3. SBOMの共有

前提として、SBOMの公開は必須ではなく、サプライヤが判断可能です。
その上で、SBOMを公開・共有すると判断した場合は、共有先との関係を踏まえて以下を考える必要があります。

  • 共有相手が受け取れるフォーマットに指定があるか（同じクラウド型のSBOMツール同士なら簡単なことが多い）

  • どこにSBOMを公開するか
    製品内に組み込むリポジトリに公開、Webページ上で公開、SBOMツール間での共有　等

  • SBOMの改ざん防止方法（電子署名等）

６．SBOM運用・管理フェーズにおける実施事項・認識しておくべきポイント

6.1. SBOMに基づく脆弱性管理、ライセンス管理等の実施

SBOMは作って終わりではなく、脆弱性管理やライセンス管理に使って初めて役立ちます。
脆弱性管理の方法は、特にSBOMに限った話ではなく、一般的なリスク評価と同様ですのでここでは割愛しますが、脆弱性情報とのマッチングを手作業でやるのは非現実だから、そういう機能を持つSBOMツールを使った方がよいとあります。
注意点として、上述の通りSBOMツールのコンポーネント解析結果には誤りが含まれる場合があるため、脆弱性情報にも誤りがありえる前提で確認が必要です。

6.2. SBOM情報の管理

サービスの提供期間、サポート期間等を踏まえてSBOMの保存期間を決定します。
SBOMの管理は、組織内のPSIRTが望ましく、それがない場合は品質管理部門が良いとのことです。

感想

本書は実際にSBOMツールを触ってみた人の目線での気づきが多く含まれており、これからSBOM検討に取り組む組織には有用かと思いました。

SBOMツールは「何も分かってなくてもひとまず実行すればいい感じに解析してくれる」魔法のアイテムと期待しがちですが、実態は結果が不完全であり、精査が必要であるなど現実的な部分がよく分かりました。
その意味で、SBOMツールを使うにしても、結局は対象システムの構成をしっかり説明できる人が必要という点は重要なところかと思います。
また、組織が持つすべてのソフトウェアに対してSBOMを作ると膨大な手間がかかりますから、そもそもどのスコープを対象にするのかをしっかり考えてから取り組む必要があります。

こうしたSBOMの不完全さ、精査の手間を考えると「SBOMツール、全然使えないのでは？」と考えてしまうのですが、そのくらいの精度であっても手動で管理するよりははるかに早く、他に効率よく部品表を作る方法はないのだから精査しながら頑張るしかない。という考えかと思います。
とはいえ、ツールの検出精度の向上を期待したいですね。

＊＊＊はじめての方へ＊＊＊
これは何のnoteだ？と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら

この記事が気に入ったらサポートをしてみませんか？