はじめに

こんにちは。先日、社内にてSBOMに関する勉強会を行いました。この記事では、そこで学んだことを解説していきたいと思います。
具体的な内容は以下の通りです。

• SBOMとは何か
• SBOMを導入するとどんなメリットがあるか
• SBOMを導入するにはどんなことに気を付けて何をすれば良いか
• SBOMにはどんな種類があるのか

特に、SBOMに興味はあるけど具体的に何していいかわからない、という方に参考になると思っています。少々長いですが、最後まで読んでいただけると嬉しいです。

それでは、順番に説明していきます。

SBOMとは

SBOMとは、ソフトウェア部品表(Software Bill of Materials)、つまり、ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リストのことです。

ソフトウェアに含まれるコンポーネントの名称やバージョン情報、コンポーネントの開発者等の情報が含まれ、OSS だけではなくプロプライエタリソフトウェア（商用ソフトウェア、ライセンス料を払って使用するもの）に関する情報も含めることができます。

SBOMをソフトウェアサプライチェーンの上流から下流に向かって組織を越えて相互共有することで、ソフトウェアサプライチェーンの透明性を高めることが期待されていて、特に、コンポーネントの脆弱性管理の課題に対する一つの解決策として期待されています。

SBOMに必要な要素

アメリカでは、2021 年 5 月の米国大統領令を受けて、2021 年 7 月にNTIA(米国商務省電気通信情報局(National Telecommunications and Information Administration))から SBOMの「最小要素」の定義に関する文書が公開されました。。NTIA が定める「最小要素」の定義にはSBOMに含めるべき情報についてのカテゴリーである「データフィールド」だけではなく、SBOMを導入する組織が考慮すべきカテゴリーとして、「自動化サポート」・「プラクティスとプロセス」のカテゴリーも規定されています。

SBOMの利活用においては、コンポーネントに関する情報を収集し、一貫性のあるデータ構造を確立することが必要不可欠です。

データフィールドのカテゴリーでは、SBOMの対象となるコンポーネントを一意に特定するための情報を含めることが「最小要素」として位置づけられています。各項目の詳細について、下の表にまとめました。

具体的なデータフィールドの定義は対象となるコンポーネントの名称やバージョン、その他の識別子に関する情報だけでなく、当該コンポーネントのサプライヤー及びSBOM作成者の名称、コンポーネントの依存関係及びタイムスタンプに関する項目が含まれます。

SBOMを導入するメリット

SBOMの導入には以下のようなメリットがあります。

脆弱性管理のメリット

最も注目されているのが脆弱性管理のメリット、つまり、ソフトウェアにおける脆弱性を検出し、優先度付けを行った上で修正及び軽減するといった一連の脆弱性対応プロセスにおけるメリットです。

近年のソフトウェアの多くは複雑なサプライチェーン構造の下で開発され、自社で開発したプロプライエタリソフトウェアだけでなく、他社や OSS コミュニティが開発したコンポーネントも多く含み、これらのコンポーネントが複雑な階層構造や依存関係を持つことが多いです。

そのため、下位のコンポーネントに脆弱性を含んでいた場合であっても、セキュリティ上の影響を受ける可能性があります。

脆弱性残留リスクの低減のためには、利用しているコンポーネントに関する情報に基づき、脆弱性を継続的に監視することが重要です。

ここで、SBOMを導入していれば、あるコンポーネントにおいて脆弱性が明らかになった場合に、その脆弱性の影響を即座に認識することができ、脆弱性対応にかかる期間を短縮できます。

さらに、パートナー企業、脆弱性の影響を受ける組織、ソフトウェア利用者等とソフトウェアに関する情報を組織間で共有することで、脆弱性対応にかかる期間を短縮できます。また、サプライチェーン上で第三者によりコンポーネントの書換えや不正な追加が行われた場合にも、その実態把握に役立ちます。

