ソフトウェア部品表（SBOM）とは何か

ソフトウェア開発チームは、10年以上前に、オープンソース・ライブラリーやサードパーティー・リポジトリーの管理のためにSBOMを使用し始めました。大規模なサプライチェーン攻撃によって重大な脆弱性が露呈した後、サイバーセキュリティーの懸念からSBOMが注目を集めるようになりました。2020年のSolarWindsの侵害では、攻撃者が信頼されたソフトウェア更新に悪意のあるコードを挿入し、複数の官公庁・自治体を含む18,000の組織に影響を与えました。その後まもなく、2021 Log4jの脆弱性が明らかになり、世界中の何億台ものデバイスに影響を与え、侵害されたコンポーネントがシステム全体を脅かす可能性があることがさらに明らかになりました。

これらのサイバー攻撃は、連邦政府を含む組織がソフトウェア・システム内のコンポーネントと依存関係を把握できていないという厳しい現実を浮き彫りにしました。この可視性の欠如は、サイバーセキュリティー・リスクを評価し、脅威に効果的に対応することを困難にしています。脅威の緊急性が、ホワイトハウスに断固とした行動を促しました。大統領令14028は、2021年5月にすべての連邦ソフトウェア調達にSBOMを義務付けました。

米国国家電気通信情報局（NTIA）は、ソフトウェア・ベンダーが行政機関に販売する際に従わなければならないSBOMの最小要素を確立しました。2024年9月、CISAは「ソフトウェア・コンポーネントの透明性の枠組み」というタイトルの文書を公開し、これらの最小要件を拡張し、ソフトウェア・エコシステム全体にわたるSBOMの実装と管理に関するより詳細なガイダンスを提供しました。

この連邦指令は現在、業界全体でソフトウェア透明性モデルとして機能しています。例えば、金融サービス業界では、決済カード業界データセキュリティ規格（PCI DSS）バージョン4.0に、支払いシステムを保護し、脆弱性に対処するための在庫管理の要件が含まれています。医療分野では、 FDAがSBOMを医療機器に義務付けており、国際医療機器規制当局フォーラム（IMDRF）は医療機器と患者データ・システムを保護するためにSBOMの使用を推奨しています。

これらの業界のガイドラインや推奨事項は、民間部門全体でのSBOMの導入に向けた幅広い変化を反映しています。Gartner社は、クリティカルなインフラストラクチャー・ソフトウェアを構築または調達する組織の60%がSBOMを義務付けると予測しています。これは、2022年の20%未満から増加しています。この採用は必要性によって推進されています。最近の分析によると、最新のソフトウェア・アプリケーションの90%以上がオープンソースの依存関係を含んでおり、そのうち74%が高リスクの依存関係を含んでいます。コンプライアンス要件を満たし、サードパーティー・コンポーネントを検証し、発見されたセキュリティーの脆弱性に対処するために、SBOMを使用する組織が増えています。

SBOMは、原材料とその供給源の詳細を示す食品ラベルと同様に、ソフトウェア・コンポーネント、そのサプライヤー、依存関係について構造化された文書を提供します。

SBOM要件は、大統領令14028（2021年）で導入されて以来、大幅に進化してきました。NTIAの最小要件として始まったものは、業界での採用と規制の改良を通じて拡大してきました。2024年9月にCISAによって公開された現在のフレームワークは、これらの基盤に基づいて構築され、より広範な実装のための強化されたガイダンスがあります。

組織は、その部門や行政機関との関係によって異なるSBOM要件に直面しています。米政府の請負業者、重要インフラ事業者、規制部門の組織は、特定のSBOM要件に準拠しなければなりません。連邦政府はサプライヤーにSBOMの導入を義務付けていますが、政府契約外の民間組織は自主的に導入していますが、サプライチェーンのセキュリティーと顧客の信頼のために、SBOMの慣行を実施することがますます重要になっています。

CISAの2024年版フレームワークは、組織がSBOMの実践を段階的に強化できるよう、3段階の成熟度モデルを導入しています。

• 期待される最小限の段階：基本的なSBOM機能とコンプライアンスに必要な必須要素
  
  
• 推奨される実践：セキュリティーとコンプライアンスの広範なユースケースをサポートするドキュメントの強化
  
  
• 大きな目標：包括的なサプライチェーンの可視化を可能にする高度な機能

