自組織のSBOM管理ツール選定の参考になる？ 米国家安全保障局が公開した「SBOM管理のための推奨事項」

3パートから構成される「SBOM管理のための推奨事項」

　ソフトウェアの脆弱性管理手法の1つとして「SBOM（Software Bill of Materials:ソフトウェア部品表）」が注目される中、米国家安全保障局（National Security Agency、以降NSA）は、「SBOM管理のための推奨事項（Recommendations for SBOM Management）」を公開しています。これは国家安全保障システム（National Security Systems、NSS）を対象に、適切にSBOM管理機能を組み込むことを支援する目的で作成されたもので、初版は2023年12月に公開され、本稿執筆時点での最新版は現地時間2024年1月4日付で更新されたバージョン1.1です。

　本来はNSSを対象とした文書ですが、一般の企業やソフトウェア開発者などにとっても参考になるところのある内容となっていますので、今回はその一部を紹介します。なお、詳細については必ず原文を参照してください。本文は10ページ強と、比較的コンパクトにまとまっています。

　この文書は主に以下の3つのパートから構成されています。

• 行動指針としての推奨事項
• NSSのオーナーが実施すべきベストプラクティス
• 推奨ツールの機能

　ここからは、この3つのパートのうち「推奨ツールの機能」を紹介します。この「推奨ツールの機能」ではSBOM管理ツールの重要な機能について考慮すべき点を以下のように14の項目に分類しています。なお、既存のツールの多くは、これらの機能の全てをサポートしているわけではないので、各組織は自組織の環境に適した機能を特定し、その機能のあるツールを選択すべきとしています。

1. SBOMの入力

• 全てのSBOMフォーマットのバージョン、例えば、最新のCyclone DX（CDX）およびSPDXバージョンをサポートおよび管理する。理想的には、 両方のフォーマットをインポートおよびサポートすべきである。
• SBOMをJSONまたはXMLのファイルタイプでインポートする。理想的には、JSON、XML、およびCSVのファイルタイプをインポートすべきである。
• SBOMをインポートする際に、SBOMの構造および構文が適切なフォーマット仕様（特定のバージョンを含む）に準拠していることを確認する。
• そのSBOMが、そのSBOMフォーマットおよびバージョンに対して適用できる構造規則および構文規則に準拠しているかについての情報を表示する。理想的には、評価された品質レベルを表示してユーザーに警告する一方で、インポートを続けるか否かのオプションを与えるべきである。
• インポートされるSBOMファイルを正規化および修正する際にユーザーをアシストする自動修正オプションを含める。

2. SBOMの出力

• CDXまたはSPDXのいずれかのフォーマットを使ってSBOMをエクスポートする。理想的には、両方のフォーマットをエクスポートする機能を含むべきである。
• SBOMをJSONまたはXMLのファイルタイプでエクスポートする。理想的には、JSON、XML、およびCSVのファイルタイプをエクスポートする機能を含むべきである。
• あるSBOMフォーマットを別のフォーマットに変換する。
• あるSBOMファイルタイプを別のファイルタイプに変換する。
• SBOMツールのリポジトリから複数のSBOMを1つのSBOMに統合する。

3. SBOMの生成

• さまざまなタイプのソフトウェア開発プロセスの出力からのSBOMを生成する（例えば、ソフトウェアビルド環境から、バイナリファイルの分析から、システムレジストリのクエリから、など）。

4. SBOMコンポーネントの処理

• NTIA最小SBOMフィールド（サプライヤー名、コンポーネント名、コンポーネント固有識別子であるCPE、PURL／ハッシュ、コンポーネントバージョン、コンポーネント依存関係、コンポーネント作成者）を各コンポーネントに対して表示する。
  ※訳註：NTIA最小SBOMフィールド（NTIA-minimum SBOM field）＝米商務省国家電気通信情報局（National Telecommunications and Information Administration、NTIA）が定めたSBOMに含めるべき最小限の要素のデータフィールド
  ※訳註：CPE=Common Platform Enumeration（共通プラットフォーム一覧）
  ※訳註：PURL=Package URL
