SBOMの最小構成要素ガイダンス更新：CISAなどが定めるソフトウェアサプライチェーンリスク管理への対応

解説

近年、デジタル化が急速に進む中で、ソフトウェアを利用する際のサプライチェーンリスクが主要なセキュリティ懸念事項となっています。これに対応するため、「SBOM（Software Bill of Materials）」という概念が注目されており、これは簡単に言えば「ソフトウェアの成分表」のようなものです。

SBOMは、ソフトウェアを構成している部品やライブラリ、それらがどこから来たかといった情報を開示する仕組みです。これにより、利用企業側は自身が使用しているソフトウェアの組成を正確に把握し、セキュリティ上の脆弱性リスクを低減することができます。

これを受けて、アメリカ政府機関（CISAなど）は、以前発表されたSBOMの最小要素についてガイダンスを更新しました。この新しいガイドラインは、過去のパブリックコメントなどの関係者からのフィードバックを取り入れつつも、基本的な目的である「ソフトウェアの透明性の確保」という理念は維持しています。

企業がよりリスクに基づいた意思決定を行うために不可欠な要素となっており、AIやクラウド環境で動くサービスなど、特定の種類のソフトウェアには追加の情報開示が必要となる可能性があります。組織全体でソフトウェアの構成情報を可視化することが求められています。

ポイント

• SBOM（Software Bill of Materials）は、ソフトウェアがどのような部品で構成されているかを明記した「成分表」に相当する情報です。
• CISAなどの米政府機関が、以前のガイダンスを更新し、より広範な最小要素を定義しました。
• この情報はサプライチェーンにおけるセキュリティリスク管理において極めて重要であり、AIやSaaSなど特定のソフトウェア種類に追加要件が発生する可能性があります。

情シスへの影響

SBOM情報の取得と利用は、システムの構成要素に関する高い透明性を要求します。

具体的な影響としては、以下の点が挙げられます。

1. 資産棚卸しと依存関係の可視化: 自社システムや利用SaaS/クラウドサービスの全てのコンポーネントを洗い出し、その部品レベルの情報（ライブラリ名、バージョンなど）を把握する必要が生じます。

2. リスクアセスメントプロセスの強化: SBOMデータに基づいて、どのサプライヤーからのコンポーネントが既知の脆弱性（例：Log4Shellのようなもの）を抱えているかを迅速に特定し、対策を立てるプロセスが必要になります。

3. 外部連携・調達要件への組み込み: 今後、新しいソフトウェアやSaaSを導入する際には、ベンダーに対してSBOMの提供を必須とする契約条項や技術的な検証（受け入れ基準）を設定することが求められます。

影響範囲

全社システム、利用しているサードパーティ製クラウドサービス（SaaS）、AI関連ソリューション、開発・構築プロセス 全てのソフトウェアコンポーネント（オープンソースライブラリ含む）の構成情報および供給元ベンダーとの契約関係

重要度

★★★★☆

対象者

• セキュリティ担当者
• M365管理者
• Entra管理者
• ネットワーク管理者

優先度

計画的に対応

優先度の理由

これは特定の緊急パッチというよりは、ソフトウェア開発や調達のプロセス全体に影響を与える構造的な要求事項です。法規制レベルでの動きを含むため、目先の対策として「今すぐ」というよりは、今後のシステム設計・導入検証サイクル（数か月〜1年単位）で体制を整える計画が必要です。ただし、セキュリティ担当者としては喫緊の情報収集が必要です。

確認手順

• 利用している主要なSaaS/クラウドサービスについて、ベンダー側がSBOMを提供可能か、または提供義務を設けているかを確認する。
• 自社開発システムや業務利用システムのソフトウェア構成要素（ライブラリ、OSバージョンなど）の洗い出しと文書化に着手する。
• 新しいシステム調達・導入プロセスにおける「SBOM要求」の組み込みに関するガイドラインの策定を行う。
• ベンダーとの契約レビューを実施し、セキュリティ要件としてSBOM提供を義務付ける条項を追加検討する。
• 内部開発チームに対し、ソフトウェア開発ライフサイクル（SDLC）へのSBOM生成プロセスの組み入れを指示する。