次の属性は、完全なSBOMに必要な基本要素を表します。

• SBOMメタ情報：SBOMデータの作成者、作成時のタイムスタンプ、文書化されている主要な構成要素など、SBOM文書自体のコア・データ
  
  
• サプライヤー名：ソフトウェア・コンポーネントを作成、定義、製造する事業体
  
  
• コンポーネント名：元のサプライヤーによって割り当てられたソフトウェア・コンポーネントの指定された名前
  
  
• コンポーネントのバージョン：バージョン固有の変更を取得して、更新と変更を正確に追跡
  
  
• その他の一意の識別子：正確なコンポーネント追跡のための共通プラットフォーム一覧（CPE）、SWIDタグ、またはパッケージURL（PURL）などの参照タイプが含まれます
  
  
• 暗号化ハッシュ：完全性の検証と正確な識別を可能にする各ソフトウェアコンポーネントの一意の指紋
  
  
• 依存関係：コンポーネントがどのように相互接続されているかを示す構造化されたマップで、直接的な依存関係と推移的な依存関係の両方をカバー
  
  
• ライセンス情報：提供されるソフトウェア・コンポーネントの法的条件の文書
  
  
• 著作権表示：記載されているコンポーネントに対する独占的および法的権利を保持する事業体

ソフトウェアの依存関係は、最新のアプリケーション内に複雑な相互接続を生み出します。SBOMは、直接依存関係（ソフトウェアに明示的に含まれるコンポーネント）と移行依存関係 （他の依存関係によって引き継がれるコンポーネント）を区別して、これらの関係を明確に把握する必要があります。

依存関係を文書化する場合、組織はその知識が完全であることを明示的に示す必要があります。依存関係情報はもともと、明示的にマークされていない限り、不完全である可能性があると想定されています。この透明性により、下流ユーザーは、ソフトウェア・サプライチェーンの潜在的な盲点を理解することができます。

組織は、ランタイムに読み込まれる動的な依存関係と、外部サービスから呼び出されるリモート依存関係も考慮する必要があります。これらは従来のソフトウェア・ビルドの一部ではないかもしれませんが、包括的なセキュリティー評価には、これらの関係を理解することが非常に重要です。

実際の実装では、すべてのソフトウェア・コンポーネントを完全に理解するのは常に可能なことではありません。組織は、未知の依存関係と不完全な情報を明示的に文書化することで、これらのギャップに透明性をもって対処する必要があります。契約上の義務やその他の制約により、特定のコンポーネントを完全に文書化できない場合、SBOMは全体的な依存関係構造を維持しながら、これらの編集を示す必要があります。

組織は、不確実な情報を省略するのではなく、これらの領域を未知または不完全であるとして明示的にマークする必要があります。このアプローチにより、下流ユーザーはリスク管理とさらなる調査の必要性について情報に基づいた意思決定を行うことができます。（機密情報などを削除した）編集済みのコンポーネントの場合、組織は完全な社内用SBOMと、外部共有用に適切に編集されたバージョンの両方を維持する必要があります。

SBOMを作成および維持するプロセスには、ソフトウェア開発ライフサイクル（SDLC）全体にわたって複数の利害関係者が関与します。組織は、自社の専有コンポーネントとオープンソース・ソフトウェア（OSS）コンポーネントの両方に対してSBOMを作成する必要があります。ソフトウェアベンダーと開発者は、主に開発プロセスの早い段階で初期SBOMを作成する責任があります。これらのSBOMにより、コードベースのコンポーネント全体の包括的な状態を把握できます。ソフトウェア購入者は、導入したアプリケーションに関するこれらの文書の検証と管理において重要な役割を果たします。

ソフトウェア開発チームは、SBOM生成を継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインに直接統合します。ビルド・プロセス中には、自動スキャン・ツールがソース・コードを分析してすべてのコンポーネントのインベントリーを作成し、直接的依存関係と推移的な依存関係の両方を取得します。これらのツールは、SPDXやCycloneDXなどの形式で標準化されたSBOMファイルを生成します（SWIDタグはそれほど重要ではありませんが、依然として有効な選択肢です）。各コンポーネントのメタデータ、バージョン情報、ライセンスの詳細が文書化されています。