組織間で情報を共有にあたってSBOMを活用することで、ソフトウェア情報の共有に必要な工数を削減できます。

例えば、SBOMツールによって、コンポーネントの解析・特定を自動で行うことが出来ます。さらに、ツールによっては、新たな脆弱性が明らかになった場合、SBOMツールに自動で反映され、その影響をリアルタイムに特定できるため、解析・特定結果に関する確認は必要となりますが、脆弱性管理にかかるコストを大幅に削減できます。

経産省の調査では、手動での脆弱性管理と比較して、必要な工数が30%程度に削減できました。

このコスト削減効果は、対象とするコンポーネント数が多ければ多いほど、大きくなるため、より大規模なソフトウェアほど、SBOMを導入するメリットが大きくなります。

副次的な効果として、製品価値や企業価値が向上するほか、脆弱性の少ない製品が増えることで、サイバー空間全体のセキュリティが向上にもつながります。

ライセンス管理上のメリット

2つ目は、ライセンス管理上のメリットです。これは、ソフトウェアに含まれるコンポーネントのライセンスを識別し、各ライセンスの要求事項に従った対応をするという一連のプロセスにおけるメリットのことです。

近年のソフトウェアの多くは OSS を含んでいますが、OSS のライセンスに違反した場合、ソフトウェアの販売停止や回収、罰金の支払い、企業ブランドイメージの低下等、大きな影響を受ける可能性があります。

実際に、海外ではOSS ライセンス違反による訴訟事例が複数存在します。

そのため、OSSを利用する場合は自らの責任ですべての OSS のライセンスを確認し、それぞれのライセンスに準拠する必要がありますが、OSSのライセンス情報を抜け漏れなく管理することは簡単ではありません。

SBOMの導入によりライセンス情報も含めて各コンポーネントを管理することで、ライセンス違反のリスク及びライセンス管理にかかるコストを低減できます。

開発生産性向上のメリット

3つ目のメリットは、ソフトウェア開発ライフサイクル（SDLC）が改善し、開発生産性が向上することです。

ソフトウェア開発初期段階からSBOMを生成することで、コンポーネントに含まれる既知の脆弱性やライセンスの問題等のコンポーネントに関する問題にあらかじめ対応できます。

このように、早期に問題個所を特定することで開発遅延の発生防止やそれに対する対応コストを減らすことが出来ます。

他にも、社内で利用が承認されたコンポーネントの情報をSBOMとして管理しておくことで、次回以降の開発で、同じコンポーネントを使用する際に毎度コンポーネントを調査・承認する必要がなくなり、開発工数を低減する効果も期待できます。

Linux Foundation が 2021 年の第3 四半期にグローバルの 412 の組織を対象に実施した調査によれば、回答組織の 51%が「開発者がより広範で複雑なプロジェクト間の依存関係を理解しやすくなる」ことを挙げており、これは脆弱性管理のメリット（同 49%）やライセンス管理のメリット（同 44％）より高い割合となっています。

また、上記の表には記載していませんが、ソフトウェアの EOL管理が容易になるといったメリットもあります。

デメリット

当然ですが、SBOMツールの環境整備やツールの学習のための工数が必要です。例えば、今この記事を読んでいる時間の事ですね。

これらのメリットデメリットを踏まえて、SBOMを導入するにあたって、考慮しなければならないことについて、次の項目以降で説明していきます。

SBOM導入の流れ

ここからは、実際に、SBOMを導入する場合に、どのような手順で導入すれば良いのか、また、どのような事に留意する必要があるのかを説明します。

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

SBOM導入にあたっての基本的な指針

SBOM導入にあたって最初に決めないといけないのは以下の2点です。

• SBOMを作成するソフトウエアの範囲を決定する
• SBOMを用いて解決したい組織課題と導入目的の明確化をする

これらによって、どのSBOMツールやフォーマットを利用するのが最適かが変わってきます。

