影響ありの場合の最小対応
（回避策→暫定→恒久の順）
脆弱性対応で一番迷いやすいのは、「影響あり」と分かった後に、何から手を付けるかです。
ここで順番を間違えると、現場の対応プロセスはすぐに崩れてしまいます。
- いきなり恒久対策だけ議論して、今日できる止血が抜ける
- 回避策だけ出して終わり、修正版の計画が無い
- 暫定対策と恒久対策が混ざり、OEMへの回答が曖昧になる
- 結論は出したのに、対象版数や証跡が残らず、追加質問で再炎上する
実務で大事なのは、完璧な答えを最初から出すことではありません。
「いま止血する」「当面のリスクを下げる」「最終的に直す」 の順番で、対応を分けることです。
この記事では、影響あり案件の最小対応を
回避策 → 暫定対策 → 恒久対策
の3段階で整理し、兼務体制でも破綻しないように 手順（ステップ）・成果物（証跡）・文面の型 まで落とし込んで解説します。
先に結論：影響あり案件は「3層」で考える
影響ありの時に一番大切なのは、対応を1つにまとめないことです。
まず、次の3つの層（レイヤー）に分けて考えを整理してください。
1 回避策 (Workaround)
ユーザーや運用側が 今すぐできる回避 です。
・問題機能を使わない
・外部接続を切る
・該当インターフェースを停止する
・暫定的に対象製品の利用範囲を制限する
2 暫定対策 (Mitigation)
製品や運用を 一時的に安全寄りへ寄せる処置 です。
・設定変更
・機能無効化
・アクセス制御の追加
・監視強化
・サービス手順の変更
3 恒久対策 (Remediation)
脆弱性の 原因そのものを除去する修正版・設計変更 です。
・パッチ適用
・ライブラリ更新
・実装修正
・機能再設計
この順で考えると、「今日やること」「次にやること」「最終的にやること」が分かれ、現場が止まりにくくなります。
回避策・暫定対策・恒久対策の違い
ここは混同されやすい（特に回避と暫定）ので、少し丁寧に整理します。
回避策は“使い方”を変える
回避策は、製品のコードや設定を直すのではなく、使い方や接続の仕方を変えてリスクを避ける ものです。
最も早く出せる（即効性がある）代わりに、機能制限を伴うためユーザーや顧客の運用負荷が増えます。
暫定対策は“状態”を変える
暫定対策は、製品や環境の設定を変えて、攻撃の成立条件を崩す ものです。
まだ根本修正ではないため、「この設定を維持している間だけ安全」という前提条件と有効期限を明示する必要があります。
恒久対策は“原因”を消す
恒久対策は、最終的に 脆弱性の原因そのものを完全に除去する ものです。
実装、試験、承認、配布といった正式なリリースプロセスが必要になるため、最も時間がかかります。
実務のポイント
OEMや顧客に対しては、この3つを混ぜずに書くことが非常に重要です。特に「回避策」と「暫定対策」を分けて回答文に記載すると、対応の論理性と見通しが伝わりやすくなり、信頼感に繋がります。
手順：影響あり案件を最小対応で回す（6ステップ）
1対象版数を先に切る
まず最初にやるべきは、どの製品・どの版数が対象か を切ることです。ここが曖昧だと、どんな対策を議論してもすべて宙に浮きます。
最低限、「対象製品名」「対象版数（暫定でも可）」「対象箇所（ECU/モジュール/機能）」「依存コンポーネント名と版数」を特定します。ここでは精緻なSBOMや構成表の存在が物を言います。
2いま出せる回避策を洗う
次に、「今日できること」を洗います。ポイントは、技術的に美しい解決策かどうかではなく、相手のリスクを今すぐ下げられるかです。
例：問題機能の利用停止、外部インターフェースの物理的/論理的遮断、管理者だけに利用を限定する、手動運用への切り替えなど。この段階では、完璧さより即効性が最優先です。
3暫定対策を決める
回避策（利用停止など）だけでは運用が長持ちしない場合、次に暫定対策を出します。ここでは、製品側やシステム側の設定変更を伴うことが多いです。
例：Bluetooth機能の無効化、USB読込機能の停止、OTA対象からの除外、診断モードの制限、閾値や権限設定の厳格化など。
【重要】 ここで忘れてはいけないのが前提条件を書くことです。「この設定のままなら攻撃は成立しない」という説明が無いと、後で設定を戻された時に覆ります。
4恒久対策を“予定”として置く
次に、恒久対策を置きます。ここでは「何を直すか」「どの版で直すか」「いつ直すか」「どう届けるか（OTA/リコール等）」の4点が必要です。
恒久対策のリリース時期は、この時点では未確定でも構いません。しかし、「未定」と書いて放置するのではなく「次回更新日」 を必ず置いてください。OEMや顧客が一番嫌うのは、影響ありと言われたまま先が見えなくなることです。
5証跡をまとめる
影響あり案件では、証跡管理が特に重要になります。監査の際に必ず求められます。
最低限、「対象版数の根拠（SBOM等）」「影響ありと判断した技術的根拠」「回避策/暫定対策が有効である根拠」「恒久対策の社内チケットや計画書」「次回更新日の記録」を揃えます。
提出資料に証跡を全部添付する必要はなく、証跡IDや参照先URLが追えれば十分です。
6文面に落とす（回答書の作成）
最後に、対外回答として文面化します。記載の順番は以下の骨格が基本です。
[結論：影響あり] → [対象版数] → [回避策] → [暫定対策] → [恒久対策] → [次回更新日] → [証跡参照先]
この順番で書くと、相手（OEMのセキュリティ担当者）が読みやすく、不要な追加質問も劇的に減ります。
そのまま使える：最小対応メモ（骨子）
社内での情報整理や、OEMへの回答文のドラフト（骨子）として、次のフォーマットがそのまま使えます。チャットツールや社内チケットのテンプレートに登録しておくと便利です。
※ この程度の箇条書きでも、頭の中だけで処理するよりずっと安定して対応を進めることができます。
自社に必要な脆弱性対応の範囲や、OEMから求められる回答レベルを整理したい方はご相談ください。
【無料】オンライン相談を予約するよくあるNG例（対応が炎上するパターン）
-
NG1：恒久対策だけ書く
「来年リリース予定の修正版を出します」だけでは、今日から修正版リリース日までの間のリスクをどう下げるか（止血）が完全に抜けており、顧客は不安になります。 -
NG2：回避策だけで終わる
「該当機能を使わないでください」で当面しのげても、恒久対策の計画が提示されないと、同じ問題（機能不全）が永遠に残り続けることになります。 -
NG3：暫定対策の「前提条件」が無い
「設定変更で防げます」と書いても、その設定が維持される条件（例：再起動後も保持されるか、ユーザーが変更できないか）を示さなければ対策として弱いです。 -
NG4：対象版数が曖昧
「影響あり」と回答しているのに、どこからどこまでのバージョンが対象かが曖昧だと、OEMから「じゃああの車種は？このリビジョンは？」と追加質問が延々と続きます。
FAQ：影響ありの時の対応
A. まず対象版数を確実に切り、その上で「今日できる回避策」を洗い出すことです。いきなり恒久対策の議論だけを始めると、現在進行形のリスクに対する現場対応が遅れてしまいます。
A. 回避策は“使い方を変える”対策（例：機能を使わない）、暫定対策は“設定や状態を変える”対策（例：ポートを塞ぐ）です。どちらも恒久対策（原因除去）とは別に整理して伝えた方が、相手に今後の見通しが伝わりやすくなります。
A. はい、問題ありません。ただし「未定」で終わらせず、「〇月〇日に方針を報告します」といった【次回更新日】を必ず設定して回答してください。そうしないとOEMからは放置されているように見えてしまいます。
「対象版数の特定」や「証跡管理」で立ち止まっていませんか？
影響ありと判断された際、最も時間がかかるのは「自社のどの製品の、どのバージョンに影響するか」の特定です。Auto PSIRT Cloudなら、構成表（SBOM）と脆弱性情報を自動で突合し、瞬時に対象版数を特定。回避策や次回更新日といったステータス管理も、そのまま監査の証跡として一元管理できます。