バージョン管理システムはSBOM変更の履歴記録を維持し、時間の経過とともにソフトウェア構成がどのように進化したかを追跡します。リリースごとにソフトウェア・コンポーネント内のバージョン変更とセキュリティー・パッチを追跡できるため、脆弱性の管理やセキュリティー・インシデントへの対応に不可欠です。

開発チームは通常、新しい依存関係が追加されたとき、既存のコンポーネントが更新されたとき、セキュリティー・パッチが適用されたときなど、特定のイベントに基づいてSBOM更新をトリガーするようにパイプラインを設定します。この継続的な更新プロセスにより、ソフトウェアの実際の構成とそのドキュメンテーションとの間の整合性が維持されます。

開発パイプライン全体の品質管理チェックポイントにより、SBOMの完全性と正確性が検証されます。これらの検証ステップでは、各SBOMが必要な標準を満たし、ソフトウェア・リリース前に必要なコンポーネント情報がすべて含まれていることを確認します。自動検証により、文書内の相違が減り、リリース間の一貫性が向上します。

SBOMの作成をサポートするエコシステムは拡大を続けています。SBOMジェネレーターが基盤を形成し、ソースコードを自動的にスキャンしてコンポーネントとその関係を識別します。そのあと検証ツールは、生成されたSBOMを、確立された標準と仕様に照らして検証し、欠落している情報や不正確な情報にフラグを立てます。SBOMの自動化を成功させるには、チーム間のフォーマットの標準化、一貫した命名規則の実装、自動化ルールの明確な文書化の維持、継続的な改善のためのフィードバック・ループの設置など、確立されたベスト・プラクティスが必要です。

管理プラットフォームはこれらの機能に基づいて構築され、組織全体でのSBOMの保管、分析、配布のための機能を提供します。先進的なプラットフォームは、SBOMデータをより広範なリスクとコンプライアンスのワークフローに統合することでさらに進化します。

たとえば、オートメーション・ツールは脆弱性を特定のソフトウェア・コンポーネントにマッピングし、重大度に基づいて修復作業の優先順位を付け、時間の経過に伴う変化を追跡して新たに導入されたリスクを特定できます。これらのツールは、データを統合し、リアルタイムの洞察を提供することで、開発、セキュリティー、コンプライアンスの各チームが効果的にコレボレーションできるようにします。

効果的な実施には、適切なSBOMフォーマットを選択することが重要です。SBOMは、ソフトウェア・エコシステム全体で拡張できる自動生成と機械可読性をサポートする必要があります。SBOMプロセスを自動化することで、作成時の手動入力による誤りがなくなり、セキュリティー・ツールや開発ツールとシームレスに統合できるようになります。

既存のセキュリティー・ツールや開発ツールとの統合をサポートしながら、SBOMデータの自動生成、検証、利用を可能にするために、いくつかの標準化されたフォーマットが使用されています。組織は、CI/CDパイプライン内で自動SBOM生成を実装して、ソフトウェアの変更に対応してドキュメントを最新の状態に保つ必要があります。

現在のCISAフレームワークは、主にSPDXとCycloneDXの2つのフォーマットを認識しています。それぞれソフトウェア・コンポーネントの文書化に対するアプローチが異なり、さまざまなレベルの詳細が提供され、ソフトウェア開発ライフサイクル内の特定のユースケースに重点が置かれています。

ソフトウェア・パッケージのデータ交換（SPDX）は、Linux Foundationによって開発され、オープンソースのエコシステムや商用ソフトウェア・ベンダーに広く採用されています。このフォーマットは暗号化パッケージの検証をサポートし、JSON、RDF、XML、YAMLなど、機械で読み取り可能な複数のフォーマットの選択肢を提供します。豊富なメタデータ・サポートにより、ソフトウェア・サプライチェーン全体で詳細なセキュリティーと来歴の追跡が可能になります。

SPDXはオープンソースのコンプライアンス・シナリオに優れており、詳細なライセンス情報を提供し、組織がオープンソース・コンポーネントの使用状況を効果的に管理できるよう支援します。大手ソフトウェア・ベンダーやクラウド・サービス・プロバイダーは、その堅固な仕様と広範なエコシステム・サポートによりSPDXを採用しています。

