インサイト

PSIRTとは(自動車サプライヤー版):
OEM要求にどう答えるか

自動車サプライヤーの現場で「PSIRTを作ってください」「脆弱性対応体制を示してください」と言われる場面が増えています。背景にあるのは、車両メーカー側がUN-R155のCSMS対応を進め、開発・生産・出荷後を通じてサイバーセキュリティを管理し、新たな脅威や脆弱性を監視・検知・対応することを求められているからです。

ISO/SAE 21434も、車載のE/Eシステムをライフサイクル全体で扱う前提を置いています。さらに日本ではJAMA/JAPIAの自動車産業サイバーセキュリティガイドラインが、サプライチェーン全体での対策レベル向上と自己評価を推進しています。

つまり、OEMの要求は単なる“追加のお願い”ではなく、規制・標準・業界運用の流れがサプライヤー側に降りてきた結果だと理解するのが正確です。

PSIRTとは何か

では、PSIRTとは何か。FIRST(Forum of Incident Response and Security Teams:グローバルなインシデント対応およびセキュリティチームの国際的な協力体制を構築するために設立された組織)のPSIRT Services Frameworkでは、PSIRTは自社が製造・販売する製品やサービスに関する脆弱性リスクを特定し、評価し、対処する組織的な機能として説明されています。また、PSIRTは開発から切り離された孤立組織ではなく、より広いセキュアエンジニアリングの取り組みの一部として動くべきものだとされています。つまりPSIRTは、単なる「受付窓口」でも「問い合わせ対応班」でもなく、製品セキュリティの意思決定を回す仕組みそのものです。

自動車サプライヤーにとってのPSIRTを、もっと実務寄りに言い換えるとこうなります。

「OEMや顧客から脆弱性について聞かれたときに、誰が、何を根拠に、いつまでに、どう答えるかを定義する体制」

現場で本当に困るのは、脆弱性そのものよりも、

  • そもそも自社製品が影響を受けるのか分からない
  • 誰が判断するのか決まっていない
  • OEMに返す文面や証跡がない

という3点です。UN-R155が求めるのは“脅威や脆弱性を監視・検知・対応すること”であり、FIRSTのPSIRT frameworkも、内部外部のステークホルダー連携や、再現性ある手順・ワークフローの整備を重視しています。したがって、OEMが見ているのは「完璧な24時間SOCがあるか」ではなく、製品脆弱性対応の流れが止まらないかです。

兼務でも回る最小構成

ここで重要なのが、PSIRTを大げさに考えすぎないことです。Tier2〜Tier4の企業で、いきなり専任チームを作る必要はありません。最小構成なら、次の4役で十分回せます。

  • 受付担当:OEMや顧客、社内からの問い合わせを受け、期限を管理する人。
  • 技術評価担当:設計・ソフト担当として、影響有無を判断する人。
  • 対外回答担当:品質保証や営業技術として、OEMに説明可能な形へ整える人。
  • 承認者:最終的に外部へ出す回答を承認する責任者。

この4つは、4人の専任者が必要という意味ではありません。兼務で構いません。大切なのは、役割が明確で、止まったときに誰がボールを持つか分かることです。FIRSTも、PSIRTが開発、品質、リリース、サポートなど複数の内部関係者と継続的に連携することを重視しています。

PSIRTとSOC、VSOCの違い

PSIRTと混同されやすいのがSOCやVSOCです。違いを一言で言えば、PSIRTは「製品の脆弱性対応」、SOC/VSOCは「運用監視と検知」です。

FIRSTの整理でも、PSIRTは製品やサービスに関する脆弱性情報の受領・調査・報告を担う一方、Enterprise CSIRTは組織内ICTのインシデントを扱うと分けられています。自動車業界ではここに車両・フリート側の監視機能が加わってVSOCと呼ばれることがありますが、少なくともサプライヤーが最初に整えるべきなのは、ログ監視よりも「脆弱性照会に答えられるPSIRT」です。

OEMはPSIRTに何を期待しているのか

では、OEMはPSIRTに何を期待しているのでしょうか。実務上は、主に3つです。

  1. 第一に、窓口があること。問い合わせ先が明確で、返答の初動が早いこと。
  2. 第二に、影響判定ができること。自社製品・部品・バージョン単位で、影響あり/なしを説明できること。
  3. 第三に、証跡が残ること。誰がどう判断し、何を回答したかを後から示せることです。

この3つは、UN-R155の継続監視・対応要求、FIRSTのPSIRT業務、そしてJAMA/JAPIAの自己評価運用の方向性と整合しています。だからこそ、「脆弱性をゼロにする」ことよりも、「対応を再現可能にする」ことの方が先に見られます。

SBOMの重要性と説明責任

もう1つ、PSIRTを回す上で避けて通れないのがSBOM(ソフトウェア部品表)です。

CISAはSBOMを、ソフトウェアを構成するコンポーネントの“材料表”として位置づけています。またVEXは、その製品が既知の脆弱性に影響を受けるかどうかを示すための考え方です。つまりOEMが欲しいのは、単なる「たぶん大丈夫です」ではなく、どのコンポーネントが入り、どのバージョンで、なぜ影響がある/ないのかという説明です。

PSIRTは、この説明責任を回すための中核機能だと考えると腹落ちしやすくなります。

最初の一歩はどう踏み出すか

自動車サプライヤーがPSIRTを立ち上げるなら、最初の一歩は大きくありません。

  • まずは脆弱性受付の窓口を1つ決める。
  • 次に、製品一覧と主要ソフト部品の棚卸しを始める。
  • そして、影響あり・要確認・影響なしの3段階で仮置きできるルールを決める。

この3つだけで、OEMからの突然の照会に対して「社内で判断不能で止まる」状態はかなり減ります。JAMA/JAPIAのガイドラインが自己評価と改善を前提にしていることを踏まえても、最初から100点を目指すより、まず継続できる最小運用を作る方が現実的です。

まとめ:説明責任を回す仕組み

最後に、PSIRTを一言でまとめるなら、製品脆弱性への“説明責任を回す仕組み”です。

自動車サプライヤーにとって重要なのは、「うちは中小企業だから無理」と考えることではなく、「OEMが納得する最小の型は何か」を定義することです。窓口、影響判定、証跡。この3つが回り始めれば、PSIRTはもう始まっています。規制や標準は厳しく見えますが、現場で必要なのはまず、迷わず返せる仕組みです。

PSIRTの立ち上げで悩んでいませんか?

「兼務体制でどう回せばいいか分からない」「既存のExcel部品表をどう活用すればいいか知りたい」という方は、まずはオンライン無料相談をご活用ください。

Auto PSIRT Cloudなら、月額5万円で専門知識ゼロでも回せる運用基盤をすぐに構築できます。

【無料】オンライン相談 & 画面デモを予約する