2025.09.30
CISA 2025ガイダンス詳説：
日本のサイバーセキュリティ戦略におけるSBOMとOSINTの役割
1. はじめに：ソフトウェアサプライチェーンの透明性確保の重要性
ソフトウェアサプライチェーンリスクの増大とSBOMの台頭
現代のソフトウェアは、その複雑性と相互接続性から、単一のコードベースのみで構成されることは稀であり、むしろ、複数の開発者が提供する商用コンポーネント、オープンソースソフトウェア（OSS）、ライブラリ、モジュール、そして各種フレームワークを階層的に組み合わせることで構築される 。この開発モデルは、効率性とイノベーションを加速させる一方で、深刻なサイバーセキュリティリスクを内包している。特に、ソフトウェアのサプライチェーン全体が「ブラックボックス」と化し、ソフトウェアを構成する「隠れた」部品の可視性が失われるという根本的な課題が存在する。
近年発生した大規模なサイバー攻撃は、このサプライチェーンにおける脆弱性の管理が、国家や企業のセキュリティにおいて喫緊の課題であることを明確に示した。象徴的な事例としては、2020年のSolarWinds攻撃が挙げられる。この攻撃では、信頼されたソフトウェアベンダーの正規のアップデートプロセスに悪意のあるコードが注入され、多数の政府機関や企業がその意図せぬ形で侵害を受けた。さらに、2021年末に発覚したLog4Shell脆弱性は、広く利用されているOSSライブラリの深い階層に潜む脆弱性が、いかに広範囲かつ壊滅的な被害をもたらすかを示す決定的な警鐘となった 。これらの事案は、ソフトウェアがサプライチェーンを通じて複数の主体を経由する複雑な現実において、その構成要素に関する情報が、サプライヤーからコンシューマーへとシームレスに、かつ信頼できる形で伝達される仕組みが不可欠であることを浮き彫りにした。
こうした背景から、ソフトウェアサプライチェーンの可視性を確保するための重要なツールとして、SBOM（Software Bill of Materials）が注目を集めている。SBOMとは、ソフトウェアの構築に使用されるすべてのコンポーネント、ライブラリ、モジュール、そしてそれらの依存関係を詳細にリストアップした「正式な記録」である。これは、食品の原材料表示のように、ソフトウェアが何からできているかを明らかにするものであり、組織が使用・展開するソフトウェアの脆弱性を特定し、リスクを評価し、情報に基づいた意思決定を行うことを可能にする。
本レポートは、サイバーセキュリティ・インフラ安全庁（CISA）が主導する最新のSBOMガイダンス（2025年版）を詳細に分析し、その内容、技術的意義、そして今後の展望を明らかにすることを目的としている。特に、静的な情報であるSBOMを、動的な脅威情報に変えるためのOSINT（オープンソースインテリジェンス）の役割に焦点を当て、最終的に日本の企業や政府機関が、国際的な標準に準拠した強固なサイバーセキュリティ体制をいかにして構築すべきか、具体的な提言を行う。
2. CISA 2025ガイダンスの背景とNTIA 2021との比較分析
米国におけるSBOM推進の経緯：大統領令14028とNTIAの取り組み
米国におけるSBOM推進は、2021年に発令された大統領令14028「国家のサイバーセキュリティの改善」が大きな契機となった。この大統領令は、サプライチェーンセキュリティを強化する目的で、連邦政府にソフトウェアを販売するベンダーに対してSBOMの提供を義務付けた。これを受け、米国電気通信情報局（NTIA）が主導し、2021年7月に「SBOMの最小要件（MinimumElements）」が策定された 。
このNTIAの最小要件は、SBOMエコシステムの黎明期における基礎を築くものであった。当時は、SBOMという概念自体がソフトウェアの生産者と消費者の双方にとってまだ馴染みが薄く、SBOMを生成・管理するためのツールも限定的であった 。そのため、2021年のNTIAガイダンスは、最小限のデータ項目（Component Name、Supplier Name、Version、Dependency Relationshipなど）に焦点を当て、まずはソフトウェアサプライチェーンの可視性を確保するための共通のベースラインを確立することを目的としていた。この初期の取り組みは、SBOMの認知度を高め、広範な導入に向けた土壌を形成する上で極めて重要な役割を果たした。
2025年版ガイダンス策定の意図と成熟度
2022年9月、米国行政管理予算局（OMB）の覚書M-22-18により、CISAがNTIAの後継としてSBOMガイダンスを策定する役割を担うことが決定された。CISAが2025年8月に公開した「SBOMの最小要件」の公開草案は、NTIA 2021年版からの単なるアップデートではなく、SBOMエコシステム全体の成熟度を反映した、より実用的かつ洗練されたガイダンスである 。
この成熟度は、以下の複数の要因によってもたらされた。まず、Log4Shellのような大規模な脆弱性事案を経験したことで、SBOMが脆弱性管理に不可欠なツールであることが広く認識された。次に、SBOMを生成、共有、分析するためのツール群が大幅に拡張され、技術的な実現可能性が高まった 。さらに、ソフトウェア開発者から政府機関、医療、重要インフラといった多様なセクターの利害関係者がSBOMに関する議論に加わり、そのユースケースが広範に特定されるようになった 。
CISA 2025年版ガイダンスは、こうした進化を取り込み、SBOMを「単なるコンプライアンスチェックボックス」から、サプライチェーンリスクを能動的に管理するための「戦略的ツール」へと昇華させることを明確に意図している。これは、単にソフトウェアの構成要素をリストアップするだけでなく、そのデータの信頼性、検証可能性、および実用性を高めるための新たな要件を導入することで達成される。ガイダンスは、連邦政府機関の調達要件としてだけでなく、民間セクターの組織に対しても、サプライチェーンセキュリティの強化とリスクに基づいた意思決定のためにこの基準を採用するよう推奨している。
表1：NTIA 2021とCISA 2025の主要エレメント比較
| エレメント名 | NTIA 2021の要件 | CISA 2025の要件 | 変更の重要性（意義） |
| SBOM Author | SBOMデータを作成した主体 | SBOMデータを作成した主体。既存エレメントを拡張 | SBOMの「信頼性」を評価する上で、その作成主体に関するコンテキストを強化 |
| Software Producer | 「Supplier Name」（サプライヤー名） | 「Software Producer」（ソフトウェア生産者）に名称変更 | サプライヤーという曖昧な用語を、ソフトウェアを定義・識別する「生産者」に置き換えることで、信頼性の連鎖を明確化 |
| Component Name | コンポーネントの名称 | 生産者によって割り当てられた名称 。複数エントリを許可 | 曖昧さを減らし、人間が理解しやすい名称を提供する |
| Component Version | バージョンまたはリリース番号 | 生産者によって指定されたバージョン。バージョンがない場合は作成日で代用可能 | バージョン管理のばらつきに対応し、より正確な追跡を可能にする |
| Software Identifiers | 「Other Unique Identifiers」（CPE, SWID, PURLなど） | 少なくとも1つの識別子（CPE, PURL, UUID, OmniBORなど）を必須化 | ソフトウェアコンポーネントの一意な識別を強制し、自動分析とデータベース照合を容易にする |
| Component Hash | 新規追加 | コンポーネントの暗号学的ハッシュ値 | SBOMの「改ざん防止」と「整合性検証」を可能にし、信頼の基盤を築く画期的な要素 |
| License | 新規追加 | コンポーネントが提供されるライセンス | SBOMのライセンスコンプライアンスにおける役割を明確化 |
| Dependency Relationship | コンポーネント間の依存関係 | 包含関係や派生関係を明確にするよう要求。トランジティブ依存関係の包含を強調 | 複雑なサプライチェーンの可視化を深化させ、隠れた脆弱性を特定する |
| Tool Name | 新規追加 | SBOM生成に使用されたツール名 | SBOMの作成方法に透明性をもたらし、品質評価に役立つコンテキストを提供する |
| Timestamp | SBOM作成日時 | 最終更新日時。ISO 8601形式の使用を推奨 | SBOMデータの鮮度と正確性を追跡する上で不可欠な情報 |
| Generation Context | 新規追加 | SBOMがどのライフサイクルフェーズ（ビルド前、ビルド時、ビルド後など）で作成されたか | SBOMが静的なスナップショットではなく、開発プロセスの各段階における「コンテキスト」を持つことを示す |
| Access Controls | SBOMデータのアクセス権限 | 廃止 | アクセス管理の考慮事項を「配布と提供」に統合し、SBOM共有の柔軟性を高める |
3. CISA 2025ガイダンスが示す新たな要件と技術的意義
CISA 2025年版ガイダンスは、NTIA 2021年版で確立された基本的な枠組みを大幅に拡張し、サプライチェーンセキュリティの進化に対応するための新たな技術的要件を導入している。これらの新旧の要件は、SBOMの信頼性、検証可能性、および実用性を根本から向上させることを目的としている。
新規追加されたデータ項目
コンポーネントハッシュ (Component Hash)
コンポーネントハッシュは、CISA 2025ガイダンスにおいて最も重要な新規追加項目の一つである 。これは、ソフトウェアコンポーネントのバイナリデータから生成される、一意の暗号学的「指紋」である。このハッシュ値の導入は、SBOMが持つ信頼性に関する根本的な課題に対処するものである。
これまでのSBOMは、主にベンダーによる自己申告の形式であったため、ベンダーが意図的に一部の依存関係を省略したり、改ざんしたりする「無菌化SBOM（sanitized SBOM）」が作成される可能性があった 。コンポーネントハッシュを必須とすることで、SBOMの消費者は、受け取ったソフトウェアのコンポーネントを独自にハッシュ化し、SBOMに記載された値と照合することで、そのコンポーネントが改ざんされていないか、ベンダーが提供した記録と一致しているかを確認できるようになる。これは、SBOMを単なるリストから「起源と整合性の証明（attestationof origin and integrity）」へと格上げする、根本的なパラダイムシフトを意味する。この要件は、信頼できる第三者機関が存在しない場合でも、サプライチェーンにおける信頼の連鎖を技術的に構築するための基盤となる。ただし、このハッシュ生成のプロセスが、複雑な実環境で適用される際には、新たな複雑性や導入の障壁を生む可能性も指摘されている。
ライセンス(License)
ライセンス情報の追加は、SBOMが脆弱性管理だけでなく、法的リスク管理にも不可欠なツールであることを明確に示している。現代のソフトウェアは多くのOSSを組み込んでおり、それぞれのライセンス（例：GNU GPL、MIT、Apacheなど）には異なる使用条件や義務が付随する。SBOMにライセンス情報を明記することで、企業は使用するコンポーネントのライセンスコンプライアンスを効率的に管理し、潜在的な法的リスクを事前に特定・回避することが可能となる。
ツール名(Tool Name)と生成コンテキスト (Generation Context)
これらのメタ情報は、SBOMの「透明性」と「信頼性」をさらに向上させる。ツール名が記載されることで、SBOMの消費者は、そのSBOMがどのような種類のツール（例：静的コード分析ツール、ビルド時スキャナー）によって生成されたかを把握できる。また、生成コンテキストが明記されることで、SBOMがソフトウェア開発ライフサイクルのどの段階（例：ソースコード分析時、ビルド時、ランタイム）で作成されたかが明らかになる。これは、SBOMの品質を評価する上で不可欠な情報であり、異なるツールや環境が生成するSBOM間の違いを理解する助けとなる 。これらの項目は、SBOMを単一の静的な成果物としてではなく、SDLCに深く統合された「生きている」データとして捉えるCISAのビジョンを反映している。
既存項目の改訂
ソフトウェアプロデューサー (Software Producer)
NTIA 2021ガイダンスの「Supplier Name」が、CISA 2025ガイダンスでは「Software Producer」に名称変更された。この変更は、サプライヤーという用語が、ソフトウェアの実際の製造者を特定する上で曖昧であり、混乱を招くという実務上の課題を反映している 。ソフトウェアが複数の当事者を経由する複雑な現代のサプライチェーンにおいて、このより厳密な定義は、ソフトウェアの出所（provenance）を追跡する上でより有用な情報を提供する 。
「Secureby Design」原則との整合性
CISAと国家安全保障局（NSA）が共同で発表したガイダンスでは、SBOMの活用が、ソフトウェア製造者が「サプライチェーンの透明性を確保し、説明責任を受け入れる」という「Secure by Design」原則と合致すると明確に述べられている 。この原則は、セキュリティ対策を製品の企画・設計段階から組み込むという思想であり、SBOMは、この思想を具体的に実践するための重要な手段と位置づけられる 。
アクセスコントロールの廃止とその背景
CISA 2025ガイダンスでは、NTIA 2021版にあった「Access Controls」という項目が削除され、その考慮事項が「Distributionand Delivery」に統合された 。この変更は、SBOMの配布方法に柔軟性を持たせることを目的としている。SBOMには、内部の脆弱性情報やプロプライエタリなコンポーネントに関する機密情報が含まれる可能性があるため、一律に公開されるべきではないケースも存在する。この項目を配布の文脈に統合することで、組織は特定の役割（SBOM作成者、消費者、配布者）に応じた適切な共有方法を柔軟に選択できるようになる 。
4. SBOM活用の戦略的価値と導入における課題
SBOMの多様なユースケース
SBOMの価値は、単なるコンポーネンスのリスト作成にとどまらない。そのデータは、組織のサイバーセキュリティ戦略とビジネスプロセス全体にわたって、多様なユースケースを生み出す。
- ● 脆弱性管理の効率化: SBOMは、ソフトウェアに組み込まれている既知の脆弱なコンポーネントを特定するための基礎情報となる 。Log4Shellのような大規模な脆弱性が公表された際、SBOMを既存の脆弱性データベース（NVD: National Vulnerability Databaseなど）と自動的に照合することで、自社のどの製品やシステムが影響を受けるかを即座に特定し、迅速な対応を取ることが可能になる 。このプロアクティブな対応は、インシデント発生後の調査や修復にかかる時間とコストを大幅に削減する 。
- ● サプライチェーンリスク管理の強化: ソフトウェア調達者は、ベンダーから提供されたSBOMを分析することで、潜在的なリスク（例：古いバージョンのコンポーネント、既知の脆弱性を含むライブラリ）に基づいて、より安全なソフトウェアを選択できる 。この透明性の確保は、サプライヤーに対してセキュリティを開発プロセスに組み込むインセンティブを与える 。
- ● ライセンスコンプライアンスの管理: SBOMに記載されたライセンス情報を活用することで、組織はOSSライセンスの法的要件を効率的に遵守できる 。これにより、ライセンス違反による訴訟リスクや、不適切なオープンソースの利用を未然に防ぐことができる。
- ● ソフトウェア開発プロセスの改善: SBOMは、開発者が依存関係をより深く理解するのに役立つ。これにより、セキュリティリスクの高いコンポーネントの早期発見、レガシーコードの排除、そしてより安全な代替ライブラリの選択といった、開発初期段階での「Shift-Left」セキュリティ実践を促進する 。
自動化と相互運用性の重要性
SBOMが大規模なソフトウェアエコシステムで効果を発揮するためには、自動化と相互運用性が不可欠である。手動でのSBOM作成は、特に頻繁なアップデートや多数の依存関係を持つ大規模プロジェクトにおいて、非効率的でエラーが発生しやすい 。CISAガイダンスは、SBOMの自動生成と機械可読性を強く推奨し、SPDXとCycloneDXを好ましい標準フォーマットとして明示している 。特にSPDXは、ISO/IEC 5962:2021として国際標準に認定されている。
これらの標準フォーマットは、異なるツールや組織間でSBOMデータをシームレスに交換・統合するための基盤を確立する。この相互運用性は、サプライチェーン全体での情報の流れを円滑にし、ソフトウェアの消費者がベンダーのSBOMを容易に分析・活用することを可能にする 。
組織的・技術的課題
SBOMの導入は、その潜在的な価値にもかかわらず、いくつかの重要な課題に直面する。
- ● データの静的性と実環境との乖離: SBOMは、ある時点のソフトウェアの静的な構成要素リストである 。しかし、実際の運用環境（ランタイム）では、静的リストに記載されていないコンポーネントが動的にロードされたり、特定の依存関係が実際には実行されなかったりすることがある 。この乖離は、SBOMデータに基づく脆弱性スキャンが「セキュリティノイズ」（誤検知や無関係なアラート）を大量に発生させる原因となる 。
- ●「Known Unknowns」の管理: 複雑なソフトウェアサプライチェーンでは、すべての依存関係を完全に把握することは不可能である 。SBOMガイダンスは、情報が不明な部分を「Known Unknowns」（既知の未知）として明示することを推奨しているが、この不完全な情報をどのように管理し、リスク評価に統合するかは、依然として課題である 。
- ● SaaS/クラウド環境への適用: SBOMの概念は、オンプレミス環境のソフトウェアには比較的適用しやすいが、SaaS（Software as a Service）のようなクラウドベースのサービスにおいては、その適用範囲が不明瞭になる 。サービスが動的に変化し、顧客がコードを直接制御できない環境では、ソフトウェアの透明性だけでなく、「サービスの透明性」が問われることになる。
表2：SBOM導入における主要な課題と解決策
| 課題 | 根本原因 | 推奨される解決策 |
| セキュリティノイズ | 静的スキャンのみによる不完全な分析や、未使用コンポーネントの誤検知 | ランタイム分析の統合：実際に運用環境で実行されているコンポーネントを特定することで、誤検知を減らし、真のリスクに焦点を当てる 。 |
| データの陳腐化 | ソフトウェアの頻繁なアップデートや脆弱性の継続的な発見 | 継続的な監視の自動化：CI/CDパイプラインに統合されたツールを使用して、コード変更や新たな脆弱性の発見に応じてSBOMを自動的に更新する 。 |
| 静的な情報と動的な脅威の乖離 | SBOMが単なるスナップショットであること | OSINTとの連携：SBOMを公開された脅威データベースやインテリジェンスと継続的に照合することで、静的なリストを動的なリスク管理ツールへと変革する 。 |
| サプライチェーン全体の導入障壁 | サプライヤーや消費者の意識、技術的成熟度のばらつき | 段階的な導入：まず社内でSBOM生成・活用のノウハウを蓄積し、次にサプライチェーンの重要なパートナーから段階的にSBOMを要求・共有する 。 |
| 組織内の意識・スキル不足 | 開発者、セキュリティチーム、経営層の間の知識のギャップ | 部門横断的な教育と連携：SBOMのメリットを各部門の役割に応じて説明し、ワークフローに組み込むためのトレーニングを実施する 。 |
5. OSINTの役割：SBOMを"動的な脅威情報"に変える
SBOMは、ソフトウェアの内部構成を明らかにする「静的な情報」を提供する 。しかし、この情報が真に価値を持つのは、それが外部の「動的な脅威情報」と組み合わされたときである。このギャップを埋める上で、OSINT（オープンソースインテリジェンス）が決定的に重要な役割を果たす。
OSINT（オープンソースインテリジェンス）の定義とSBOMとの連携
OSINTとは、インターネット上の検索エンジン、ソーシャルメディア、公開フォーラム、学術論文、技術ブログといった「公開されている情報源」からデータを収集・分析し、脅威を評価したり、特定の疑問に答えたりするプロセスである。サイバーセキュリティの文脈では、脅威アクターの動向監視、新たな攻撃ベクトルの特定、そして既知の脆弱性に関する情報の収集に広く用いられる 。
SBOMとOSINTの連携は、静的なSBOMデータを、リアルタイムな脅威インテリジェンスへと変革する。SBOMが「何が含まれているか」という問いに答えるのに対し、OSINTは「その含まれているものに、現在、どのような危険があるか」というコンテキストを提供する 。
この連携により、組織は以下のことが可能になる。
- １．リアルタイムな脆弱性特定: ソフトウェアサプライヤーがSBOMを提供し、組織がそれを自社のデータベースにインポートする 。一方で、OSINTツールやサービスは、公開された脆弱性情報（CVEなど）、ハッキングフォーラムの議論、セキュリティ研究者のブログといった情報源を継続的に監視する 。新たな脆弱性が発表された際、この動的なOSINT情報が、SBOMデータと自動的に照合される 。これにより、組織は自社のどのソフトウェアコンポーネントが影響を受けるかを即座に特定できる 。
- ２．優先順位付けと対応の効率化: 脆弱性情報をSBOMと照合することで、単に脆弱性が存在するだけでなく、それがどのアプリケーションに、どのようなコンテキストで組み込まれているかを把握できる 。これにより、リスクに基づいて対応の優先順位を付け、修復作業を効率的に進めることが可能になる 。
- ３．未知の脅威への対応: OSINTは、まだ正式にCVEとして登録されていない「ゼロデイ脆弱性」や、攻撃者が水面下で議論している新たな攻撃手法に関する兆候を捉えるのに役立つ 。SBOMと組み合わせることで、組織はこうした予兆に基づき、影響を受ける可能性のあるコンポーネントを特定し、先回りして対策を講じることができる。
SBOM分析とOSINTツールの統合ワークフロー
SBOMとOSINTの連携は、手動で行うにはあまりにも膨大な作業となる。このため、多くの商用ソフトウェアソリューションが、このワークフローを自動化する機能を提供している。
- ● SBOM生成と脆弱性スキャン: SonatypeやSnykのようなSCA（ソフトウェア構成分析）ツールは、開発パイプラインに統合され、ソースコード、ビルド時、あるいはランタイムの分析を通じて、SBOMを自動生成する 。これらのツールは、生成されたSBOMを、自社が保有する膨大な脆弱性データベース（Snyk Vulnerability Database, Sonatype OSS Index）と自動的に照合し、既知の脆弱性を特定する 。
- ● 脅威インテリジェンスの統合: これらのツールは、単にSBOMを生成するだけでなく、そのデータを脅威インテリジェンスプラットフォームにフィードする。これにより、組織はサプライチェーンの継続的な監視体制を構築し、新たな脆弱性情報やライセンス変更、あるいは悪意のあるコードの存在をリアルタイムで検知できるようになる 。
- ● VEXとの連携: VEX（Vulnerability Exploitability eXchange）ドキュメントは、特定の脆弱性が、特定の製品に実際に影響を与えるかどうかを明確にする補完情報を提供する 。SBOMとOSINTツール、そしてVEXを組み合わせることで、組織は「セキュリティノイズ」を大幅に削減し、真に対応すべき脆弱性にリソースを集中させることができる 。
この統合されたワークフローは、SBOMを「単なる棚卸しリスト」から「プロアクティブな脅威インテリジェンス」へと進化させ、組織のサイバーレジリエンス（回復力）を飛躍的に向上させる。
6. 日本のサイバーセキュリティ戦略への提言
米国ガイダンスに準拠する重要性
米国政府のSBOM推進は、単なる国内政策にとどまらない。その影響はグローバルなサプライチェーン全体に及ぶ。日本政府（内閣官房国家サイバー統括室および経済産業省）が、CISA主導の国際ガイダンス「サイバーセキュリティのためのソフトウェア部品表（SBOM）の共有ビジョン」に共同署名した事実は、この国際的な潮流に日本が足並みを揃えることを強く示唆している。
この共同署名は、日本がSBOMに関して、米国をはじめとする主要国と共通のビジョンと技術的実装を共有する意思があることを示している。これは、日本の企業が国際的なサプライチェーンに深く組み込まれている現状を鑑みると、極めて重要な意味を持つ。米国政府とのビジネスを行う企業は、大統領令14028の要件を遵守する必要があり、将来的には、このガイダンスに準拠したSBOMの提供が、グローバル市場でのビジネスを行う上でのデファクトスタンダードとなる可能性がある。独自路線を追求することは、国際的なビジネス機会の損失や、コンプライアンス対応コストの増大につながるリスクをはらむ。したがって、日本の企業は、米国ガイダンスへの準拠を、単なる法的要件ではなく、グローバル市場での信頼性と競争力を確保するための「戦略的選択」として捉えるべきである。
日本企業が取るべき具体的なアクションプラン
日本の企業が、CISA2025ガイダンスが示す成熟したSBOMエコシステムに適応し、サプライチェーンセキュリティを強化するためには、以下の段階的なアクションプランが有効である。
フェーズ1：SBOMの概念定着と体制整備
- ● 組織横断的な理解の醸成: 経営層から開発者、法務部門、セキュリティチームに至るまで、SBOMの基本原則、導入メリット、および各部門の役割を共有する 。SBOMは、特定の部門のみの責任ではなく、組織全体で取り組むべき戦略的課題であるという認識を確立する。
- ● 明確なポリシーと手順の確立: SBOMの生成、メンテナンス、共有に関する明確なポリシーと手順を策定する 。誰が、どのタイミングで、どのような内容のSBOMを生成・共有すべきかを定義し、混乱を最小限に抑える。
- ● パイロットプロジェクトの実施: 特定の製品やサービスを対象に、小規模なSBOM導入の試験的プロジェクトを開始する 。これにより、実際の開発ワークフローへの統合に関するノウハウを蓄積し、全社展開に向けた課題を洗い出す。
フェーズ2：SBOMの生成と共有の実践
- ● 自動化ツールの導入: SPDXやCycloneDXといった国際標準フォーマットに対応したSBOM自動化ツール（SCAツールなど）を導入する 。手動での作業を排除し、SBOMの正確性と効率性を確保する。
- ● 全ソフトウェアのSBOM化: 社内で開発されたファーストパーティ製ソフトウェアだけでなく、使用しているすべてのサードパーティ製ライブラリやOSSについてもSBOMを生成する 。
- ● サプライチェーンパートナーとの連携: サプライチェーンの上流・下流に位置するビジネスパートナーに対して、SBOMの提出を要求する。また、自社のソフトウェアを提供する際には、CISAガイダンスに準拠したSBOMを共有する体制を構築する 。
フェーズ3：SBOMの戦略的活用とOSINTとの統合
- ● 継続的な監視体制の構築: 生成されたSBOMを脆弱性データベースと連携させ、新たな脆弱性が発見された際に自動的にアラートが発せられるような継続的な監視体制を構築する 。
- ● OSINTの統合: SBOMの情報を、OSINTツールやサービスが提供する動的な脅威インテリジェンスと連携させる 。これにより、ソフトウェアの構成要素に加えて、潜在的なゼロデイ攻撃やダークウェブでの議論といった、より広範な脅威コンテキストをリスク評価に統合する。
- ● リスク管理プロセスの統合: SBOMデータを活用して、脆弱性、ライセンス、技術的負債といった多角的なリスクを統合的に管理する 。このプロセスを、組織のインシデントレスポンス計画やサイバー保険戦略と連携させる。
7. 結論
CISAが主導する2025年版SBOMガイダンスの公開は、ソフトウェアサプライチェーンセキュリティにおける重要な転換点である。これは、2021年のNTIAガイダンスで確立された基本的な枠組みを、その後のエコシステムの成熟と実務上の経験に基づいて大幅に拡張したものである。特に、コンポーネントハッシュの導入は、SBOMを単なる自己申告のリストから、改ざん不能で検証可能な「信頼の証明」へと進化させる、技術的なパラダイムシフトを意味する。これにより、SBOMは、単なるコンプライアンスチェックボックスではなく、サプライチェーンリスクを能動的に管理し、ソフトウェアの整合性を確保するための戦略的ツールへと昇華した。
しかし、SBOMはそれ自体が万能の解決策ではない。それはあくまで静的な「データ」であり、その真価は、OSINTが提供する動的な脅威インテリジェンスと連携し、継続的な監視と分析のワークフローに組み込まれたときに発揮される。この連携によって、組織は新たな脆弱性の発見に即座に対応し、セキュリティノイズを削減し、真に重要なリスクにリソースを集中させることが可能となる。
日本政府が国際共同ガイダンスに共同署名したことは、日本の企業がグローバルなサプライチェーンに組み込まれる上で、米国標準との整合性が不可欠であり、国際標準への準拠が単なるコンプライアンス義務ではなく、グローバル市場での信頼性と競争力を確保するための戦略的基盤であることを明確に示している。
今後、SBOMの要件は、AIモデルやクラウドサービスといった新技術の進化に伴い、さらに洗練されていくだろう 。日本の企業は、この継続的な変化を注視し、段階的なSBOM導入計画を実行に移すことが不可欠である。SBOMの概念定着から、自動化ツールの導入、そしてOSINTとの統合に至るロードマップを明確にすることで、日本の企業は、サプライチェーンの透明性を確保し、サイバーセキュリティ能力を向上させると同時に、グローバル市場での持続的な成長を実現することができるだろう。
（hiro.I記）
引用文献
1. SBOM and Supply Chain Security | Keysight Blogs, https://www.keysight.com/blogs/en/tech/nwvs/2021/09/14/sbom-and-supply-chain-security
2. 内閣官房国家サイバー統括室と経済産業省、SBOM活用の重要性を示す国際ガイダンスに共同署名 - EnterpriseZine（エンタープライズジン）, https://enterprisezine.jp/news/detail/22695
3. A Shared Visionof Software Bill of Materials (SBOM) for Cybersecurity | CISA, https://www.cisa.gov/resources-tools/resources/shared-vision-software-bill-materials-sbom-cybersecurity
4. Improve SupplyChain Security through Visualization of Software Components Using SBOM, https://www.nttdata.com/global/en/insights/focus/2024/improve-supply-chain-security-through-visualization-of-software-components-using-sbom
5. Software Billof Materials (SBOM) - CISA, https://www.cisa.gov/sbom
6. A Guide to SBOMRequirements & Standards - RunSafe Security, https://runsafesecurity.com/blog/sbom-requirements-global-guide/
7. SBOM Security:6 Key Components and Top 3 Use Cases, https://www.mend.io/blog/sbom-security-6-key-components-and-top-3-use-cases/
8. CISA's new SBOMstandards go beyond checkbox security | ReversingLabs, https://www.reversinglabs.com/blog/cisa-new-sbom-standards
9. What Is aSoftware Bill of Materials (SBOM)? - IBM, https://www.ibm.com/think/topics/sbom
10. 経済産業省と内閣官房国家サイバー統括室、SBOM 共有ビジョン ..., https://scan.netsecurity.ne.jp/article/2025/09/25/53672.html
11. 9111-LFDEPARTMENT OF HOMELAND SECURITY [Docket No. CISA-2025-0007] Request for Commenton 2025 Minimum Elements for a Software - Federal Register, https://public-inspection.federalregister.gov/2025-16147.pdf
12. SBOM FormatsExplained and Compared | FOSSA Blog, https://fossa.com/blog/sbom-formats-compared-explained/
13. Sonatype'sSBOM Generation Capabilities Outpace the Competition, https://www.sonatype.com/test-blog/sonatypes-sbom-generation-capabilities-outpace-the-competition-1
14. The MinimumElements For a Software Bill of Materials (SBOM), https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
15. Software Billof Materials Elements and Considerations - Regulations.gov, https://www.regulations.gov/document/NTIA-2021-0001-0001
16. PotentialElements for an SBOM, https://www.ntia.gov/sites/default/files/publications/jitsuin_inc._-_2021.06.17_0.pdf
17. CISA's UpdatedSBOM Guidelines: What's New? | Revenera Blog, https://www.revenera.com/blog/software-composition-analysis/cisas-updated-sbom-guidelines-whats-new/
18. CISA releases2025 SBOM Minimum Elements outlining minimum requirements for softwaretransparency - Industrial Cyber, https://industrialcyber.co/cisa/cisa-releases-2025-sbom-minimum-elements-outlining-minimum-requirements-for-software-transparency/
19. CISA seekspublic input on new SBOM guidance for software transparency - Paubox, https://www.paubox.com/blog/cisa-seeks-public-input-on-new-sbom-guidance-for-software-transparency
20. CISA's SBOMDraft: Moving From Theory to Practice | DigiCert, https://www.digicert.com/blog/cisa-sbom-draft-guide
21. Software Billof Materials - Automated SBOM Generation - OPSWAT, https://www.opswat.com/technologies/sbom
22. A SharedVision of Software Bill of Materials (SBOM) for Cybersecurity, https://media.defense.gov/2025/Sep/03/2003791481/-1/-1/0/JOINT-GUIDANCE-A-SHARED-VISION-OF-SOFTWARE-BILL-OF-MATERIALS-FOR-CYBERSECURITY.PDF
23. 5 SBOMGeneration Tools & 5 Critical Best Practices - Oligo Security, https://www.oligo.security/academy/5-sbom-generation-tools-5-critical-best-practices
24. 7Recommendations to Improve SBOM Quality - Software Engineering Institute, https://www.sei.cmu.edu/blog/7-recommendations-to-improve-sbom-quality/
25. 2025 MinimumElements for a Software Bill of Materials (SBOM) - CISA, https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf
26. 政府、「ソフト部品表」の国際文書に署名 脆弱性管理でサイバー攻撃に備え |電波新聞デジタル, https://dempa-digital.com/article/690078
27. CISA, NSA,global partners release SBOM Guidance urging cross-border adoption to boostsoftware supply chain security - Industrial Cyber, https://industrialcyber.co/sbom/cisa-nsa-global-partners-release-sbom-guidance-urging-cross-border-adoption-to-boost-software-supply-chain-security/
28. CISA updatesSBOM recommendations | Cybersecurity Dive, https://www.cybersecuritydive.com/news/cisa-sbom-software-bill-of-materials-guidance-update/758414/
29. What Is aSoftware Bill of Materials (SBOM)? - Palo Alto Networks, https://www.paloaltonetworks.com/cyberpedia/what-is-software-bill-materials-sbom
30. SBOM ResourcesLibrary - CISA, https://www.cisa.gov/topics/cyber-threats-and-advisories/sbom/sbomresourceslibrary
31. サイバーセキュリティのためのソフトウェア部品表（SBOM）の共有ビジョンに関する国際ガイダンスに共同署名しました - 経済産業省, https://www.meti.go.jp/press/2025/09/20250904001/20250904001.html
32. A Guide toSBOM Best Practices and Fundamentals | Kiuwan, https://www.kiuwan.com/blog/a-guide-to-sbom-best-practices-and-fundamentals/
33. 「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の ..., https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html
34. The CompleteGuide to SPDX | FOSSA Learning Center, https://fossa.com/learn/spdx/
35. SBOMChallenges and Opportunities - ATARC, https://atarc.org/wp-content/uploads/2023/02/ATARC_Complying-with-SBOM-Mandates.pdf
36. How OurBusiness Complies with SBOM Recommendations - DevPro Journal, https://www.devprojournal.com/software-development-trends/sbom/how-our-business-complies-with-sbom-recommendations/
37. What is opensource intelligence (OSINT)? - IBM, https://www.ibm.com/think/topics/osint
38. What is OpenSource Intelligence (OSINT)? - Rapid7, https://www.rapid7.com/fundamentals/what-is-open-source-intelligence-osint/
39. Open-SourceIntelligence (OSINT) | Techniques & Tools - Imperva, https://www.imperva.com/learn/application-security/open-source-intelligence-osint/
40. How to Use theOSINT Framework: Sources, Tools, & Steps - BitSight Technologies, https://www.bitsight.com/learn/cti/osint-framework
41. What is OSINTOpen Source Intelligence? | CrowdStrike, https://www.crowdstrike.com/en-us/cybersecurity-101/threat-intelligence/open-source-intelligence-osint/
42. SoftwareSupply Chain Security Tools - Snyk, https://snyk.io/solutions/software-supply-chain-security/
43. SnykVulnerability Intelligence for SBOM - ServiceNow Store, https://store.servicenow.com/store/app/994d67e21b646a50a85b16db234bcb56
44. SBOMManagement Software For Security and Compliance - Sonatype, https://www.sonatype.com/solutions/sbom-management
45. Open SourceVulnerability Scanner: Get Your Free SBOM - Sonatype, https://www.sonatype.com/products/vulnerability-scanner
46. From SBOMGeneration to SBOM Management: the Next Software Supply Chain Challenge -FossID, https://fossid.com/articles/sbom-generation-to-management-software-supply-chain-challenge/
47. 経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引」掲載 - yamory, https://yamory.io/news/published-meti
48. What Is aSoftware Bill Of Materials (SBOM)? - Fortinet, https://www.fortinet.com/resources/cyberglossary/sbom