OWASP Foundationによって開発されたCycloneDXは、アプリケーション・セキュリティーとソフトウェア・サプライチェーンのリスク管理を目的として特別に設計されています。VEXの統合とコンテナ分析のサポートに重点を置き、脆弱性管理、コンポーネントの追跡、サプライチェーン・セキュリティーに不可欠な主要な機能を提供します。

このフォーマットはセキュリティに重点を置いた要素を備えているため、包括的なソフトウェア・サプライチェーン・セキュリティー・プログラムを実装する組織に最適です。セキュリティーのユースケースをネイティブにサポートしているため、セキュリティー・チームや脆弱性管理ワークフローの間で導入が促進されています。

ソフトウェア識別（SWID）タグは、ソフトウェアの識別と管理のための標準化されたメカニズムを提供します。このフォーマットは、エンタープライズ環境におけるライフサイクル管理、パッチ追跡、主要な機能を備えた包括的なソフトウェア資産のインベントリー管理をサポートします。特に、SWIDタグは、属性のマッピングに関する2024年のガイダンスでサポートされる形式として掲載されなくなりましたが、SBOM 内の一意の識別子としては有効なオプションとして引き続き使用できます。

ソフトウェア構成分析（SCA）は、コードの脆弱性をスキャンするアクティブなサイバーセキュリティー・プロセス（関連ツールを使用）であり、一方、ソフトウェア部品表（SBOM）は、製品内のすべてのソフトウェア・コンポーネントの標準化されたインベントリーを提供します。どちらもソフトウェア・サプライチェーンのセキュリティーをサポートしていますが、最新の開発環境では異なる目的を果たします。

どちらのツールもソフトウェア・コンポーネントに焦点を当てていますが、SCAツールは開発中にコードを先見的にスキャンして分析し、主にオープンソース・コンポーネントとサードパーティの依存関係に焦点を当てています。これらのツールは、脆弱性検出、ライセンス・コンプライアンス、セキュリティー・ポリシー施行のためのリアルタイムな知見を提供します。

SBOMは、独自のコードを含むすべてのソフトウェア・コンポーネントを取得する標準化されたインベントリー・ドキュメントとして機能します。SBOMは、SPDXやCycloneDXなどの構造化された形式を通じてソフトウェア構成に透明性をもたらしますが、本質的には分析機能は含まれていません。SCAツールは通常、社内のセキュリティー手法をサポートしますが、SBOMは規制や業界標準による義務付けがますます進んでいます。

組織は通常、SCAツールを使用して開発中のセキュリティーを先見的に監視すると同時に、コンプライアンス要件とサプライチェーンの可視性のためにSBOMを維持しながら、両方のソリューションを一緒に実装しています。SCAツールは多くの場合、SBOMを自動的に生成して検証しますが、SBOMの文書化はスキャン・ポリシーの通知に役立ちます。

現代のソフトウェア・サプライチェーンは複雑なため、包括的なリスク管理とセキュリティー保証にはSBOMの採用が不可欠になっています。より効果的な意思決定のために、SBOMデータを他のセキュリティーおよびコンプライアンス情報と統合できる自動プラットフォームを使用する組織が増えています。

セキュリティー・チームは、リアルタイムの脆弱性の検出と対応を可能にする自動化プラットフォームを通じて、SBOMのデータを広範な アプリケーション・リスク戦略に統合しています。新しい共通脆弱性識別子（CVE）が出現すれば、これらのプラットフォームは、SBOMインベントリーを使用して、ソフトウェア・ポートフォリオ全体の影響を受けるコンポーネントに即座にマッピングできます。これにより、組織は安全なソフトウェア・プラクティスをサポートできます。

この統合により、AI駆動型の知見に基づくリスクの優先順位付けが可能になり、チームは最も重要なCVEに対処できるようになります。インシデント対応の際、SBOMからの詳細なコンポーネント・データは、侵害される可能性のあるコンポーネントに関する重要な情報を提供します。これにより、的を絞った修復の取り組みとより正確なリスク・アセスメントが可能になります。

SBOMは、ソフトウェア・コンポーネントの包括的なインベントリーを提供し、新しい脆弱性が発見されたときに影響を受けるシステムを迅速に特定できるようにすることで、脆弱性管理において重要な役割を果たします。