例えば、巨大なシステムなら有償のツールを使う必要があるかもしれませんし、逆にとても小規模なソフトウェアならなら、ツールを使わずに手作業でSBOMを作成するのがベストかもしれません。

SBOM導入プロセス

SBOM導入までのフェーズはざっくりと3つのフェーズに分けることが出来ます。

環境構築・体制整備フェーズ・SBOM作成・共有フェーズ・SBOM運用・管理フェーズ

各フェーズにおける実施事項・認識しておくべきポイントを以下で説明していきます。

環境構築・体制整備フェーズ

SBOM導入に向け、まずはSBOMに関する環境・体制を整備する必要があります。

SBOM適用範囲の明確化

まずは、適用範囲明確化のための以下の情報を整理します

• SBOMの対象のソフトウエアに関する情報の整理観点
  • 開発言語、コンポーネントの携形態、開発環境ツール、ビルドツール、構成管理ツール、動作環境
• ソフトウエア構成図の作成
• SBOMの対象コンポーネントの範囲を明確化するための対象ソフトウエアの利用者及び、サプライヤーとの契約形態、取引慣行を整理
  • 契約形態、コンポーネント情報の提供、第三者コンポーネントの申告、脆弱性の通知、脆弱性の修正、納品携帯、損害賠償責任、知的財産権の貴族、改変の有無
• SBOMに関する規制・要求事項の確認
• 組織内の制約の明確化(体制の制約、コストの制約)

整理した情報を加味して、SBOMの作成主体、作成タイミング、活用主体、コンポーネントの範囲、作成手段、活用範囲、フォーマット・項目を、決める必要があります。

SBOMツールの選定

SBOMツールを比較・選定する際は、以下のような方針で評価観点を決めると良いです。

• 目的に対して最小限であること
• 有償ツールは高価であるが無料版(OSSなど)は環境整備や学習コストが高い
  • 無料版は場合によってはOSSのサポートをしてくれる企業との連携などが必要
• SaaS版は情報の利用用途に関して規約を確認すること
• 既存の開発プロセスへの組み込みが容易であるツールを選定すること

上記ポイントを考慮して、機能、性能、解析可能な情報、データ形式、コスト、対応フォーマット、コンポーネントの解析方法、サポート体制、インタフェース、運用方法などの観点で、SBOMツールを評価して比較します。

SBOMツールの導入・設定

SBOMツールを導入する時は、SBOMツールが導入可能な環境要件を確認し、必要に応じて整備します。

例えば、対応OSや実行環境、マシンスペックが足りているか、などを確認する必要があります。

基本的に、取扱説明書やREADMEファイルに導入・設定手順がありますので、そこを確認して導入、設定を行います。

この時、SBOMを脆弱性管理に活用する場合、障害でSBOMツールが停止し、検知が滞ることが無いようにSBOMツール自体の稼働監視やデータを定期的にバックアップするなどの対応も必要です。

SBOMツールに関する学習

取扱説明書やREADMEファイルを確認して、SBOMツールの使い方を習得します。

ツールの使い方に関するノウハウや各機能の概要は記録し、組織内で共有したほうが良いです。

SBOM作成・共有フェーズ

子のフェーズは、構築した環境や体制に基づき実際にSBOMを作成し、必要に応じてSBOMを提供するフェーズです。

コンポーネントの解析

まずは、SBOMツールを用いて対象ソフトウェアのスキャンを行い、コンポーネントの情報を解析します。

SBOMツールを利用することで、ソフトウェアを効率的に解析できるため、以降はSBOMツールを使用している前提で説明します。

次に、SBOMツールの実行結果を調査し、エラー発生や情報不足による解析の中断や省略がなく、解析が正しく実行されたかを確認する必要があります。

一見解析完了しているように見えても途中でエラーになっている可能性もあるので、実行時のログなども確認する必要があります。

最後に、コンポーネントの解析結果について、コンポーネントの誤検出や検出漏れがないかを確認する必要があります。

