顧客からSBOMを求められたら：サプライヤー向けガイド

このガイドは、製造業のサプライチェーンの中にいるサプライヤー向けです。ECU、ディスプレイ、コントローラー、ゲートウェイ、ドライブ、組み込みLinuxスタック、ファームウェアモジュールなどを供給している方が対象です。ソフトウェアを販売していて、顧客から1回限りの依頼が届いた場合は、そのケースを扱う顧客からのSBOM提出依頼への答え方から始めてください。

OEMが今、SBOMを求める理由

OEMからのSBOMの依頼は、たいていOEM自身の規制が契約を通じてあなたのもとに届いたものです。どの規制かによって、OEMが何を持っていなければならないか、そしてそのうちどれだけがあなたに引き継がれるかが決まります。

Cyber Resilience Act

Cyber Resilience Act、Regulation (EU) 2024/2847のもとでは、デジタル要素を含む製品には「個別に市場に出されるソフトウェアまたはハードウェアのコンポーネント」が含まれます（第3条第1号）。EUで単体で販売するコンポーネントはそれ自体が製品であり、あなたはその製造者として、自らSBOMを作成する義務を負います。附属書I第II部第1項は、「一般的に使用され、機械可読なフォーマットで、少なくとも製品のトップレベルの依存関係をカバーする」SBOMを求めています。コンポーネントがほかの製品への組み込みを意図している場合、取扱説明には、必須要件を満たすために「インテグレーターが必要とする情報」も記載しなければなりません（附属書II第8項(f)）。

OEMにも、あなたに及ぶ義務があります。OEMは「第三者から調達したコンポーネントを組み込む際に相当の注意を払う」必要があり（第13条第5項）、組み込んだコンポーネントに脆弱性を見つけた場合は、そのコンポーネントを製造または保守する個人または事業体に報告しなければなりません（第13条第6項）。2026年7月の欧州委員会のCRAガイダンスは、相当の注意のエビデンスは「コンポーネントの製造者から入手した文書で構成されうる」としており、SBOMには言及していません。実際には、OEMが求める文書はSBOMであることが多いです。報告義務は2026年9月11日から適用され、規則全体は2027年12月11日から適用されます。置き換える対象のコンポーネントと同じ仕様で製造されたスペアパーツは除外されます（第2条第6項）。規則のそのほかの内容については、CRAとはとCRAガイドをご覧ください（引用は英語版からの訳）。

車両

CRAは、車両型式認証規則であるRegulation (EU) 2019/2144の対象となる製品には適用されません（第2条第2項(c)）。型式認証を受ける車両のコンポーネントは代わりに車両の規則のもとで市場に出され、それらの規則はSBOMに一切言及していません。

UN Regulation No. 155（サイバーセキュリティ）は、製造者に対し、「サプライヤーに関連するリスクが特定され管理されていることを示すために、サプライチェーンを通じて」情報を収集・検証すること（5.1.1(a)）、サイバーセキュリティマネジメントシステムが「契約したサプライヤー、サービスプロバイダー、または製造者の下部組織との間に存在しうる依存関係をどのように管理するか」を示すこと（7.2.2.5）、そして「認証を受ける車両型式について、サプライヤーに関連するリスクを特定し管理する」こと（7.3.2）を求めています。
UN Regulation No. 156（ソフトウェアアップデート）は、初期および更新後のすべてのソフトウェアバージョンを一意に識別できること（7.1.1.2）と、RX Software Identification Number（RXSWIN）ごとに「RXSWINに関連するすべてのソフトウェアを記述した監査可能な登録簿」（7.1.2.3）を求めています。
ISO/SAE 21434は、OEMとサプライヤーの間のサイバーセキュリティ作業を分散アクティビティとして構成し、その分担をサイバーセキュリティインターフェース合意で取り決めます。
Auto-ISAC SBOM Informational Report（2025年2月）は、業界自身のガイダンスです。

自動車業界では、SBOMは法的要件ではなく契約上の要件として届きます。

産業オートメーション