• 追加の参照ソースを使ってSBOM情報を強化する。理想的には、SBOMデータを強化するために外部情報が使われたことを示す視覚的な手がかりと強化データのソースサイトの参照情報を提供すべきである。
• コンポーネントの依存関係をグラフィカルに表示する仕組みを含める。
• 外部強化を含む、コンポーネントの出処の情報を表示する。

5. SBOMおよびSBOMコンポーネントの完全性の検証

• 各コンポーネントに対するハッシュ情報を取得および表示する。理想的には、この検証はSBOMに対するデジタル署名と各コンポーネントに対する出処の情報に加え、コンポーネントハッシュ、およびPURLまたはCPEポインタを提供すべきである。
• 出処データが収集された情報源へのリンクを含める（完全性を検証し、リスクを評価する能力をサポートする）。

6. 脆弱性のトラッキングと分析

• NVD（National Vulnerability Database）およびその他の脆弱性データからの更新を毎日提供する。理想的には、これらの更新は関連するサイバー脅威インテリジェンス（Cyber Threat Intelligence、CTI）およびSBOMデータ向上サービスからの継続的な抽出および分析を提供すべきである。
• 新たな脆弱性と更新をユーザーに通知する。これには顕在化した致命的脆弱性とその深刻度についての警告が含まれる。理想的には、これらの通知は新しい脆弱性と既存の脆弱性への更新を明確に区別し、リスク改善ガイダンスとともに脆弱性対応に優先順位をつけるための追加情報を提供すべきである。
• さまざまなソフトウェア脆弱性／弱点データベースに加えて脅威インテリジェンスのさまざまな情報源を統合する。
• 組織固有のポリシールールを適用および更新する機能を含む、柔軟なポリシーエンジンを提供する。理想的には、このカスタマイズによって脅威インテリジェンスをポリシールールとして統合することを可能にすべきである。
• ユーザーのSBOMリポジトリ／資産インベントリにおいて現れた脆弱性の存在を特定および調査する複数の方法を提供する。理想的には、新たに発見された脆弱性によって影響を受けるソフトウェアおよび構成を含む特定のネットワークまたはエンドポイントを迅速に割り出すべきである。
• 脆弱性の修正の適時性をサポートおよびトラッキングする（脆弱性のある、取り替えられたソフトウェアと、修正／強化された代替ソフトウェアを区別するための新しいSBOMに対する構成管理／トレーサビリティを含む）。

7. 特定された脆弱性と悪用可能な脆弱性の識別

• 脆弱性が実際に悪用可能かどうかを示し、悪用可能でない場合はその主張の根拠と正当性をサポートする。理想的には、脆弱性悪用可能性交換（Vulnerability Exploitability eXchange、VEX）フォーマットを使用してコンポーネントの脆弱性の悪用可能性に関する情報に対して注釈を付け、且つその情報を更新すべきである。

8. ユーザーインターフェース

• ヒューマン・コンピュータ・インターフェース（Human Computer Interface、HCI）の標準に従う。
• アクセシビリティ機能を組み込む。
• 情報を評価しやすくする仕組みを提供し、必要なら、ユーザーが次のレベルの詳細を見るために（多くの場合、アイコンの上にカーソルを置くか、リンクのあるアイコンをクリックすることによって）さらに掘り下げることが簡単にできるようにする。
• ソフトウェアコンポーネント、脆弱性、ライセンス、サプライヤー組織、ユーザー、およびユーザー組織についての情報属性を伝えるために、理解しやすいグラフィック表現の方法とフォーマットを提供する。
• ソフトウェアコンポーネントの出処、脆弱性、ライセンス、リスクステイタスに対する追加情報を「ドリルダウン」して取得する複数の方法を提供する。
• 資産のトラッキング、脆弱性管理、インシデント管理などを円滑に進めるためにSBOMの構造化されたグルーピングまたはカテゴリを作成する手段を提供する。
• ユーザーが選択可能な属性（例えば、ソフトウェア／BOMタイプ、ソフトウェア／BOMソース、ソフトウェア／BOM PoC、コンポーネントタイプ、コンポーネントパッケージ、コンポーネント使用年数、コンポーネントバージョン、セキュリティトレンド、脆弱性深刻度、脆弱性数、組織レベル、ライセンスタイプ、違反など）に応じてSBOM情報をフィルタリング／ソート／グルーピングする機能を提供する。