ツールでのコンポーネントの解析は、誤検出や検出漏れが起きる可能性があります。そのため、完全に正確なSBOＭを作成するにはツールでの解析後、人力で確認する必要があります。

この解析精度は、ツールの解析方法によって差が出ます。依存関係検出は精度が高く、バイナリスキャンは精度が低いです。コードマッチングや文字列検出はその中間です。ツールによって利用できる解析方法が異なるので、利用するツールの解析方法を確認してください。

ただし、人力での確認作業は工数が多くかかるため、けっきょくのところ、正確性と工数のトレードオフとなってしまいます。

SBOMの作成

解析したコンポーネントの情報をもとにSBOMを作成します。

環境構築・体制整備フェーズで決めたSBOMの項目、フォーマット、出力ファイル形式等のSBOMに関する要件にそって、SBOMツールを用いてSBOMを作成します。

第三者から提供されたコンポーネントを使用している場合は、当該コンポーネントのSBOMの提供を受け、効率的にSBOMを作成することができるかもしれませんが、そのコンポーネントを改変している場合など、そのまま利用できないこともあります。

SBOMの共有

SBOMの共有は必ずしなければならない、というわけではないですが、ソフトウェアサプライチェーンの透明化のために、作成したSBOMをソフトウェアの利用者や納入先に共有した方が良いです。

この時、共有先が利用するSBOMツールによっては共有方法を検討する必要があります。

SBOMの作成者と利用者が同じSBOMツールを利用している場合は、たいてい簡単な共有手段が提供されていますが、異なる場合は、どのようなSBOMの内容・フォーマットをどのような方法で共有することが出来るかあらかじめ調査しておく必要があります。

例えば、以下のような共有方法が考えられますので、それぞれの方法の長所短所を踏まえて検討する必要があります。

• 利用者がアクセス可能なリポジトリにおいて公開する
• Webページ上で公開する
• 共通のSBOMツールを導入しSBOMツールを用いて共有する

SBOM運用・管理フェーズ

SBOMはあくまでソフトウェア管理の一手法であるため、作成することが目的ではなく、SBOM
を用いて適切なソフトウェア管理を行うことが重要です。そのためには、SBOMを作成して終わりではなく、SBOMの運用・管理について考慮する必要があります。

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

SBOMのメリットのところでも書きましたが、SBOMがソフトウェアの運用で役立つのは、主に、脆弱性管理とライセンス管理についてです。

脆弱性管理については、脆弱性マッチングの機能があるSBOMツールを利用すると、脆弱性に関する情報を出力できるので、その結果を踏まえ、深刻度・影響度の評価、脆弱性の修正、残存リスクの確認、関係機関への情報提供などの脆弱性対応を行う必要があります。ソースコードだけでなく、ドキュメント類の修正範囲の特定も必要です。

ライセンス管理については、ツール次第ではありますが、SBOMツールがライセンスに関する情報を出力できるので、出力結果を踏まえ、OSS のライセンス違反が発生していないかを確認できます。

コンポーネントの解析の時と同じく、ツールも絶対ではなく、SBOMツールが出力した脆弱性情報やライセンスに関する情報が誤っている場合もあり、最終的には出力結果を確認する必要があります。

SBOM情報の管理

作成したSBOMは、社外からの問合せがあった場合等に参照できるよう、変更履歴も含めて一定期間保管・管理してください。

SBOMの対象としたソフトウェアの内容が動的に変わるほか、脆弱性の情報も日々更新されるので、SBOMに含まれる情報も定期的に更新し、管理する必要があります。自動で脆弱性情報が更新・通知されるSBOMツールもあるので、そのようなツールを利用すると、効率的にSBOMの管理が出来ます。

