Japan

サイト内の現在位置

SBOMが解決する課題と関連資料の紹介

NECセキュリティブログ
  • Share

2023年4月14日

NECサイバーセキュリティ戦略統括部セキュリティ技術センターの岩田琴乃です。本ブログでは、近年、注目が集まっているSBOM(Software Bill Of Materials) new window[1]の概要・解決する課題・活用による運用上のメリット・関連資料をご紹介します。

1. SBOMとは？

SBOMとは、Software Bill of Materialsの略語で、読み方は「エスボム」です。「ソフトウェア部品表」とも呼ばれます。SBOMは、製品やソフトウェアに含まれるコンポーネントの情報(構成情報)とそのコンポーネント間の依存関係をリスト化したデータです。食品パッケージの裏に記載されている原材料表示のように、ソフトウェアを構成する部品を一覧化したリストをイメージすると分かりやすいでしょう。
SBOMを作成・管理することで、特定のソフトウェアの構成要素に関する情報が可視化でき、ソフトウェアの構成情報管理・組み込まれているコンポーネントのライセンス管理・IT資産管理・脆弱性管理を強化することができます。
特に脆弱性管理では、新たな脆弱性が発見された場合、SBOMに書かれたコンポーネントの依存関係から影響範囲を特定でき、早期対応に繋げることができます。こうした点から、SBOMに取り組む企業が増えています。

図1:SBOMのイメージ

2. SBOMがなぜ重要なのか？

2021年以降、徐々に「SBOM」という言葉を聞く機会が多くなってきました。
ここでは、SBOMが大きく注目されるようになった2つのきっかけから、SBOMの重要性をセキュリティの観点からご説明します。

SBOMが注目されるようになった出来事

〇米国大統領令の中で「SBOM」に言及

数多くのサイバー攻撃や国家レベルのサイバー攻撃の激化を受け、2021年5月12日にバイデン米大統領は大統領令(EO)14028「Improving the Nation’s Cybersecurity」(国家のサイバーセキュリティの改善に関する大統領令) new window[2]に署名しました。そのSection4の「ソフトウェアサプライチェーンセキュリティの向上」では、ソフトウェアの構成要素に関する詳細の開示手段としてSBOMが言及されています。
大統領令が発行された背景には、2020年12月に検知されたSolarWinds社の大規模な情報漏洩事件や、2021年のColonial Pipeline社などの大規模なサイバー攻撃があります。
SolarWinds社の事例では、ソフトウェアサプライチェーン攻撃を受け、組織のネットワーク・端末を遠隔管理できる製品を導入している企業・政府機関が連鎖的に情報漏洩の被害に遭いました。
米国の大手石油パイプライン企業Colonial Pipeline社では、ランサムウェア攻撃を受け一時的に操業が停止するなど、石油の輸送という社会インフラに直接影響を及ぼす出来事がありました。

〇2021年12月:重大な脆弱性「Log4Shell」

広く使用されているOSSの一つであるログ記録ライブラリ「Apache Log4j」に、任意のリモートコードを実行可能な重大な脆弱性「Log4Shell」(CVE-2021-44228)が発見されました new window[3]。「Apache Log4j」は、幅広い業界のサービス・製品で使用されていたことから、多くの企業に影響を及ぼしました。さらに、自社製品で利用しているOSSや他社ベンダーから購入したソフトウェアに「Apache Log4j」が組み込まれているケースがあるなど、企業は「Apache Log4j」が含まれているかの調査に時間を要しました。この「Apache Log4j」の脆弱性が公開されて以降、意図せず脆弱性のあるOSSが組み込まれてしまうリスクについてより強く認識され、自社製品の構成情報を把握・共有するための手段であるSBOMに注目が集まりました。

日本でも脆弱性を悪用した攻撃が課題

日本でも、ソフトウェアの脆弱性を狙った攻撃は依然として課題となっています。IPAが発行している「組織向け情報セキュリティ10大脅威 2023」 PDF[4]によると、2022年に発生した社会的に影響が大きかった脅威ランキングでは、脆弱性を悪用した攻撃が3つ～サプライチェーンの弱点を悪用した攻撃:2位(前年3位)、修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）:6位(前年7位)、脆弱性対策情報の公開に伴う悪用増加:8位(前年6位)～がランクインしています。2位の「サプライチェーンの弱点を悪用した攻撃」には、コード・ライブラリなどソフトウェアの開発の一連のプロセスを指すソフトウェアサプライチェーン攻撃が含まれています PDF[4]。

SBOMの重要性

毎年、数多くのソフトウェア製品の脆弱性が報告されています new window[5]。新たな脆弱性が登場すると、それを悪用した攻撃が予想されます。また、多くの企業がOSSを使用しています。OSSは、ライセンス条件に従えば誰でも使用できますが、公開された脆弱性の対処が必要となるなどOSSの管理が問題となっています。1つでも悪用可能な脆弱性のあるコンポーネントが組み込まれていれば、そのソフトウェアを使用している組織だけでなくサプライチェーン上の関連組織もサイバー攻撃の対象となる可能性が十分考えられます。こうしたソフトウェアの脆弱性を悪用する攻撃を防ぐために、ソフトウェアを構成するコンポーネントを把握・管理し、その情報を基に対策を行うことが必要です。こうした背景から、SBOMの活用が重要視されています。

3. SBOMの中身と活用方法について

NTIAによるSBOMの最小要素の定義

大統領に対して電気通信および情報政策の問題について助言を行う行政府機関であるNTIA(National Telecommunications and Information Administration)は、「データフィールド」・「自動化サポート」・「プラクティスとプロセス」という3つのカテゴリーに分けて、SBOMの最小要素を発表しています new window[6]。

表1:SBOMの最小要素の定義
SBOMの最小要素
データフィールド
(Data Fields)		 SBOMのデータに含める必須データフィールド
  • サプライヤー名(Supplier Name)
  • コンポーネント名(Component Name)
  • コンポーネントのバージョン(Version of the Component)
  • その他の一意な識別子(Other Unique Identifiers)
  • 依存関係(Dependency Relationship)
  • SBOMの作成者(Author of SBOM Data)
  • タイムスタンプ(Timestamp)
自動化サポート
(Automation Support)
  • 相互運用のため、SBOMの自動生成・機械判読をサポートすること
  • SBOMの作成と使用には、SPDX・CycloneDX・SWIDタグを含むデータフォーマットを使用
プラクティスと
プロセス
(Practices and Processes)		 SBOMを使用する組織は、以下の運用方法を定義する
  • SBOMの作成頻度
  • SBOMの深さ(再帰的に特定可能なコンポーネントの情報)
  • 既知の未知(依存関係のあるコンポーネントのうち既知と未知を区別)
  • SBOMの共有
  • アクセス管理
  • ミスの許容

SBOMのフォーマット

SBOMのフォーマットには、主に3種類(SPDX・CycloneDX・SWIDタグ)あります。また、簡易版のSBOMであるSPDX Liteもあります。

  • SPDX
    SPDXは、Software Package Data Exchangeを略したものです。Linux Foundationによって開発されたフォーマットとして、様々なツールで用いられています。SPDXのSBOMファイルは、作成情報・パッケージ情報・ファイル情報・スニペット情報・その他のライセンス情報の検出・コンポーネントの依存関係・注釈情報・レビュー情報のセクションで構成されています new window[7]。
  • SPDX Lite
    企業間で必要な情報を簡単にやり取りできるよう、最小限の必須情報を記述するために開発されたフォーマットです new window[8]。SPDX LiteはSPDXのサブセットとして定義されており、SPDXと比べて必要となるデータフィールドが絞り込まれています。この特徴から、特にスプレッドシート形式（Excelファイル）のSBOMファイルの場合には、人手での読み書きもしやすいフォーマットとなっています。
  • CycloneDX
    Open Web Application Security Project (OWASP)によって開発されたフォーマットです。サイバーリスク削減のための高度なサプライチェーン機能を提供するフルスタックの部品表 (BOM) 標準です new window[9]。CycloneDXのSBOMのデータは、メタデータ情報・コンポーネント情報・サービス情報・依存関係情報・構成情報・脆弱性情報・拡張機能のセクションで構成されています new window[10]。
  • SWIDタグ
    SWIDタグは、Software Identificationタグを略したものです。ソフトウェアの構成要素を識別・管理するための標準フォーマットです new window[11]。SWIDタグは4種類(Corpus Tags・Primary Tags・Patch Tags・Supplemental Tags)あり、ソフトウェア開発ライフサイクルの異なる工程で使用されます PDF[12]。

SBOMの作成の理想と現実

最も理想的な作成方法は、ソフトウェアの各コンポーネントを提供するサプライヤー毎にSBOMを作成・提供し、製品としてソフトウェアを販売するベンダーがそれらをマージしたSBOMを作成することです。しかし、実際は、SBOMを作成しているサプライヤーは少なく、全てのコンポーネントのSBOMを取得することは非常に困難です。したがって、当面の対応の代替手段としては、ベンダーがソフトウェア構成分析(SCA)ツールを用いて、全てのコンポーネントを集約してスキャンを行い、SBOMを作成することが現実的です。作成したSBOMは、ユーザ(開発エンジニア・企業などの顧客)が特定のソフトウェアが組み込まれた製品に脆弱性がないかを確認したい時に、ベンダーはそれをユーザに渡します。
ただ、SBOMは一度作成すれば終わりというわけではありません。ソフトウェアのコンポーネントに変更があった場合は、速やかに作成し直さなければいけないことに注意が必要です。
現実的な方法で説明したSCAツールでは、全てのコンポーネントを正確に網羅的にスキャンされるわけではなく、不十分なSBOMが出力される可能性があるという問題があります。そのため、手作業による構成情報の追加や修正が必要です。

図2:理想的なSBOMの作成方法
図3:現実的なSBOMの作成方法

4. SBOMが解決する課題と活用による運用上のメリット

SBOMを活用することで、従来の主な3つの課題を解決することができます。
また、運用上の複数のメリットもあります。

SBOMが解決する主な課題

  • 構成管理(ソフトウェアの構成・バージョン・変更履歴の記録と管理)
    従来の構成管理では、そもそもソフトウェアの構成バージョン管理・変更履歴の記録・管理を十分に行えていないなどが原因で、情報の漏れがありました。また、そもそも構成情報の標準フォーマットがないといった問題がありましたが、SBOMを活用することで、以下のように課題を解決できます。
    • SBOMのフォーマットを構成情報の標準フォーマットとして利用できる
    • ソフトウェアの構成情報・依存関係を記録できる
    • 不具合やセキュリティインシデントが発生した際に、原因分析を効率的に行える
  • IT資産管理(ソフトウェア情報・ライセンス情報、サポート期限などの記録・管理)
    従来のIT資産管理では、ソフトウェア情報・ライセンス情報・サポート期限などを十分に把握できておらず、記録・管理できていないこともありました。SBOMと各コンポーネントのライセンスや保守に関する詳細情報とを突き合わせることにより、以下のように課題を解決できます。
    • ライセンス違反対策として使用できる
    • ソフトウェアのサポート期限(EOL)を管理できる
  • 脆弱性管理(コンポーネント・バージョン毎の脆弱性情報の収集と管理)
    従来の脆弱性管理では、構成情報を把握できていないことにより、収集すべき脆弱性情報の漏れや、対策が適切に行えていない場合がありました。また、「Log4j」の事例のように、利用している認識のないまま、脆弱性を持つコンポーネントを利用するなど、脆弱性があるかどうかの検出やその対処がすぐに行えないといったケースがありました。
    しかし、SBOMと脆弱性情報を組み合わせることによって、以下のように課題を解決することができます。
    • 製品ごとに特定の脆弱性の影響を確認できる
    • 脆弱性の影響を確認可能なため、製品に対応(パッチ・回避策など）の必要性を早期に判断できる

SBOM活用による運用上のメリット

  • SBOMをサプライチェーン・ワイド（組織横断）で利用できるソフトウェア情報管理の標準フォーマットの直接の手段として利用でき、構成管理・IT資産管理・脆弱性管理を共通化・一元化することができる
    • SBOMを利用することで、ソフトウェアを構成するコンポーネントの作成元を記録・確認することができるため、ソフトウェアの透明性を確保できる
    • SBOMを一元管理・共有することで、特定のソフトウェアの情報をたどることができ、追跡可能性を確保できる
      • ソフトウェアの依存関係をたどることができる
      • ソフトウェアのバージョン履歴毎の構成情報をたどることができる
  • あらゆるステークホルダー(開発エンジニア・CSIRT・PSIRT・営業・顧客など)が、用途に合わせて同じSBOMのデータを利用することができる
  • 各サプライヤーが作成したソフトウェアのコンポーネントのSBOMを収集することで、依存関係下位(部品・ライブラリなど)の情報を把握できる
  • どこで脆弱性が作りこまれたのか/影響する範囲を確認できる
    • Vulnerability-Exploitability eXchange (VEX)の情報を活用することで、ユーザ(オペレーター・ソフトウェア開発・サービスプロバイダーなど)は脆弱性の影響の有無を確認する調査の時間を減らすことができる。
    • ※
      VEXとは、ソフトウェアのコンポーネントの脆弱性がそのソフトウェアに悪影響をもたらすかどうかを伝達する手段の1つです。主なユースケースは、コンポーネントのサプライヤーから特定の脆弱性がそのソフトウェアに影響を及ぼすか否か、もし影響がある場合には推奨される修正策の有無に関する追加情報の提供がされ、ユーザがそれを基に自社製品への対応を行うことです PDF[13]。

5. SBOMの関連資料

2023年4月現在の、SBOMの技術面・運用面に関する資料をご紹介します。

表2: SBOMの技術面に関する資料と概要
SBOMの技術面に関する資料 概要
【NTIA】The Minimum Elements For a Software Bill of Materials (SBOM) PDF[14]
  • SBOMの最小要素の定義について
【SPDX】The Software Package Data Exchange new window[15]
  • バージョン毎のSPDXに関するドキュメント
  • ※各バージョンの付録GにSPDX Liteに関する記載
【Cyclone DX】CycloneDX v1.4 JSON Reference new window[16]
  • 各バージョンJSON/YAML毎のドキュメント (現在は1.4)
【SWIDタグ】SWID Tagging Specifications and Guidelines new window[17]
  • SWIDタグに関する仕様とガイドラインについて
【SPDX Lite】SPDX Lite-Guideline (JP) new window[7]
  • SPDX Liteの日本語のガイドライン
【NTIA】SBOM:Formats & Tooling PDF[18]
  • SBOMの作成ツールやフォーマットの変換ツールについて
表3:SBOMの運用面に関する資料と概要
運用面に関する資料 概要
【NTIA】Software Supliers Playbook PDF[19]
  • サプライヤー(商業ベンダー・OSSコード開発者など)向けのplaybook
  • SBOMの作成と提供について
【NTIA】Software Consumer Playbook PDF[20]
  • コンシューマー(SBOMの使用者・ユーザ)向け
  • サプライヤーからのSBOMの取得・取り込み・解析・使用について

6. まとめ

SBOMの概要・解決する課題・活用による運用上のメリット・関連資料をご紹介しました。

SBOMのデータ自体は構成情報であるため、それだけでは脆弱性対策を行うことはできません。脆弱性情報やライセンス情報などその他の情報と突き合わせて活用していくことが重要です。また、SBOMは昔からあった考え方ですが、強く推進されているのはここ数年ですので、まだまだ課題が多いです。運用面・技術面で改善が行われ、SBOMの活用が広まり、少しでも安心してソフトウェアを使用できる社会になれば良いなと思います。

本ブログをお読みいただいた皆様がSBOMを取り入れるとまでいかなくても、興味関心を持っていただけると幸いです。

参考:

執筆者プロフィール

岩田　琴乃（いわた ことの）
セキュリティ技術センター　脆弱性管理グループ

NECグループの社内向け脆弱性情報管理業務に従事しています。
SBOMに興味・関心があります。
好きなものは、焼き芋とクマです。

執筆者の他の記事を読む

アクセスランキング