「トップレベルだけ」では安心できない —TR‑03183で組み立てるCRA準拠SBOMの最短ルート—

はじめに

2027年12月より全面的に施行される欧州CRA¹（EU Cyber Resilience Act：欧州サイバーレジリエンス法）において、特に注目すべき対応の1つであるSBOM（Software Bill of Materials：ソフトウェア部品表）について、「少なくともトップレベルの依存関係」と聞き、ひとまず安心している担当者もいるかもしれません。しかし、局所的な理解は、将来の大きな手戻りやセキュリティインシデントにつながる落とし穴かもしれません。

• 「本当にトップレベルの記載だけで、SBOM本来の目的を果たせるのか？」
• 「結局、SBOMのフォーマットや項目は、何を選べば正解なのか？」
• 「SBOMはどのタイミングで作るのがベストなのか？」

本稿では、上記の漠然とした不安や疑問に対し、CRAにおける要求の本質を読み解き、SBOMの運用を形骸化させないための対応方針を、TR-03183 : Technical Guideline BSI TR-0318: Cyber Resilience Requirements for Manufacturers and Products Part 2: Software Bill of Materials (SBOM) ² v2.1.0に基づいて解説します。

※「SBOM」については、SBOM普及の本格化～ソフトウェアサプライチェーンの構造的な課題と解決策～を参照ください。

1章：なぜ「トップレベルだけ」では足りないのか

CRAの条文から抽出したSBOMに関する要求事項（概要）

1. 技術文書の一つとして、ソフトウェア部品表を作成すること
2. 少なくとも製品のトップレベルの依存関係を網羅する、一般的に使用され機械で読み取り可能な形式のソフトウェア部品表を作成すること
3. （ソフトウェア部品表をユーザーに提供する場合）ソフトウェアの部品表へアクセスに関する情報を提供すること
4. 市場監視当局からの要求があった場合には、ソフトウェア部品表を提供すること

CRAのSBOM最小要件を正しく捉える

CRAが示すSBOMの要件は、あくまで法律として課すことのできる最低限のラインです。具体的には、製品が直接利用しているソフトウェアコンポーネント、つまり「トップレベルの依存関係」をリスト化することを求めています（図表1）。

しかし、実際のソフトウェアは、そのトップレベルのコンポーネントがさらに別のコンポーネントを呼び出す、「推移的依存関係（Transitive Dependencies）」と呼ばれる複雑な階層構造を持っています（図表2）。そして、セキュリティを脅かす脆弱性の多くは、この深く隠れた階層に潜んでいるのです。

図表1：トップレベルと推移的依存関係

^{出典：「EU Cyber Resilience Act」に基づいてPwCが作成}

※実際に発生したインシデントの事例については、ソフトウェアサプライチェーンリスクの顕在化事例とSBOMによる解決を参照ください。

したがって、CRAの最小要件を満たすトップレベルのSBOMだけでは、サプライチェーン攻撃に対してあまりにも無力です。製品の安全性を確保し、インシデント発生時に迅速な対応を行うためには、推移的な依存関係のすべてを可視化することが不可欠です。

2章：TR-03183が埋める実務の穴

TR-03183の位置づけ

CRAが示すSBOMの要件は、「何をすべきか（What）」は理解できても、「どう実現するのか（How）」の詳細については、疑問点が残ります。そこで、BSI（Bundesamt für Sicherheit in der Informationstechnik：ドイツ連邦政府情報セキュリティ庁）は、CRAの要件を実践的なものにすることを目的としTR-03183を策定しています。これは3つのパートで構成されており、特にPart 2（2025年8月20日にv2.1.0が公開）ではSBOMの要件に関する詳細が記載されています。

※あくまでも、BSIが発行している本文書は、本稿執筆（2025年11月現在）時点でCRAの正式なガイドラインとして採択されているものではありません。

どのレベルのコンポーネントまでをSBOMで示す必要があるか

TR-03183では、「Delivery item SBOM」と言われるSBOMが要求されています。

図表2：Delivery item SBOMの図