IEC 62443-4-1は、産業オートメーション・制御システム製品のサプライヤーに適用されます。SBOMを名指ししてはいませんが、プラクティス6のセキュリティ関連の問題の管理（DM-1～DM-6）と、プラクティス7のセキュリティアップデートの管理（SUM-1～SUM-5。SUM-3「Dependent component or operating system security update documentation」を含む）で、SBOMがエビデンスになります。

機械

機械に関するRegulation (EU) 2023/1230は2027年1月20日から適用され、SBOMには言及していません。改ざんに対する保護に関する必須要件（附属書III、1.1.9）は、適合性にとって重要なソフトウェアを識別して保護すること、機械が「安全に動作するために必要な、機械にインストールされたソフトウェアを識別」できること、そのソフトウェアへの介入のエビデンスを収集することを求めています。デジタル要素を含む機械は、型式認証を受ける車両とは異なりCRAの対象にもなるため、機械メーカーは今、サプライヤーにSBOMを求めています。機械メーカー向けCRACIと産業用IoTをご覧ください。

NIS2と認証を取得している顧客

半導体などの分野で必須事業体や重要事業体に供給している場合、NIS2第21条第2項(d)は、顧客にサプライチェーンのセキュリティへの対処を求めています。SBOMを名指ししてはいません。顧客はこれを質問票に落とし込み、ISO/IEC 27001附属書Aの管理策5.21と8.8でSBOMがエビデンスになります。ISO 27001、SOC 2、NIS2のエビデンスとしてのSBOMをご覧ください。

規制の比較

規制	適用対象	SBOMへの言及	サプライヤーに及ぶもの
Cyber Resilience Act	EU市場のデジタル要素を含む製品。個別に販売されるコンポーネントを含む	あり。附属書I第II部(1)	コンポーネントを自ら市場に出す場合は直接。OEMの相当の注意（第13条第5項）と脆弱性の報告（第13条第6項）を通じても
UN R155とR156	型式認証を求める車両メーカー	なし	契約を通じたサプライヤーリスク管理（R155 7.2.2.5、7.3.2）とソフトウェアの識別（R156）
ISO/SAE 21434	道路車両のサイバーセキュリティエンジニアリング。OEMとサプライヤー	公開されている概要にはなし	分散アクティビティとサイバーセキュリティインターフェース合意
IEC 62443-4-1	産業オートメーション・制御システム製品のサプライヤー	なし	製品サプライヤーであれば直接。SBOMはDMとSUMのエビデンスになる
機械に関する規則（EU）2023/1230	EU市場の機械と関連製品	なし	ソフトウェアの識別と保護（附属書III 1.1.9）。CRAも並行して適用
NIS2	必須事業体と重要事業体	なし	サプライチェーンのセキュリティに関する質問票と契約条件（第21条第2項(d)、第21条第3項）

どの経路であれ、顧客が必要とするものは同じです。納品するソフトウェアのバージョンごとの正確なSBOMです。

OEMが一般的に求めるもの

要件はOEMごとに異なりますが、行き着くリストは同じです。最初の納品の前に、自社のSBOMをこのリストと照らし合わせてください。

要件	一般的な期待
フォーマット	CycloneDXまたはSPDX、JSONまたはXMLで、仕様の最低バージョンを指定。BSI TR-03183-2はCycloneDX 1.6以降、またはSPDX 3.0.1以降を定めています。
フィールド	CISA 2026 Minimum ElementsまたはBSI TR-03183-2に沿ったもの：作成者、タイムスタンプ、そしてコンポーネントごとの名前、バージョン、作成者、識別子
識別子	コンポーネントを脆弱性データベースと照合できるよう、エコシステムにあればpackage URL、なければCPE
ライセンス	SPDXライセンス識別子。OEMのライセンス専門家はこれを読んでコピーレフトなどのライセンスリスクを判断します。
ハッシュ	納品する各バイナリのハッシュ。OEMはこれで、SBOMが受け取ったファイルを記述していることを確認できます。BSIはSHA-512を求めています。
深さ	トップレベルだけでなく、推移的依存関係まで
粒度	納品するソフトウェアのバージョンまたは品番ごとに1つのSBOM
提供と対応	提供経路と、脆弱性に関する質問への回答期限

多くのOEMは、届いた時点でこれらを自動的にチェックします。顧客が何をチェックし、どのツールを使うかはSBOM品質チェックリストを、ファイルの中でフィールドがどう見えるかはSBOMの例をご覧ください。

オープンソースがほとんど、またはまったくない場合のSBOM

モデルベースのコード生成による独自ファームウェアを搭載したベアメタルのECUやコントローラーの正直なSBOMは、短くなることがあります。独自のアプリケーション、自社のブートローダー、半導体ベンダーのライブラリやキャリブレーション、そして暗号ライブラリなどのオープンソースです。それは有効な答えです。ルールは次のとおりです。

独自のコンポーネントは、自社の識別子で列挙する：名前、バージョン、そして作成者として自社。
中身を確認できないベンダーのライブラリなど、既知の未知を明記する。
網羅的に見せるためにSBOMを水増しせず、小さいからといってオープンソースのライブラリを省かない。

Linuxベースのディスプレイやゲートウェイではその逆で、カーネル、ブートローダー、ベースシステムのパッケージを含め、コンポーネントは数百から数千になります（コネクテッドデバイスを参照）。自社のアプリケーションといくつかのライブラリしか列挙していないSBOMは、受け取る側のチームが真っ先に指摘するものです。Yoctoでビルドしている場合は、スキャナーがYoctoビルドの中身を見逃す理由をご覧ください。

契約：最初の納品の前に合意すべきこと

条項	重要な理由
対象となる製品とソフトウェアバージョン	バリアントやサービスリリースにSBOMが必要だったかどうかで、後から揉めないため
フォーマットと仕様バージョン	顧客の受け入れパイプラインは、それ以外を差し戻すことがある
フィールドと準拠するフレームワーク	「BSI TR-03183-2 v2.1.0」や「CISA 2026 Minimum Elements」はテストできるが、「完全なSBOM」はテストできない
納品のきっかけ	リリースごと、OEMに出荷するソフトウェアバージョンごと、修正ごと
提供経路	OEMのサプライヤーポータル、安全なファイル交換、またはNDAのもとでのメール
機密保持	SBOMを機密情報として明記したNDAまたは既存の供給契約
利用制限	脆弱性管理とコンプライアンスの目的に限り、同意なく第三者に共有しない
双方向の脆弱性通知	OEMはあなたのコンポーネントで見つけた脆弱性を報告し（CRA第13条第6項）、あなたは自社で見つけたものをOEMに通知する
VEXに関する期待	どのフォーマットか、新しいCVEをどれだけ早く評価するか
保持期間	各バージョンのSBOMをどれだけの期間保管するか。製品のサポート期間に合わせる
正確性と既知の未知	SBOMがカバーできることとできないことについての誠実な条項は、双方を守る

CISAのSBOM Sharing Primerも、自動車のケースを同じように説明しています。SBOMの依頼は「標準的な情報交換の合意（たとえば秘密保持契約、サイバーセキュリティインターフェース合意、開発インターフェース合意）に含まれる」としています（英語原文の訳）。

知的財産を漏らさずに共有する

SBOMはソースコードではありません。列挙するのはコンポーネントの名前、バージョン、作成者、ライセンス、ハッシュ、関係です。あなたのコード、アルゴリズム、キャリブレーションデータ、設計は含まれません。

CRAは、製造者にSBOMの公開を義務づけていません（前文77）。SBOMは、理由を付した要請に応じて市場監視当局に提出するものです（附属書VII第8項）。
CISAの共有に関するガイダンスは、独自ソフトウェアの一般的な経路として、NDAのもとでのメール、顧客のサプライヤーポータルや安全な文書交換、または自社のアクセス制御付きポータルを挙げ、機密保持とアクセスは契約で定めるとしています。
実践的な選択肢：契約のもとでOEMごとに1つの完全なSBOM。社内のプロジェクト名を明かさない、独自部分の識別子。そして別のVEX文書。これにより、SBOMを送り直さずに脆弱性のステータスを更新できます。

