PSIRTを少人数で始める方法｜専任者がいなくても回る製品セキュリティ体制

はじめに：PSIRTは大企業だけのものか？

PSIRT（Product Security Incident Response Team）という言葉を聞いたことはあるでしょうか。自社製品に関するセキュリティ脆弱性やインシデントに対応する組織のことです。

「うちは従業員100人規模だし、専任のセキュリティチームなんて置けない」——そう考える方が多いのではないでしょうか。

しかし実際には、PSIRTは専任チームがなくても始められます。重要なのは、「脆弱性の報告が来たときに、誰が何をするか」が決まっていることです。

なぜ今PSIRTが必要なのか

1. 顧客からの要求

大手企業や公共機関との取引では、「脆弱性が見つかった場合の対応体制」を質問されるケースが増えています。セキュリティ質問票の中に「PSIRTまたはそれに相当する組織はありますか」という項目が入っていることも珍しくありません。

2. 制度面の後押し

• JC-STARの適合基準には、脆弱性情報の受付・対応に関する項目が含まれています
• EU CRAでは、製品の脆弱性への対応体制が義務化されます（2027年12月完全適用）
• IEC 62443でも、脆弱性管理プロセスが要件に含まれています

3. リスク管理

自社製品の脆弱性を外部から報告されたとき、対応の窓口もプロセスも決まっていなければ、初動が遅れます。初動の遅れは顧客の信頼喪失や契約解除にもつながり得ます。

PSIRTの最小構成

以下の4つの機能が回っていれば、それがPSIRTです。

専任者は不要です。既存の役割の中に、上記の機能を割り当てるだけで始められます。

4ステップで始めるPSIRT

ステップ1：受付窓口を設置する

最低限やること：

• 専用メールアドレスを作る（例：security@yourcompany.co.jp）
• 製品ページまたは会社のWebサイトに連絡先を掲載する

この1つ目のステップだけでも、「脆弱性の受付窓口がない」から「ある」に変わります。

ステップ2：社内の連絡フローを決める

脆弱性報告が届いたとき、誰がどの順番で何をするかを決めます。

具体的に決めること：

• 一次受付者：メールを確認し、開発リーダーに転送する人
• トリアージ担当：「対応が必要か」「緊急度はどの程度か」を判断する人
• 対応担当：修正作業を行う開発者
• 承認者：修正内容と顧客通知の内容を承認する人
• 対外連絡担当：顧客への連絡を行う人

最初はA4用紙1枚に書ける程度のフローで十分です。

ステップ3：対応方針を文書化する

文書に含める項目：

1. 対応範囲：どの製品が対象か
2. 受付方法：連絡先（メールアドレス等）
3. 初動の目安：受付から何営業日以内に一次回答するか
4. 緊急度の基準：どのような脆弱性を「緊急」とするか
5. 対応の流れ：受付 → トリアージ → 修正 → 通知の概要
6. サポート期間：製品のセキュリティアップデート提供期間

「方針がある」という事実自体が価値です。

ステップ4：運用を回しながら改善する

改善のヒント：

• 対応完了後に簡単な振り返りを行う
• 実際に来た報告の内容と対応内容を記録として残す
• 半年に一度、フローと文書を見直す機会を設ける

よくある質問

Q：脆弱性報告は実際にどれくらい来るのか？

中堅メーカーの場合、年間数件程度というのが一般的です。受付窓口さえ設置しておけば、既存の開発業務の中で十分に対応可能です。

Q：セキュリティの専門知識がなくてもトリアージできるか？

• すぐに対応：認証なしでリモートから悪用できる／個人情報が漏洩する
• 計画的に対応：悪用には物理的アクセスが必要／影響が限定的
• 対応不要：理論上の脅威のみ／すでに対策済み

Q：PSIRTとCSIRTの違いは？

• CSIRT：社内のIT環境に関するセキュリティインシデントに対応するチーム
• PSIRT：自社が販売・提供する製品に関するセキュリティ脆弱性に対応するチーム

メーカーの場合、顧客や市場から求められるのはPSIRTの方です。

スケジュール感の目安

受付窓口の設置だけなら1〜2日で完了します。

まとめ

PSIRTは、大企業だけのものではありません。

1. 受付窓口を作る
2. 社内の連絡フローを決める
3. 対応方針を文書化する
4. 運用しながら改善する

この4ステップで、専任者がいなくてもPSIRTの機能は立ち上がります。

自社だけで進めるのが難しいと感じたら

「フローを作る時間がない」「方針文書の書き方が分からない」——そんな場合は、外部の専門家と一緒に整えるのも一つの方法です。