^{出典：BSI「TR-03183 : Technical Guideline BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products Part 2: Software Bill of Materials (SBOM) 2 v2.1.0」に基づいてPwCが作成}

つまり、TR-03183ではSBOMに記載すべきコンポーネントの範囲を製品の納品範囲に含まれるもののみに限定しており、外部参照しているコンポーネント（外部APIなど）については、「最初の」依存関係までを識別するのみということになります（※ここでの識別とは、「4章：どの項目が必要か」で要求されている項目をすべて記載することではなく、コンポーネント作成者、コンポーネント名、コンポーネントバージョン、その他の一意識別子の情報を最低限情報として記載することを指します）。これにより、SBOMは製品のセキュリティとトレーサビリティを確保しつつ、管理の複雑さを軽減することができます。

3章：どのフォーマットで作るか

SBOMのフォーマット

SBOMの導入を検討する際、担当者が最初に直面するのが「どのフォーマットを、どのバージョンで作成すべきか」という技術的な問いです。この選択は、将来のツール連携やサプライチェーンとの情報交換を、いかに円滑にするか左右する重要な判断となります。

TR-03183では、現在デファクトスタンダードとなっているSPDXとCycloneDXのいずれかを利用することとしています（図表3）。この選択に重要な観点は、「どちらが優れているか」ではなく、「自社の開発環境、SBOMの利用目的（脆弱性管理、ライセンス管理など）、サプライチェーンのエコシステムなどにどちらが適合しているか」で判断することです。多くのSBOMツールは両フォーマットに対応しており、相互変換も可能ですが、社内での取り扱いや取引先が必要とするフォーマットなどは、事前に調整しておくことで、スムーズな運用に繋がります。

※TR-03183 v2.0.0からv.2.1.0への改訂により推奨バージョンがそれぞれ引き上げられました。（SPDX：2.2.1→3.0.1、CycloneDX：1.5→1.6）特に、SPDXのv3.0以上については、これまで一般的に利用されていたv2.3と比較して、刷新されている部分があります。各SBOMツールでもv3.0への対応要求を今後予定ているツールがほとんどのため、すでにSBOMツールをに導入済みの場合は、対応可能か確認が必要となります。

データフォーマット

SBOM自体は、機械可読可能なテキストデータのリストです。そのためTR-03183では情報のSBOMのファイル形式として「XML」と「JSON」の2つを採用することと明記しています。これらの特長は、いずれも機械可読性が高く、異なるシステム間での相互運用性を確保しやすいということです。特に、XMLはスキーマによる厳格な構造定義が可能であり、官公庁や大規模システムでの利用実績が豊富です。他方、JSONは軽量で扱いやすく、クラウドネイティブな環境やAPI連携に適していることから、近年のSBOM活用において広く採用されています。TR-03183がこの2形式を推奨する背景には、セキュリティと実装効率の両立を図る意図があると考えられます。

4章：どの項目が必要か

続いて、SBOMにどのような情報を記載しておくべきかについて確認していきましょう。CRAでは、SBOMに何を含めるべきかを2025年9月時点では定めていません。したがって本稿で取り上げているTR-03183、さらに、CISA（Cybersecurity and Infrastructure Security Agency：米国サイバーセキュリティ・インフラストラクチャセキュリティ庁）「2025 Minimum Elements for a Software Bill of Materials （SBOM）」³で定められている項目から、記載が必要となる情報を理解しておく必要があります。

TR-03183では、「SBOM自体に必要なデータ項目」「各コンポーネントで必要なデータ項目」の2種類で必要な情報を定義しています

※CISAの「2025 Minimum Elements for a Software Bill of Materials（SBOM）」は公表された2025年時点で草案のため、内容が変更となる可能性があることにご注意ください。

※CRAのSBOM要件を具体化する正式な整合規格は、2026年8月30日を目途に作成される見込みです（2025年4月8日CEN/CENELECワークショップ「Cyber Resilience Act and the horizontal standards」資料より）。

SBOM自体に必要なデータ項目

この項目（図表4）では、主にSBOMが誰によって作成されたか、またいつ作成されたものであるかを示すための情報が必要であると定義しています。

各コンポーネントで必要なデータ項目

