自動車サプライヤーのPSIRT完全ガイド：
UN-R155/ISO 21434対応を兼務で回す方法

まず結論：兼務PSIRTが“回る状態”の最小要件

最初に結論を言うと、自動車サプライヤーのPSIRTは、次の5つが揃えば運用を始められます。

• 受付窓口がある
• 影響評価の責任者が決まっている
• 回答テンプレがある
• SBOMまたは簡易部品表がある
• 判断の記録が残る

ここで大事なのは、「完璧にやる」ことではなく、同じ手順で繰り返し回せることです。

OEMや監査側が見ているのは、きれいな理想論よりも、脆弱性情報を受け取ったときに、誰が、どう評価し、どう回答したかが説明できるかです。つまりPSIRTは、華やかなセキュリティ組織というより、まずは運用ルールと証跡管理の仕組みです。

PSIRTとは何か：SOCやVSOCとの違い

PSIRTは Product Security Incident Response Team の略で、製品に関する脆弱性やセキュリティインシデントへ対応するための体制・運用を指します。
やることは大きく分けて次の5つです。

1. 脆弱性情報の受付
2. 影響有無の確認
3. 優先度の判断
4. 顧客/OEMへの連絡
5. 修正または回避策の管理

ここで混同されやすいのがSOCやVSOCです。

• SOC：ITシステムやネットワークの監視・検知・分析
• VSOC：車両や車両関連システムの運用監視
• PSIRT：製品脆弱性に対する受付・評価・対外対応・是正管理

Tier2〜Tier4のサプライヤーにとって、最初に必要なのは多くの場合VSOCではなくPSIRTです。

なぜなら、いきなり24時間365日の監視体制を作るより前に、OEMから来る脆弱性照会へ答えられることの方が現実的かつ緊急だからです。もちろん、将来的には脅威監視や外部インテリジェンスの継続取得も必要になります。ただ、立ち上げ初期の論点はまず「製品脆弱性に説明責任を持てるか」にあります。

なぜ自動車サプライヤーにもPSIRTが必要なのか

ISO/SAE 21434は、車両の電気・電子システムとそのコンポーネント、インターフェースを対象に、コンセプト、開発、製造、運用、保守、廃棄まで含むライフサイクル全体でのサイバーセキュリティリスク管理要求を定義しています。ISO自身も、この規格が車両のライフサイクル全体でサイバーセキュリティを考慮するための枠組みだと説明しています。

また、UN Regulation No.155はサイバーセキュリティおよびサイバーセキュリティ管理システムを扱う公式規則であり、UNECEは条文と改訂版を継続的に公開しています。つまり、これは一過性の流行ではなく、型式認証やOEM要求に関わる実務要件です。

ここで重要なのは、Tier2〜Tier4のサプライヤーが「法規の直接適用対象ではないから関係ない」とは言えないことです。

実際にはOEMやTier1がUN-R155/CSMSに対応するため、下位サプライヤーに対しても次のような要求が降りてきます。

• 使用OSSやソフト部品の把握
• 脆弱性情報の継続監視
• 影響有無の回答
• 是正計画または回避策の提示
• 証跡の提出

つまり、OEMに売るためにPSIRTが必要というのが現実です。

OEMが本当に見ているのは“説明責任”である

OEMからの要求を受けると、多くの企業は「とにかくCVEを全部追わなければ」と考えがちです。
ですが、OEMが本当に見ているのはCVEの数ではありません。見ているのは、次の3点です。

1. 自社製品への影響を判断できるか

そのCVEが、自社のどの製品・どのバージョン・どの構成に関係するかを説明できるか。

2. 対応優先度を決められるか

全部を同じ重さで扱っていないか。何を優先し、何を調査中とし、何を影響なしとするかの基準があるか。

3. 期限内に回答できるか

社内調査が完了していなくても、中間報告・追加確認・確定報告の流れを持っているか。

ここを外すと、いくらセキュリティツールを入れても運用は破綻します。逆に言えば、PSIRT立ち上げで最初に作るべきは巨大な監視基盤ではなく、説明責任を支える運用フローです。

兼務でも回るPSIRT最小体制

PSIRTを立ち上げようとすると、「専任チームが必要では」と考えて止まってしまいがちです。
ですが、立ち上げ初期は4ロールで十分です。

1. 受付窓口

品質保証または情シスが担うことが多いです。役割は、OEMや外部からの問い合わせを受け、期限を管理し、チケットを起票することです。

2. 技術評価

設計、ソフト開発、製品担当が担います。その脆弱性が実際に使っている部品・ソフト・機能に関係するかを確認します。

3. 顧客対応

品質保証や営業技術が担います。OEM向けの回答文面を整え、必要に応じて補足説明や中間報告を出します。

4. 承認者

部門長または品質責任者です。対外回答の最終承認と、リスク受容の判断を行います。

この4ロールは、4人必要という意味ではありません。実際には1人が複数ロールを兼務して構いません。ただし、誰が最終承認するのかだけは曖昧にしないことが重要です。

兼務PSIRTでよくある失敗

• 受付窓口がなく、メールが個人に埋もれる
• 技術評価の依頼先が曖昧で止まる
• 対外回答の承認待ちで期限を過ぎる

この3つを潰すだけでも、PSIRT運用の安定度はかなり上がります。

PSIRT運用フロー：受付からクローズまで

兼務体制では、フローを文章ではなく状態遷移で持つ方が運用しやすくなります。おすすめは次の7ステータスです。

• New：受付
• Triage：一次評価中
• Need Info：追加情報待ち
• Decision：方針決定
• Remediation：修正または回避策対応中
• Reported：OEM報告済み
• Closed：証跡保管まで完了

受付時に最低限記録すべき項目

• 受付日
• 依頼元
• 回答期限
• CVE番号
• 対象製品
• 現在の担当
• 現時点の判定
• 次のアクション

このレベルでも、メールだけで対応するよりはるかに強くなります。監査や社内レビューの場面でも、「どの案件が止まっているか」を見える化できます。

SBOMがないとPSIRTはすぐ詰まる

PSIRT運用で最も大きなボトルネックは、「そのCVEが自社製品に関係あるか分からない」状態です。この問題を解決する基礎がSBOMです。

CISAはSBOMを、ソフトウェアを構成するコンポーネントの“入れ子状の在庫表”と説明しています。また、CISAはSBOMと関連する概念としてVEXを挙げ、VEXを「既知の脆弱性に対して製品が影響を受けるかどうかを示す表明」と説明しています。

ただし、最初から完璧なSBOMでなくてよい

よくある誤解は、「SPDXかCycloneDXで完全なSBOMがないと始められない」というものです。実務上は、まず次の項目が追えれば十分です。

• 製品名
• バージョン
• 使用ソフト/OSS名
• バージョン
• 担当者
• 出荷との紐付け

つまり、Excelの簡易部品表からでも始められるということです。大切なのは形式よりも、次の2点です。

1. 出荷中の製品と紐づいていること
2. 更新責任者が決まっていること

SBOMがないままPSIRTをやると、OEMからの照会が来るたびに、設計担当へ個別確認を投げることになり、運用が疲弊します。

脆弱性トリアージ：CVSSだけで回さない

CVEを追い始めると、多くの組織はCVSSの点数だけで優先順位を決めようとします。
しかし、これは兼務PSIRTにとって危険です。なぜなら、CVSSは脆弱性の深刻度を見る指標であって、あなたの製品にとって今どれだけ優先すべきかを単独で決めるものではないからです。

実務では3段階で十分

まずは次の3区分に落とすのが現実的です。

• 対応必須
• 要確認
• 対応不要

判断の基準

次の3つで見ます。

1. 使っているか：SBOMや部品表上で、そのコンポーネントが入っているか。
2. 到達可能か：外部インターフェース、通信機能、診断機能などを通じて、その脆弱な機能に到達できるか。
3. 悪用リスクが高いか：実際に悪用されている、または短期的に悪用されやすいか。

この3つで切るだけでも、ノイズはかなり減ります。

VEXの考え方：“影響なし”を説明できるようにする

VEXは、製品やコンポーネントが特定の脆弱性に対してどの状態にあるかを機械可読で表すための枠組みです。CISAのVEX最小要件では、VEXはソフトウェア製品やコンポーネントが脆弱性に対してどういう状態かを示すもので、SBOMや脆弱性DB、セキュリティアドバイザリと統合できるが、それらを必須とはしないと整理されています。

自動車サプライヤーの実務で特に重要なのは、“Not affected（影響なし）”をきちんと説明する語彙を持つことです。

典型パターン