しかし、すべての脆弱性が等しくリスクをもたらすわけではなく、搾取可能性を判断することは困難な場合があります。そこで登場するのが、脆弱性悪用可能性交換（VEX）です。VEXは、既知の脆弱性に関する重要なコンテキストを提供することで、SBOMのユーティリティーを強化するフレームワークです。SBOMはソフトウェア製品内のすべてのコンポーネントを識別しますが、発見された脆弱性が悪用可能かどうかは示しません。VEXは、脆弱性が実際に及ぼす影響を明確にすることで、このギャップを埋めます。

VEXは、製品セキュリティー・インシデント対応チーム（PSIRT）やセキュリティー・チームに、特定の脆弱性がソフトウェア環境に影響を及ぼすかどうかを通知します。共通セキュリティー・アドバイザリー・フレームワーク（CSAF）を使用して、VEXは脆弱性の影響に関する機械可読のステータス更新情報を配信します。この情報があれば、セキュリティー・チームはより迅速かつ十分な情報に基づいた意思決定を行うことができます。

VEXデータをSBOMと統合することで、組織は誤検知を減らし、実際のリスクに優先順位を付け、脆弱性管理ワークフローを簡素化できます。このアプローチにより、自動セキュリティー・リスク評価と対象を絞った修復が大幅に進歩しました。

規制要件が進化するにつれて、組織には複雑なSBOM要件に対応できる高度なコンプライアンス管理機能が必要になります。SBOMは認証の一形態として機能し、ソフトウェア・コンポーネントがNISTガイドラインや大統領令14028などの基準に準拠していることを確認する検証可能な文書を提供します。SBOM 、ソフトウェアの構成とセキュリティーに関する透明性のある記録を提供することで、監査を簡素化し、業界全体での規制の整合性を実証します。連邦政府機関や規制対象業界は、NISTガイドラインや大統領令14028などのさまざまなフレームワークに準拠していることを証明する必要があります。高度なコンプライアンス・プラットフォームは、ソフトウェア・コンポーネントがセキュリティー基準を満たしていることを検証し、複数のフレームワークにわたるコンプライアンスの状態を追跡し、コンポーネントが要件から逸脱した場合にリアルタイムでアラートを発することができます。これらの機能は、組織が手動による監視を減らしながら、継続的なコンプライアンスを維持するのに役立ちます。

クラウドネイティブな環境とコンテナ化された環境は、SBOM管理に特有の課題をもたらします。これらの環境は動的な性質を持っているため、複雑なマイクロサービスのアーキテクチャー、頻繁に変化するコンテナのイメージ、複数のクラウド・プロバイダーとプラットフォームにまたがるデプロイメントを処理するための特別なアプローチが必要です。

組織は、コンテナ・オーケストレーション・プラットフォームと直接統合する特殊なSBOMツールを通じて、これらの課題に対処します。これらのソリューションにより、コンテナのイメージの構築と展開時にリアルタイムのSBOM生成が可能になり、ハイブリッドクラウド環境全体にわたって統一された可視性が提供されます。

コンポーネントの追跡を自動化し、既存のクラウド・セキュリティー・ツールと統合することで、組織は正確なソフトウェア・コンポーネント・インベントリーを維持し、クラウド・インフラストラクチャー全体にわたるセキュリティーの脅威に迅速に対応できます。この機能は、アプリケーションがコンテナで実行されるか、サーバーレス機能として実行されるか、従来の環境で実行されるかに関係なく適用されます。

SBOMは、サードパーティー製ソフトウェアに対する包括的な可視化を実現することで、サプライチェーン・リスク管理の基盤として機能します。組織は多くの場合、AI駆動型プラットフォームを使用して、他のセキュリティー・メトリクスと共にSBOMデータを分析し、アプリケーションの健全性とリスク体制の全体像を把握します。

これらのプラットフォームは、コンポーネントのバージョンを追跡し、サプライヤーのリスクを評価し、ライセンスのコンプライアンスを推進すると同時に、リスク軽減のための知見を提供します。SBOMデータをより広範なリスク管理プロセスと統合することで、組織はソフトウェアの依存関係について十分な情報に基づく意思決定を行い、より安全でコンプライアンスに準拠したアプリケーション環境を維持できるようになります。