9. 出力形式と方法

• コンポーネントの属性、脆弱性情報、ライセンス情報、およびコンポーネントのサプライヤー情報に関する標準化されたレポートを出力する。
• 依存情報をグラフィックやテキストフォーマットでエクスポートする。
• 分析結果をグラフィック表現で出力する。
• 理想的には、外部コミュニケーションで使用するために特定のテキストおよびグラフィックを（SBOM自体からであろうと分析および向上プロセスから生成されたものであろうと）エクスポートするモジュール化された手段を提供する。

10. SBOMのバージョニングと構成管理のサポート

• SBOMのための拡張可能な構成管理機能を含む。最低でも、SBOMを整理し、バージョン履歴を保持し、且つSBOM／ソフトウェアの変更をトラッキングする仕組みを含むべきである。
• 複数の情報属性において（例えば、組織、ソフトウェアサプライヤー、ソフトウェアのタイプ、BOMのタイプ、ライセンスのタイプなどによって）SBOMを整理するためのユーザーが調節可能な仕組みを含める。
• 各コンポーネントバージョンをまたがった各深刻度レベルに対する脆弱性の数を示すトレンドグラフィックを含めるとともに、各バージョンのリリースごとにコンポーネントの脆弱性の数が増加しているか減少しているかを報告する。
• 同じソフトウェアに対するSBOMバージョンを比較して（例えば、異なるコンポーネントまたは異なるコンポーネントバージョン、異なるソースなどによる）違いを強調する。

11. 他のシステムとの統合とワークフロー

• 他のシステムとの情報のインポートおよびエクスポートを円滑に進めるために「APIファースト」の設計を採用する。理想的には、ツール内の情報要素は個別にエクスポート／ダウンロード可能であるべきである。
• 複数のタイプのSBOMソースとその他のデータを統合し、それらを組み合わせて分析できるようにする。
• フォーマットにとらわれない、独立した、ステートレスで拡張可能なAPI機能（RESTなど）を活用してプロセスやワークフローを自動化する。
• セキュアで、統合されたプロデューサー／コンシューマー交換エコシステムをサポートする。

12. データソースへのアクセスのサポート

• AI／MLエンジンと関連する「データレイク」を統合し、多様なタイプの脅威シグネチャーおよびパターンに照らし合わせてSBOMコンポーネント情報を分析する。
  ※訳註：AI／ML=人工知能（AI）と機械学習（ML）
  ※訳註：データレイク（data lake）=大量の生データを元の形式のまま保存できるリポジトリ
• SBOM管理ツールが適用可能であれば識別してトラッキングするオープンソースソフトウェアライセンスの更新可能なライブラリを含める。

13. 拡張可能なアーキテクチャ

• リスク許容度のルールまたはポリシーが異なる可能性のある企業内の個別の下位組織をサポートする仕組みを含める。
• 他のタイプのSBOMを取り扱う。
• リスク管理、脆弱性管理、およびインシデント管理の活動を遂行するために共に働く一連のツールの一部となる、またはその一連のツールをサポートする。

14. SBOMツールのセットアップと構成

• LinuxまたはMicrosoft環境で簡単にダウンロード、セットアップ、そして統合できる仕組みとサポート資料を提供する。理想的には、両方の環境をサポートすべきである。

　今回紹介した文書はNSSを対象としたものなので、SBOM管理ツールに求められる機能としては一般の企業や組織にとってオーバースペックなところもあると思います。それでも、自組織の環境に適したSBOM管理ツールの機能を特定し、自組織に必要なツールを検討・選定する際の参考資料としては十分に使えるはずです。うまく活用してください。