外部インターフェース有無でのトリアージ例
（BT/USB/OTA等：まず何を見るか）
CVE対応で優先度判断がぶれる最大の理由の1つが、「外部から届くのか」を見ないまま深刻度だけで判断してしまうことです。
同じ脆弱性でも、
- Bluetooth が有効で近距離から触れる製品
- USB経由でしか成立しない製品
- OTAで更新経路を持つ製品
- そもそも車外からの入口が無い製品
では、実務上の優先度が大きく変わります。
つまり、CVSSの点数やCVE要約だけでは足りません。
外部インターフェースの有無、既定状態、成立条件 を見て、はじめて「今すぐ動くべきか」が決まります。
先に結論：インターフェースを見るときは「3点」だけでよい
外部インターフェース有無でのトリアージは、最初はこの3点だけで回せます。
① 入口があるか
BT / USB / OTA / Wi-Fi / 診断ポートなど、外部から接続できる経路があるか
② 既定状態で有効か
出荷状態で有効なのか、サービスモードや設定変更が必要なのか
③ 成立条件がそろうか
認証、近接、物理操作、更新権限など、攻撃に必要な条件が現実的に満たせるか
この3点で見れば、最初の結論は大きく外しません。
なぜ外部インターフェースが重要なのか
サプライヤー実務で知りたいのは、「この脆弱性が存在するか」より、「車外/外部から届くのか」 です。
たとえば同じメモリ破壊の脆弱性でも、次のように前提が異なれば優先順位もOEMへの説明も変わります。
- OTA経由で遠隔から入力できる （高優先）
- Bluetoothペアリング範囲でしか届かない （中優先）
- USBメディアを物理的に挿さないと届かない （条件付き）
- 工場モードでしか有効にならない （低優先/要説明）
この違いを整理しないと、全部が「重大」に見えて現場が回らなくなります。
まず分類：外部インターフェースは4種類で考える
現場で迷わないよう、入口を4つに分けると整理しやすいです。
OTA、テレマティクス通信、クラウド連携、Wi-Fi、セルラー
特徴：遠隔から成立し得るので、一般に優先度が上がりやすいです。
Bluetooth、NFC、近距離ペアリング機能
特徴：物理接近が必要でも、車外から成立し得るため、「完全な閉域」とは言いにくいです。
USB、SDカード、物理デバッグポート、サービスコネクタ
特徴：物理操作が必要なので優先度は下がることがありますが、整備現場・ユーザー操作・工場工程で現実的に使われるなら無視できません。
OBD/診断ポート、工場書き込み治具、サービスモード、開発/保守用インターフェース
特徴：出荷状態では限定されていても、条件付きで成立する入口として評価が必要です。
手順：外部インターフェース有無でトリアージする（5ステップ）
該当コンポーネントが“どこで使われているか”を切る
最初に見るべきは、脆弱なコンポーネントが どの製品・どのECU・どの機能 に入っているかです。ここでSBOMや部品表が効いてきます。
- 対象製品名 ／ 対象版数
- 搭載箇所（ECU/モジュール）
- 関係する機能（通信、更新、メディア読込など）
インターフェース評価は、対象箇所が切れて初めて意味を持ちます。
入口があるかを Yes / No / 不明 で切る
次に、その機能に対して外部インターフェースがあるかを確認します。最初から細かく書きすぎず、まずはこの3値で十分です。
- Yes： 外部から接続可能な入口がある
- No： 車外/外部から到達する入口が無い
- 不明： 資料や担当確認がまだ必要
この段階で「No」なら、いったん not_affected 候補 に置けます。ただし、次のStep3で前提条件を確認します。
既定状態で有効かを確認する
入口があっても、出荷状態で有効かどうかで意味が変わります。
- Bluetooth機能があるが、標準構成では無効
- USBポートはあるが、当該モードでは読込機能が無効
- OTA機構はあるが、対象ECUは更新対象外
- 診断ポートはあるが、認証ツールがないと成立しない
ここでのポイントは、「存在する」ことと「通常状態で成立する」ことを分けることです。この違いを書けると、OEM照会でかなり強くなります。
成立条件を短文で書ける形にする
最終的に必要なのは、論文のような説明ではなく、判断の根拠が伝わる1〜3行です。
・USB経由でのみ成立するが、量産設定ではメディア読込機能を無効化
・OTAは存在するが、対象モジュールは更新対象外
・OBD経由で成立し得るが、認証済み整備ツールとサービスモードが必要
この一文があるだけで、「影響なし」の質が上がります。
VEXの結論に落とす
ここまで来れば、結論はかなり決まります。
- not_affected 対象コンポーネントは搭載しているが、外部IFが無い。外部IFはあるが当該機能では使われない。成立に必要な設定/認証条件が通常運用では満たされない。
- affected OTAやBTなど外部から現実的に届く入口があり、出荷状態で有効で、対象機能が実行経路に入っている。
- under_investigation 搭載は確認できたが、入口や既定状態が未確認。診断/工程系IFの扱いが曖昧。顧客別派生やオプション構成の差分確認が必要。
BT / USB / OTA の具体例
ここは実務で使いやすいように、短く具体例で見ます。
Bluetooth
影響あり寄り
出荷状態でBluetooth機能が有効、対象機能に直接入力が届く
影響なし寄り
Bluetooth自体はあるが、当該コンポーネントを使う経路に乗らない
USB
影響あり寄り
一般ユーザーが使えるUSBポートから、脆弱なメディア処理機能が呼ばれる
影響なし寄り
物理接続が必要で、量産設定では機能無効、またはサービスモード限定
OTA
影響あり寄り
OTAが出荷状態で有効、対象モジュールが更新対象、遠隔経路で成立
影響なし寄り
OTA基盤は存在するが、対象コンポーネントは更新対象外／別経路でしか使われない
そのまま使える：判断メモのテンプレ
以下を台帳やチケットに貼っておくと便利です。
自社の製品構成に合わせた脆弱性トリアージの判断基準を整理したい方はご相談ください。
【無料】オンライン相談を予約するFAQ：外部IFでのトリアージについて
いいえ。重要なのは、存在することではなく、通常状態で有効か・実行経路に入るか・成立条件が現実的かです。
少なくとも「完全な閉域」とは言いにくくなります。ただし、機能無効・未使用・認証必須などの条件があれば、not_affected の根拠になり得ます。
遠隔更新経路があるため優先度は上がりやすいですが、対象モジュールが更新対象か、通常状態で有効かを確認してから判断します。
量産時は閉じていても、条件付きで成立する入口として扱うのが安全です。「通常運用では成立しない」なら、その前提を書いた上で判断します。
自社の判断基準をシステムに組み込みませんか？
Auto PSIRT Cloudなら、製品ごとの「外部IFの有無」や「機能の有効/無効」を事前に登録しておくことで、新たなCVEが発見された際、AIが自動で到達性を推測し、一次トリアージを行います。