組織は、ソフトウェア・エコシステム全体でSBOM慣行を実装する際に、いくつかの大きなハードルに直面する可能性があります。これらの課題を理解して対処することは、導入を成功させ、サプライチェーン全体で効果的なデータ・セキュリティーを維持するための重要な要素です。

組織がSBOM慣行を実践する際には、しばしば次の課題が発生します。

• 多様な環境にわたる数千のソフトウェア・コンポーネントの管理
  
  
• 異なる開発ツールとセキュリティー・プラットフォーム間のSBOMデータの統合
  
  
• データ品質の維持（特にレガシー・ソフトウェアやサードパーティ製コンポーネントの場合）
  
  
• 迅速な導入サイクルによるクラウド環境内の依存関係の追跡
  
  
• リソースの制約と、正確で最新のSBOMデータの必要性とのバランス
  
  
• コンポーネントが頻繁に変更される動的なクラウドネイティブ・アーキテクチャーへの適応

SBOMの導入を成功させるには、業界標準と組織のニーズに沿った戦略的なアプローチが必要です。主な要素は次のとおりです。

• ソフトウェア開発ライフサイクル全体を通したプロセスを自動化
  
  
• 既存のワークフローやセキュリティー・ツールとシームレスに統合
  
  
• SBOM管理のための統合プラットフォームを使用

• 基本的なSBOMの機能とコンプライアンスに不可欠な要素の実装
  
  
• より広範なセキュリティーとコンプライアンスのユースケースに対応するための文書を強化
  
  
• 主要な機能で包括的なサプライチェーンの可視性を実現

• 特にクラウドネイティブ環境で、SBOMをリアルタイムで生成および更新します
  
  
• 未知の情報を省略せずに透過的に文書化
  
  
• 完全な内部SBOMと外部共有のための冗長化されたバージョンの両方を管理
  

• 定期的な監査と自動検証により、明確なSBOMガバナンス・ポリシーを作成
  
  
• SBOMデータを脆弱性悪用可能性交換（VEX）とつなげて脆弱性管理を強化

これらの慣行に従うことで、組織はSBOM実装の課題に対処しながら、サプライチェーンの可視性を向上させ、セキュリティーを強化し、コンプライアンスを維持できます。

ソフトウェアサプライチェーンのセキュリティーを取り巻く環境は進化し続け、SBOMのイノベーションと採用を推進します。組織がますます巧妙化する脅威に直面するにつれて、ソフトウェア・エコシステムの保護におけるSBOMの役割はますます重要になっています。

SBOMの実装と活用の未来を形作るいくつかの重要な傾向があります。

人工知能の進歩により、組織がSBOMを管理し、活用する方法が変化しています。最新のAIシステムは、SBOMの生成と分析を自動化すると同時に、より正確な予測リスク分析と高度な脆弱性検知を提供します。この自動化は、ソフトウェア・サプライチェーン全体にわたる先見的なセキュリティー・リスクの特定にまで拡張されます。

大きな進展は、AIが生成するコードやモデル特有の課題に対処する、AI/ML BOMの登場です。これらの強化されたBOMは、AIモデルのアーキテクチャー、トレーニング・データ、テスト方法を文書化し、AI開発プロセスに必要な透明性をもたらします。

SBOM管理のセキュリティー環境は進化し続けています。ブロックチェーンと分散型台帳テクノロジーは、安全なSBOMの保管と共有のための新しいソリューションを提供し、重要なインフラ・システムにとって特に価値のある不変の監査トレースを作成します。侵害されたコンポーネントを迅速に特定し、修復を効率化できる実行可能なSBOMデータを求める組織の声がますます高まっています。

ブロックチェーンは、改ざん防止ストレージを提供し、検証の分散化を可能にし、厳格なアクセス制御による組織間の安全な共有を促進することで、SBOMのセキュリティを強化できます。

この技術の融合により、既存のDevSecOpsプラクティスと一体化した統合プラットフォームの採用が促進されます。これらのソリューションは、異なるデータソースの統合から、複数のソフトウェア・バージョンやブランチにわたる承認の管理まで、SBOMライフサイクル全体を自動化し、リスク軽減のための情報を提供します。