頻度と、納品後に起こること

納品するソフトウェアのバージョンごとに新しいSBOMを、OEMが書き込みや登録に使うのと同じ識別子で。車両の場合、これはR156のソフトウェア識別に結びつきます。
修正したSBOM：送ったSBOMに誤りを見つけたとき。
VEXステートメントまたはアドバイザリ：脆弱性を評価したとき。

続く問い「CVE-Xの影響を受けていますか？」は、次の大きな脆弱性とともにやってきます。納品したバージョンごとに答えられるよう準備してください。それができるのは、各バージョンのSBOMを保管している場合だけです。

VEX：顧客が次に求めるもの

VEX文書は、製品が脆弱性の影響を受けるかどうかを示します。CISAのMinimum Requirements for VEX（2023年4月）は、4つのステータスを定めています：not_affected、affected、fixed、under_investigation。not_affectedのステートメントには、5つの根拠のいずれか、またはそれに代わる影響の説明（impact statement）を記載すべきとされています。

component_not_present
vulnerable_code_not_present
vulnerable_code_not_in_execute_path
vulnerable_code_cannot_be_controlled_by_adversary
inline_mitigations_already_exist

affectedのステートメントには、顧客が何をすべきかを示すアクションの説明（action statement）が必要です。VEXには3つのフォーマットがあります：CSAF 2.0のVEXプロファイル、CycloneDX VEX、OpenVEXです。YoctoのSPDX 3.0出力には、デフォルトでVEXデータが含まれます（SPDX_INCLUDE_VEX変数）。

具体例。LinuxベースのディスプレイにOpenSSL 3.0.8が搭載されています。CVE-2023-0464は、ポリシー制約を含むX.509証明書チェーンの検証時に過剰なリソースを消費する問題です。ポリシー処理はデフォルトで無効になっており、ディスプレイのソフトウェアはこれを有効にしません。サプライヤーは、次のようなOpenVEXステートメント（説明用の例）を送ります。

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

SBOMを再現可能な形で作成する

ビルドの方法	SBOMを作成する現実的な方法
CIでビルドするソフトウェア	納品するソフトウェアを作成するビルドでSBOMを生成し、リリースと一緒に保管する
Yoctoベースの組み込みLinux	Yocto自身のSPDX出力（`create-spdx`）を、抜け落ちるものを確認したうえで使う。またはYoctoビルドの記録
モデルベースツールによるベアメタルのファームウェア	テキストエディターではなくジェネレーターライブラリやツールを使い、リリースごとに保守し、送付前に検証する
組み込むサードパーティのバイナリ	自社のサプライヤーにSBOMを求める。届くまではバイナリ解析で代用

どの経路であれ、送る前にファイルを検証してください。SBOM品質チェックリストには顧客が実行しそうなバリデーターを、CycloneDXとSPDXの比較にはフォーマット選びのヒントを、SBOM生成の標準化にはチーム間でそろえる方法をまとめています。

CRACIの役割

GitHub Actionsでビルドしているサプライヤー向けに、CRACIはGitHubホステッドランナーを置き換え、すべてのビルドからSBOMを記録します。そのため、納品する各バージョンにはすでにSBOMがあります。

SBOMには、推移的依存関係を含め、ビルドが実際に取り込んだものが、パッケージごとのpackage URLとすべてのコンポーネントの宣言されたライセンスとともに列挙されます。
各ジョブのSBOMには完全性の状態が付くため、送る前に何を送ろうとしているのかがわかります。
SBOMはCycloneDXまたはSPDXでエクスポートでき、CRACIはVEXに対応しています。
監視対象のSBOMは、新しい脆弱性が公開されるたびに再評価され、ビルド履歴は、保持期間内であれば、どのビルドに脆弱な依存関係が含まれていたかを示します。
YoctoビルドはCRACIのランナーで実行でき、ドキュメントも用意されています。
サードパーティのSBOMを追加できるため、購入したコンポーネントも自社のビルドと並べて監視できます。

