品質保証部長向け｜PSIRTを持つべきか判断する5条件

PSIRTが必要か見極める5つの条件

条件 1

OEMからの要求が「都度回答」では済まなくなっている

最初の判断条件は、OEMからの要求内容です。たとえば、次のような依頼が増えているなら、PSIRTを持つタイミングです。

PSIRT窓口や脆弱性対応窓口の有無を聞かれる
SBOM、CVE、VEX、影響有無の説明を求められる
「影響なし」と回答した根拠を聞かれる
過去の対応履歴や是正記録を求められる
監査や自己評価で、体制・手順・証跡を確認される

この段階で、品質保証の担当者がメールを見ながら都度答えているだけでは危険です。回答内容が担当者ごとに揺れたり、過去回答との整合性が取れなくなったりします。
JAMA/JAPIAのガイドラインは、基本的な対策の抜け漏れ確認や、共通チェックシートによる信頼チェーン構築を想定しています。品質保証部長の視点では、これは「セキュリティ資料を作る仕事」ではなく、OEMへ一貫した品質説明をするための業務基盤です。

条件 2

脆弱性通知や確認依頼が増え、優先順位を付けられない

2つ目の条件は、通知量です。件数が少ないうちはメールとExcelで回りますが、上流ベンダーからの通知、CVE情報、OEMからの照会、SBOM起点の確認依頼が重なり始めると、品質保証だけでは優先順位を付けにくくなります。特に危険なのは次の状態です。

受け付けた問い合わせの一覧がない
どの製品が対象か、毎回探している
「調査中」の案件がどれだけあるか分からない
OEMへの回答期限が個人のカレンダーで管理されている
重大度や顧客影響ではなく、声の大きい依頼から対応している

PSIRTを置く意味は、すべての脆弱性を品質保証だけで判断することではありません。受け付ける、分類する、技術部門へ渡す、期限を管理する、回答を承認する流れを固定することです。最小限でも、次のステータスは台帳で管理すべきです。

ステータス	意味
受付済み	OEM、上流、社内から通知を受けた
一次確認中	対象製品・対象版を確認している
技術調査中	設計・ソフト部門が影響を確認している
回答作成中	顧客向け回答を作成している
承認待ち	部長・責任者の最終確認中
回答済み	OEMまたは顧客へ正式回答済み

条件 3

設計部門なしでは、影響有無を判断できなくなっている

品質保証部門は顧客説明の前面に立ちますが、製品に本当に影響があるかを単独で判断することはできません。対象ソフトウェア、使用ライブラリ、通信機能、実装条件などを確認するには、設計・開発・ソフト担当の関与が必要です。

品質保証が設計部門へ毎回個別に確認している
どの製品の技術窓口が誰か分からない
「影響なし」の根拠を設計担当者の口頭確認だけで済ませている
OEMから追加質問が来ると、最初から調べ直している
技術判断と顧客回答の間に承認ルートがない

この場合、PSIRTの目的は「設計部門を管理すること」ではありません。
品質保証が顧客に答えるために、技術判断を正式な根拠として受け取れる流れを作ることです。最低限、製品系列ごとに技術窓口を1人決め、影響判断の記録を残すだけでも、対応品質は大きく変わります。

条件 4

監査や自己評価で、証跡を求められるようになっている

PSIRTがない会社でも実作業はしていることが多いですが、問題は「監査や自己評価で説明できる形に残していないこと」です。回答がメールの中だけにある、承認が口頭のみ、SBOMの保管場所がバラバラ、といった状態は危険です。

品質保証部長の視点では、証跡管理は監査のためだけではありません。OEMから再確認が来たとき、前回の判断を再利用できるかどうかが、回答スピードと品質を左右します。

証跡	目的
受付記録	いつ、誰から、何を受けたか
対象製品・対象版	どの製品が確認対象だったか
技術判断記録	影響あり・なし・調査中の根拠
顧客回答履歴	何を、いつ、誰が返したか
承認記録	誰が正式回答として承認したか
是正・暫定対策記録	修正、回避策、再発防止の内容

条件 5

特定担当者に依存し、休むと対応が止まる

品質保証部門で一番危険なのは、「あの人に聞けば分かる」状態です。短期的には便利ですが、PSIRTやOEM監査対応では大きなリスクになります。

OEMからの問い合わせを受ける人が1人だけ
過去回答の所在を特定担当者しか知らない
設計部門への確認ルートが個人の人脈になっている
回答案文を作れる人が限られている
主担当が休むと期限管理が止まる

PSIRTは担当者を増やすためだけのものではありません。個人の対応力に依存している業務を、組織として再現できる業務に変えるための仕組みです。

判断基準：2つ以上当てはまったら最小PSIRTを置く

品質保証部長が判断しやすいように、5条件を整理しました。

条件	典型的なサイン	まずやること
OEM要求が増えている	PSIRT窓口、SBOM、証跡、過去対応を聞かれる	正式窓口と回答テンプレを作る
通知量が増えている	CVE、上流通知、OEM照会が並行する	案件台帳とステータス管理を始める
設計連携が必要	品質保証だけで影響判断できない	製品系列ごとに技術窓口を決める
証跡要求が増えている	監査で根拠資料を求められる	判断・回答・承認記録を1か所に残す
属人化している	主担当が休むと止まる	受付、技術判断、承認の3ロールを固定する

1個

既存業務の改善で対応できる可能性あり

2個以上

PSIRTの最小体制を
検討すべき段階

3個以上

品質保証だけで抱えずに
設計・情シス・経営層を含めた体制へ早急に切替

品質保証起点の最小PSIRTは「3ロール」でよい

中小サプライヤーの場合、最初から専任チームを作る必要はありません。まずは次の3ロールを固定するだけで、PSIRTの最小運用は始められます。

1. 品質保証：受付・進行管理・顧客回答

OEMからの問い合わせを受け、案件台帳に登録し、期限と回答状況を管理します。顧客向け回答の取りまとめも担います。

2. 設計・ソフト部門：技術判断

対象製品、対象バージョン、影響有無、回避策、修正要否を判断します。品質保証が顧客へ答えるための根拠を提供します。

3. 部長・責任者：最終承認

顧客へ正式に何を返すか、どの案件を優先するか、追加説明や是正をどこまで約束するかを承認します。

この3ロールが決まっていれば、名前としてのPSIRTがまだなくても、運用としてはPSIRTに近づきます。逆に、3ロールが決まっていないまま「PSIRT体制あり」と言っても、監査やOEM照会で詰まりやすくなります。

まとめ

品質保証部長がPSIRTを持つべきか判断するときは、組織名や専任人数から考える必要はありません。

見るべきなのは、先ほどの5条件です。2つ以上当てはまるなら品質保証起点で最小PSIRTを作るべきですし、3つ以上なら受付・技術判断・承認・証跡管理を早急に固定した方が安全です。

PSIRTは大きな新組織ではありません。
品質保証がOEMに対して、遅れず、揺れず、根拠を持って答えるための運用体制です。

品質保証部長向け
PSIRTを持つべきか判断する5条件