SBOMの管理をする管理体制については、脆弱性管理を現在行っている部署(例えばPSIRT(Product Security Incident Response Team(製品セキュリティ担当部門)など) が対応すると効果的です。

SBOM仕様

SBOMという文書のフォーマットは複数の団体がそれぞれ定めているため、SBOMにはいくつかのフォーマットがあります。

主なフォーマットについてざっくりと説明します。

各フォーマットの使用目的や実際の項目など、詳細な比較については、別記事にて投稿予定ですので、よろしければそちらも読んでいただけると嬉しいです。

Cyclone DX

• 提供元
  • OWASP
• 特徴
  • 2017 に OWASP dependency-track(オープンソースのSCAツール) の為に開発
  • 主な使用用途として設計されていたのは脆弱性の特定、ライセンス準拠、古いコンポーネントの分析
  • 現在は 1.5 (2023/06/26) が最新版
  • セキュリティ管理を念頭に置いたSBOMフォーマット
  • 体系立てられたオブジェクトモデルであるため、学習と導入が容易
  • 開発エコシステムと統合して自動化を実現
  • 仕様の拡張が可能であり、要件に応じた新しい機能を試行できる

SPDX（Software Package Data Exchange）

• 提供元
  • Linux foundation
• 特徴
  • 2021年「ISO/IEC 5962:2021」として国際標準化
  • ソフトウェアがライセンスをあいまいさなく判別できるようにSPDX-Identifyを定義
  • 2010年から開発が継続している：現在3.0
  • SBOM作成対象となるソフトウェアとして、スニペットやファイルにとどまらず、パッケージ、コンテナ、OSディストリビューションまで拡張可能
  • SBOMドキュメントとして作成された成果物は、提供されたハッシュ地を使用することでSBOM化データ改ざん有無を検証することが可能
  • 知的財産とライセンス情報のための豊富なリスト（SPDXライセンス）を持つ
  • 他のパッケージ参照システムやセキュリティシステムと連携することが可能
  • 複雑なシステムに関連するドキュメントを論理的に分割し、SBOMドキュメントの各セクションや項目で管理することが可能

SWID (Software Identification) Tags

• 提供元
  • NIST (National Institute of Standards and Technology)
• 特徴
  • ソフトウェア開発者がソフトウェアの各コンポーネントに付与するタグであり、インストールされたソフトウェアを追跡してライセンス管理やパッチの管理が可能
  • ソフトウェアライフサイクルに合わせて各タグの情報を更新するため、ビルド時に作成されるソフトウェア
  • ID の情報を正確にタグへ付与して提供することが可能
  • ソフトウェアのインストール時に、サプライヤーと利用者の間で交換可能なソフトウェア情報を標準化
  • 関連するパッチやアップデート、構成設定、セキュリティポリシー、脆弱性や脅威の勧告等、ソフトウェアに関連する情報の関連付けが可能

SPDX-Lite

上の3つほどメジャーではないですが、日本発のSPDXのサブセットがありますので、紹介します。

• 提供
  • LF OpenChain Japan Work Group
• 特徴
  • SPDX のサブセットとして作成
  • 最新版は SPDX 2.3 をベース
  • SPDX と比べて必要最低限の項目のみが含まれているため、運用性を重視したSBOM管理が可能
  • SPDX の「SBOMドキュメントの情報」と「パッケージ情報」のセクションに分類される必須項目を含んでいるため、SPDX に対応したSBOMツールと親和性が高い
  • SPDX-Lite 形式のSBOM作成に当たって、専用のツールは必要なく、手動でSBOMドキュメントを作成することが可能

終わりに

いかがでしたでしょうか。今回は、主にSBOMのメリットや導入する際の注意点などについて、まとめました。

SBOMフォーマットの詳細や、いろんなSBOMツールの使い方など、SBOMに関するブログを、今後も投稿していく予定ですので是非読んでみてください。

最後までお読みいただきましてありがとうございました。

参考資料

• https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html
• https://www.meti.go.jp/press/2023/07/20230728004/20230728004-1-2.pdf