CRACIが適さない場合

CIを使っていない、またはGitLab、Jenkins、ビルドサーバーでビルドしている。現在CRACIが対応しているのはGitHub Actionsのみで、ほかのCIシステムはロードマップに掲載されています。
ファームウェアを、パッケージを取得しないモデルベースツールで生成している。その場合、ビルドの記録はほとんど役に立ちません。
多くのOEM向けにSBOMを共有ポータルでホストしたい、またはSBOMに署名したい。CRACIはどちらも提供していません。
ビルドを自社のインフラで実行しなければならない。顧客ホスト型ランナーはロードマップに掲載されています。
顧客が、ISO 27001認証やNIS2質問票への回答など、自社のセキュリティマネジメントの証明を求めている。SBOMはその一部のエビデンスであり、認証ではありません。CRACI自身のISO 27001認証の対象はCRACIのサービスであり、あなたのサービスではありません。

サプライヤー向けSBOM：よくあるご質問

顧客のOEMからSBOMを求められました。提供する義務はありますか？

多くの場合、求めているのは法律ではなく契約です。デジタル要素を含むコンポーネントを自らEU市場に出す場合は、Cyber Resilience Actにより自社のSBOMが必要です。そうでなければ義務はOEMにあり、OEMは相当の注意と供給契約を通じてそれをあなたに引き継ぎます。

製造者に販売するコンポーネントにCRAは適用されますか？

コンポーネントを個別にEU市場に出すなら、適用されます。第3条第1号は、個別に市場に出されるソフトウェアまたはハードウェアのコンポーネントを含めています。OEMの製品に組み込まれた形でのみ市場に出るなら、製造者はOEMであり、OEMがあなたのコンポーネントについて相当の注意を払う必要があります（第13条第5項）。型式認証を受ける車両のコンポーネントはCRAの対象外です（第2条第2項(c)）。

UN R155やISO/SAE 21434はSBOMを義務づけていますか？

いいえ。R155はSBOMに一切言及しておらず、車両メーカーにサプライヤー関連のリスク管理を求めています。ISO/SAE 21434は、インターフェース合意を通じてサプライヤーとのサイバーセキュリティ作業を構成します。自動車業界では、SBOMは契約上の要件として届きます。

OEMはどのフォーマットとフィールドを期待しますか？

通常は、CISA 2026 Minimum ElementsまたはBSI TR-03183-2に沿った、JSONまたはXMLのCycloneDXかSPDXです。作成者とタイムスタンプ、そしてコンポーネントごとの名前、バージョン、作成者、package URLまたはCPE、ライセンス、ハッシュを、推移的依存関係とともに記載します。

更新したSBOMはどのくらいの頻度で送る必要がありますか？

納品するソフトウェアのバージョンごと、誤りを修正するたび、そして脆弱性を評価したときにはVEXステートメントまたはアドバイザリとともに送ります。納品のきっかけは契約で合意してください。

SBOMを共有すると知的財産が漏れますか？

いいえ。SBOMが列挙するのはコンポーネントの名前、バージョン、作成者、ライセンス、ハッシュ、関係であり、ソースコード、アルゴリズム、キャリブレーションデータではありません。NDAまたは供給契約のもとで、利用を脆弱性管理とコンプライアンスに限定して共有してください。CRAは公開を求めていません。

VEXとは何ですか？顧客から求められますか？

VEXは、製品が脆弱性の影響を受けるかどうかを、not_affected、affected、fixed、under_investigationで示し、not_affectedには根拠を添えます。出荷しているコンポーネントで次に広く報じられる脆弱性が出たあと、求められると考えておいてください。

当社のECUファームウェアにはオープンソースがありません。SBOMはどうなりますか？

短く、正直なものになります。独自のアプリケーション、ブートローダー、半導体ベンダーのライブラリやキャリブレーション、そして暗号ライブラリなどのオープンソースを、それぞれ自社の識別子で記載し、既知の未知も明記します。水増しはしないでください。

顧客がSBOMを求めています：コンポーネントとソフトウェアのサプライヤー向けガイド