この項目（図表5）では、セキュリティの観点やライセンス管理の観点においてどのような情報が各コンポーネントで必要となるかを定義しています。

※TR-03183の版がv2.0.0からv2.1.0へ変更された際に、ライセンスの項目が「Associated licences」から「Distribution licences」へ変更されています。これについてBSIは、「一般的に、定義されている項目は、使用するSBOMフォーマットの仕様（CycloneDXやSPDXの特定バージョン）に従って記入すべき」としています。このような定義としているのは、フォーマットの仕様によってライセンス項目の定義が若干異なるため、情報の取得方法に基づいてライセンス項目を区別するためです。

5章：どのタイミングで作成されるべきか

SBOMの作成タイミング

最後は、「いつSBOMを生成すべきか」という問題について説明します。TR-03183は、SBOMを作成するタイミングを以下の6つに分類しています。

1. Design SBOM：新しいソフトウェア成果物に含まれる予定のコンポーネントに基づいて作成
2. Source SBOM：開発環境、ソースファイル、および使用される依存関係に基づいて作成
3. Build SBOM：ソースコードをコンパイル・ビルドした成果物から作成
4. Analyzed SBOM：ビルドプロセスの後に、実行ファイル、パッケージ、コンテナ、仮想マシンイメージなどの成果物を分析して作成
5. Deployed SBOM：ソフトウェアを実行しているシステムを用いて、実行中のコンポーネント、外部呼び出し、動的に読み込まれるコンポーネント（メモリ上）を記録するSBOM
6. Runtime SBOM：実行中のソフトウェアの状態を監視して作成

この中でTR-03183が推奨しているのは、「3. Build SBOM」です。ビルド時の生成が最適解であるとする理由は、その正確性と自動化の容易さにあります。

例えば、ソースコード上ではライブラリのバージョンが「^1.0（1.0以上）」のように曖昧に指定されていても、実際のビルドプロセスでは「1.2.5」のような具体的なバージョンが適用され、組み込まれます。ビルドSBOMは、この確定したバージョンの部品表を最も正確に捉えることができるのです。

さらに、このプロセスは完全に自動でCI／CDパイプラインに組み込むことが可能です。これにより、人為的なミスの発生を排除できます。ただし、開発段階でのみ使用するテストライブラリや、製品には含まれないツールまで、誤ってSBOMの対象に含めてしまうと、管理が複雑になるだけでなく、脆弱性スキャンにおいて不要なノイズ（誤検知）が増える原因となります。そのため、まずは製品として出荷されるバイナリやコンテナイメージを基準とし、それに含まれるコンポーネントを正確にリスト化することが前提となります。

バージョン毎の作成

TR-03183が定める要件の一つが、SBOMは「特定のソフトウェアバージョンに対する不変のスナップショットである」という原則です。これは、たとえ軽微なバグ修正であっても、新しいバージョンとして製品がリリースされる際には、必ず新しいSBOMを生成・紐付けしなければならないことを意味します。このルールを徹底することで、脆弱性インシデント発生時に「どのバージョンの製品が影響を受けるか」を正確に特定し、完全なトレーサビリティを確保することが可能になります。

まとめ

CRAが求める「SBOMにおけるトップレベル」は、あくまで最低限の取り組みであり、社会全体で挑戦していくためのスタートラインです。他方、TR-03183では、「どこまで可視化するか」「どのフォーマットを選ぶか」「どのタイミングで生成するか」といった実践的な指針を提供しています。SBOMが単なる法令対応ではなく、ソフトウェアサプライチェーン全体の健全性を守るための基盤であることを踏まえ、実践的なSBOMを作成することで、自社製品のソフトサプライチェーンの可視化および継続的な脆弱性管理に向けた土台を築くことが、市場において信頼を勝ち取る前提条件となっていくでしょう。

参考文献

https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

² BSI, 2025. “Technical Guideline BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products Part 2: Software Bill of Materials (SBOM)”
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2_v2_1_0.pdf?__blob=publicationFile&v=5

³ CISA,2025. “「2025 Minimum Elements for a Software Bill of Materials (SBOM) ”
https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom