設計部門向け：
影響評価で設計が持つ責任と、
外に出せる責任
「このCVEは当社製品に影響しますか」「影響なしと答えてよい根拠はありますか」。OEMから脆弱性照会が届くと、最後は製品の中身を知る設計部門に問い合わせが集まります。
しかし、設計が脆弱性対応のすべてを背負う必要はありません。設計に残すべきなのは製品影響の技術判断です。受付、情報収集、台帳、期限、証跡、回答文の整理はPSIRTや外部支援へ切り出せます。
この記事では、自動車OEMへ部品を納入する中小サプライヤーを想定し、脆弱性の影響評価で設計部門が持つべき責任と、PSIRT・品質保証・外部支援へ委ねられる範囲を切り分けます。
結論：外に出せるのは作業、設計に残るのは製品判断
最初に責任分界の全体像を示します。製品の中身を知らなければ答えられない判断は設計が持ち、情報を集め、案件を動かし、説明可能な形に整える仕事はPSIRTや外部支援が担います。
| 領域 | 設計部門 | PSIRT・外部支援 |
|---|---|---|
| CVE情報の収集 | 必要に応じて確認 | 主担当にできる |
| SBOM・製品台帳との突合 | 候補の妥当性を確認 | 主担当にできる |
| 対象製品・対象バージョンの確定 | 主担当 | 候補抽出を支援 |
| 脆弱なコードの使用有無・到達可能性 | 主担当 | 一次調査を支援 |
| 「影響なし」の技術根拠 | 主担当 | 文書化を支援 |
| 回避策・修正方針・リリース影響 | 主担当 | 進捗と期限を管理 |
| OEM回答ドラフト・証跡整理 | 技術内容を確認 | 主担当にできる |
| OEMへの正式回答承認 | 必要に応じて関与 | 品質保証・責任者と管理 |
設計部門の責任は、CVEを探すことではありません。そのCVEが、自社の製品構成・実装・使用条件で本当に影響するかを判断することです。
FIRSTの「Consolidated SBOM and CSAF/VEX Operational Framework」では、VEXの製品ステータスとして Not affected、Affected、Fixed、Under Investigation が整理されています。SBOMだけでは製品文脈での実行可能なリスク評価は完結せず、Not affected とする場合も、なぜ影響しないのかを伝えることが重要です。
設計に残る責任1：対象製品・対象バージョンを確定する
OEMからCVEの影響有無を聞かれたとき、最初に確認するのはCVEの深刻度ではありません。脆弱なコンポーネントが、どの製品・どのバージョンに含まれているかです。
| 確認項目 | 設計が関与する理由 |
|---|---|
| 対象製品 | 製品系列、派生品、顧客別仕様を把握しているため |
| 対象バージョン | 出荷版、試作版、保守版の差分を知っているため |
| 搭載ソフトウェア | 実際の組込み構成を知っているため |
| ビルド条件 | 同じ部品名でも設定によって含まれる機能が変わるため |
| サポート期限 | 修正要否や顧客への回答方針に関わるため |
SBOMや製品台帳から候補を出す作業は自動化・外部化できます。一方、「この顧客向け仕様では該当機能を外している」といった製品固有の確定には、設計の知識が必要です。PSIRTが候補を絞ってから設計へ渡せば、設計は探す作業ではなく確認する判断に集中できます。
設計に残る責任2：脆弱なコードが実際に使われるかを判断する
コンポーネントが含まれていることと、製品が影響を受けることは同じではありません。SBOM上で一致しても、脆弱な機能を使っていない、ビルドから除外されている、外部入力から到達できないなどの可能性があります。
| 論点 | 判断例 |
|---|---|
| 脆弱なバージョンか | 製品に含まれる版が影響範囲と一致するか |
| 脆弱な機能を使っているか | 該当APIを呼び出しているか |
| ビルドに含まれているか | オプション機能として除外されていないか |
| 実行時に到達可能か | 外部入力や攻撃経路から到達できるか |
| 設定で無効化されているか | コンパイル時または実行時設定で無効か |
| 他の防御策があるか | 認証、フィルタ、サンドボックスなどで緩和されるか |
スキャナやSBOMは「含まれている可能性」を示せます。しかし、自社製品の構成と使用条件で悪用可能かを確定するには、実装を理解する設計部門の判断が必要です。
設計に残る責任3：「影響なし」の根拠を言葉にする
「影響ありません」だけでは、OEMが再確認できる回答になりません。対象製品、対象版、確認した構成、影響しない条件を残して初めて、会社として説明できる判断になります。
| 弱い回答 | 説明できる回答 |
|---|---|
| 影響ありません | 対象ライブラリは含まれますが、該当機能はビルド時に除外されているため影響しません |
| 使用していません | 対象製品A v1.2のSBOMに当該コンポーネントは存在せず、対象外です |
| 問題ありません | 当該関数は外部入力から到達できない内部処理に限定されるため、現行構成では悪用できません |
| 対策済みです | v1.3で修正版へ更新済みです。v1.2以前には暫定対策を案内します |
PSIRTや外部支援は文章の整形と証跡整理を担えますが、Not affected の技術根拠そのものは、製品構成、使用API、入力経路、保護機構を知る設計が確認します。
設計に残る責任4：修正・回避策・リリース影響を決める
影響ありと判断した後は、パッチ適用、コンポーネント更新、暫定回避策、修正版のリリース時期を決めます。依存関係や副作用、既存顧客への展開まで含むため、ここも設計の責任領域です。
- パッチやバージョンアップを適用できるか
- 暫定回避策が実装・運用上妥当か
- 開発、検証、出荷計画にどの程度影響するか
- OTA、フィールド更新、交換、保守対応が必要か
- 対応しない場合の残存リスクを受容できるか
修正方針の技術判断は設計が持ち、顧客説明、期限管理、承認フロー、証跡保存はPSIRT・品質保証が引き受ける。この分担が、設計の負荷と顧客回答の遅れを同時に減らします。
PSIRTに委ねられるのは、影響評価の交通整理
| PSIRTが持つ業務 | 目的 |
|---|---|
| 脆弱性通知の受付と案件番号の発番 | 個人メールに散らさず追跡できるようにする |
| 対象製品候補の抽出 | 設計へ渡す前に確認範囲を絞る |
| 設計への確認依頼 | 誰に、何を、いつまでに確認するか明確にする |
| SLA・期限管理 | OEMへの回答遅延を防ぐ |
| 回答ドラフトと承認管理 | 設計判断を顧客向けの表現に整える |
| 証跡・履歴管理 | 監査と再照会に備える |
| 月次レビュー | 未解決、遅延、再発防止を確認する |
PSIRTは設計の代わりに製品判断をする組織ではありません。設計が技術判断に集中できるよう、周辺作業を引き受ける組織です。
外部支援に出せる範囲と、社内に残す判断
脆弱性情報の収集、一次調査、SBOMとの機械的突合、公開情報の整理、回答案の下書き、証跡パックの整理は外部支援に切り出せます。
ただし、「影響なしと言い切れるか」「回避策を顧客へ説明してよいか」「修正をどのリリースへ入れるか」の3点は、設計・品質保証・責任者が社内で判断します。
外部の専門家が確認できるのは、公開情報、一般的な影響可能性、SBOM上の一致候補までです。自社製品での使用実態と副作用まで、外部だけで確定することはできません。
RACIで責任線を固定する
Rは実行責任、Aは最終責任、Cは相談先、Iは共有先です。設計をすべての業務でRにすると、PSIRTが転送係になり、設計の負荷は下がりません。
| 業務 | 設計 | PSIRT | 品質保証 | 外部支援 | 経営・部長 |
|---|---|---|---|---|---|
| 脆弱性通知の受付 | I | R | C | C | I |
| 対象製品候補の抽出 | C | R | C | C | I |
| 対象製品・版の確定 | R | C | C | C | A |
| 影響有無の技術判断 | R | C | C | C | A |
| Not affected 根拠作成 | R | C | C | C | A |
| 回避策・修正方針 | R | C | C | C | A |
| OEM回答ドラフト | C | R | R | C | I |
| OEM回答承認 | C | C | R | I | A |
| 証跡保存・月次レビュー | C | R | C | C | A |
役割分担で起きやすい3つの失敗
設計へ、整理しないまま全部聞く
「このCVE、影響ありますか」だけを転送しても、設計は対象コンポーネント、影響バージョン、自社SBOM上の候補、対象製品、回答期限から調べ直すことになります。PSIRTがこの情報をそろえてから渡すだけで、設計の確認負荷は大きく下がります。
「影響なし」の根拠が残らない
担当者が口頭やメールで「この構成なら影響しない」と回答して終えると、半年後の再照会で判断を再現できません。対象製品、対象版、構成、判断理由、確認者、承認者、日付までを案件記録として残します。
外部支援へ製品判断まで丸投げする
外部支援は調査を速められますが、自社製品で本当に使う機能か、顧客環境から到達できるか、修正の副作用を許容できるかは確定できません。調査と判断の境界を契約・手順の両方で明確にします。
設計の負荷を減らすため、先に整える5つ
| 整えるもの | 設計部門にとっての効果 |
|---|---|
| 製品台帳 | 対象製品と派生品を探す時間を減らす |
| SBOM管理 | 搭載部品と対象バージョンの確認を速くする |
| 影響評価テンプレート | 設計へ依頼する確認項目と回答粒度をそろえる |
| Not affected 理由コード | 影響なしの根拠を再利用しやすくする |
| 案件台帳 | 過去回答、期限、証跡を一つの案件として追えるようにする |
特に効果が高いのは、Not affected の理由を型にすることです。設計は毎回長文を一から書かずに、該当する理由と製品固有の補足を確認できます。
| 理由コード | 意味 |
|---|---|
| Component not present | 対象コンポーネントを含まない |
| Vulnerable version not present | コンポーネントは含むが脆弱な版ではない |
| Vulnerable code not included | ビルド時に該当コードを含まない |
| Vulnerable code not reachable | 該当機能へ攻撃経路から到達できない |
| Configuration not affected | 製品設定上、脆弱性が成立する条件を満たさない |
| Mitigated by design | 設計上の保護機構で影響を緩和している |
| Fixed in version | 修正版のコンポーネントへ更新済み |
設計を脆弱性対応の下請けにしない
設計部門が持つべきなのは、対象製品と版の確定、脆弱なコードの使用・到達可能性、「影響なし」の技術根拠、回避策と修正方針です。
CVE情報の収集、SBOMとの突合、案件起票、期限管理、OEM回答ドラフト、証跡整理、回答履歴の管理は、PSIRTや外部支援へ切り出せます。
設計部門の役割は、PSIRTの下請けになることではありません。製品の専門家として必要な技術判断を出せるよう、PSIRT側が受付、台帳、期限、証跡、回答整理を引き受けることが重要です。
参考資料
設計とPSIRTの役割分担を相談する
現在の脆弱性対応フロー、設計部門への確認負荷、SBOM管理、OEM回答の流れをもとに、設計へ残す判断とPSIRTへ切り出す業務を整理します。