• そもそも該当コンポーネントを使っていない
• 該当コードがビルドに含まれていない
• 到達経路が存在しない
• 既存設定やアーキテクチャで緩和されている

ここを毎回ゼロから文章で書くと、担当者によって回答品質がぶれます。だからこそ、判定理由の型を持つことが大事です。

“調査中”も立派な回答

結論が出ない場合に黙るのが一番危険です。「現時点では調査中だが、追加で確認して○日までに再回答する」と返せるようにしておく方が、対外運用としては強いです。

NVD、KEV、EPSSをどう使うか

脆弱性情報の取り込み先として、まず押さえやすいのがNVDです。NVDはCVE情報をAPIで取得でき、ページング、最終更新日、CPE指定、KEV追加日などの条件で取得できます。NVDはまた、CVEが公開されると通常1時間以内にNVDへ入ると説明しています。

• KEV：CISAのKnown Exploited Vulnerabilities Catalogは、実際に悪用が確認されている脆弱性をまとめた一覧で、CISA自身も脆弱性優先順位付けの入力として使うよう勧めています。
• EPSS：FIRSTのEPSSは、脆弱性が今後30日以内に現実世界で悪用される確率を推定する仕組みです。FIRSTはEPSSをリスクスコアそのものではなく、リスクのうち“脅威側”を補う情報として扱うべきだと説明しています。

実務上の使い方

• NVD：基本データの取得
• KEV：優先対応のシグナル
• EPSS：要確認案件の優先順位付け補助

これで「CVSSが高いから全部急ぐ」という誤りを避けやすくなります。

OEM調査依頼への対応：何を返せばよいか

OEMからの照会に対して、回答書に最低限入れるべき内容は次の通りです。

• 対象CVE
• 対象製品/バージョン
• 影響有無
• 判定根拠
• 現在の対応状況
• 今後の予定
• 連絡先/承認者

“影響なし”で返す場合

一番重要なのは、短くてもよいので理由があることです。

“影響あり”で返す場合

この場合も、最初から完璧な修正完了を求められているわけではありません。返すべき内容は次の順です。

1. 影響あり
2. 暫定回避策の有無
3. 恒久対応の予定
4. 次回報告タイミング

この型を持っておくだけで、社内調整がかなり楽になります。

30日で立ち上げる現実的ロードマップ

PSIRTを一気に完璧にしようとすると止まります。おすすめは30日で最小運用を作ることです。

• 1週目：窓口とフローを決める
  • 問い合わせ窓口を1つ決める
  • チケット管理表を作る
  • 承認者を決める
• 2週目：トップ製品の部品表を整理する
  • 売上上位またはOEM要求が強い製品から着手
  • Excelでもよいので部品・ソフト一覧を作る
• 3週目：トリアージルールを決める
  • 対応必須 / 要確認 / 対応不要
  • 判定根拠の型を決める
• 4週目：模擬案件で回す
  • OEM照会を想定して1件通してみる
  • どこで止まったか洗い出す
  • テンプレを更新する

この進め方なら、専任不在でもPSIRTを“存在する状態”にできます。

よくある失敗

• SBOMを作って終わる：更新されないSBOMは、ほぼ役に立ちません。出荷バージョンと紐づいて初めて意味があります。
• CVSSだけで全部高優先度にする：兼務運用では確実に破綻します。露出、到達性、悪用状況で絞る必要があります。
• 対外回答の承認者がいない：回答文はできているのに、誰も最終判断できず期限が過ぎるケースは非常に多いです。
• “調査中”を出せない：結論が出ない間に無言になるのが最悪です。中間報告の型を持っておくべきです。

まとめ：PSIRTは“組織名”ではなく“回る運用”である

自動車サプライヤーにとってPSIRTは、立派な看板を作ることではありません。本質は、脆弱性を受け取り、影響を判断し、OEMへ説明し、記録を残す一連の運用を回せることです。

そのために必要なのは、最初から巨大な組織ではなく、次の最小セットです。

• 受付窓口
• 4ロールの責任分界
• 状態遷移で管理する運用フロー
• SBOMまたは簡易部品表
• 3段階のトリアージ基準
• OEM回答テンプレ
• 証跡保管

ここまで揃えば、兼務PSIRTでも十分にスタートできます。そして、ここからSBOM自動化、VEX整備、OEMフォーマット出力、自動トリアージへと拡張していくのが現実的です。

---

よくある質問（FAQ）