PSIRTとは？役割やCSIRTとの違い、CRA（欧州サイバーレジリエンス法）対応のポイントを解説

PSIRT（Product Security Incident Response Team）とは、自社が開発・製造・販売する製品のセキュリティに特化したインシデント対応チームのことです。一般的に「ピーサート」と読みます。

具体的には、製品に潜む脆弱性（セキュリティ上の欠陥）をあらかじめ特定して修正したり、出荷後に発見された脆弱性に対してユーザーへパッチ（修正プログラム）を提供したりする役割を担います。単なる修理担当ではなく、製品の企画段階から廃棄に至るまでの全ライフサイクルにおいて、サイバー攻撃からユーザーを守るための司令塔となる組織です。

PSIRTを組織のどこに配置するかは、その実効性を左右する重要なポイントです。多くの場合、製品設計の深い知識が必要となるため、開発本部や品質管理部門の直下に設置されます。

しかし、重要なのは「独立性」です。開発現場の納期優先という論理に押し切られ、脆弱性を放置してリリースすることは許されません。そのため、PSIRTには経営層直轄の権限を持たせたり、開発担当とは異なる視点でリスクを評価・判断できる独立した意思決定フローを整備したりすることが、健全な組織運用の鍵となります。

PSIRTがこれほどまでに重視されるようになった最大の理由は、あらゆるモノが通信機能を持つようになったことにあります。かつての家電や産業機器はネットワークから隔離されていましたが、現在はクラウド連携が当たり前となり、製品がサイバー攻撃の入り口になるリスクが激増しました。

また、他社製部品やオープンソースソフトウェア（OSS）を組み合わせて製品を作るサプライチェーンの複雑化も要因です。自社コードに問題がなくても、利用しているライブラリに脆弱性があれば、製品全体が危険にさらされます。こうした複雑な依存関係のなかで、迅速にリスクを検知・対処するためにPSIRTの存在が不可欠となっているのです。

セキュリティ組織には、PSIRTのほかにもCSIRT（Computer Security Incident Response Team）という似た名称が存在します。ここでは、それぞれの組織が守るべき対象や具体的な活動範囲の違いを整理します。

PSIRTとCSIRTにおける最大の違いは、守るべき対象（アセット）にあります。

CSIRTの守備範囲は、主に自社内のITインフラ（PC、サーバー、社内ネットワーク）です。社員が使う端末がウイルスに感染した際に対応するのがCSIRTです。対してPSIRTは、顧客に提供する製品・サービスを守ります。

つまり、CSIRTは社内を守る盾、PSIRTは自社製品の品質としての安全を守る盾であるといえます。

PSIRTとCSIRTには、役割の面でも明確な差があります。CSIRTの主な活動は、社内ネットワークへの不正アクセス監視や、感染したPCの隔離、業務復旧です。IT部門と密接に連携し、ビジネスの継続性を維持することに主眼を置きます。

一方、PSIRTの活動は、製品開発に深く関わります。脆弱性が発見された際に、エンジニアに修正コードを書かせ、ファームウェアのアップデート版を作成し、ユーザーに告知・配布するまでを管理します。対象が不特定多数のユーザーの手元にあるデバイスであるため、物理的なリコールや大規模なアップデート配信など、対応の規模と手法がCSIRTとは大きく異なります。

PSIRTとCSIRTは独立した役割を持ちますが、両者の連携は全社的なセキュリティ統制において極めて重要です。たとえば、自社の開発サーバー（CSIRTの管轄）がサイバー攻撃を受けた場合、そこから製品のソースコードが流出したり、バックドアを仕込まれたりすれば、それは即座に製品セキュリティ（PSIRTの管轄）の問題へと発展します。

インシデントの情報共有をスムーズに行うための共通プラットフォームの構築や、合同演習の実施により、隙間のない防御体制を築くことが、現代の企業に求められるガバナンスの姿です。

【関連記事】CSIRTとは？役割やSOCとの違い、社内構築のポイントをわかりやすく解説

PSIRTの活動は、製品のリリース前後を問わず多岐にわたります。脆弱性の収集からパッチ配布、ユーザー広報、さらには開発段階でのセキュリティ組み込みまで、具体的な4つの主要業務について解説します。

PSIRTの日常業務の核となるのが、情報の収集です。自社製品に使用しているOS、ライブラリ、OSSなどの脆弱性情報（CVEなど）を常にモニタリングします。

単に情報を集めるだけでなく、その脆弱性が自社製品のどのモデルに、どのような影響を与えるかを分析（トリリアージュ）する能力が求められます。すべての脆弱性が即座に危険なわけではありません。製品の利用環境や構成を照らし合わせ、優先順位をつけて対処を決定する分析力こそがPSIRTの専門性の見せ所です。

分析の結果、対策が必要と判断された場合、PSIRTは開発チームへ修正を指示します。このプロセスを「脆弱性ハンドリング」と呼びます。

修正が完了したら、ユーザーに対してセキュリティアドバイザリ（注意喚起）を公開します。これには、脆弱性の内容、影響を受ける製品バージョン、回避策、および修正済みパッチの適用方法が含まれます。ユーザーが適切に対処できるよう、専門用語を避けつつも正確な技術情報を提供するドキュメンテーション能力が必要です。

万が一、製品の脆弱性が悪用され、実害が発生してしまった場合、PSIRTはクライシス・マネジメント（危機管理）の主導権を握ります。

カスタマーサポート部門と連携してユーザーからの問い合わせに応じるとともに、広報部門と協力して公式見解を発表します。隠蔽や対応の遅れは企業の信頼を失墜させるため、正確な事実関係を迅速に公表し、被害拡大を食い止めるためのリーダーシップが期待されます。

事後対応だけでなく、予防的な活動もPSIRTの重要な任務です。企画・設計段階からセキュリティ要件を組み込む「セキュリティ・バイ・デザイン」を組織に浸透させます。

脅威モデリング（どのような攻撃が予想されるかのシミュレーション）の実施や、ソースコードの静的・動的解析、ペネトレーションテスト（疑似攻撃テスト）の実施をガイドします。開発の上流で問題を潰しておくことで、リリース後の修正コストを劇的に下げることが可能になります。

近年、PSIRTを取り巻く環境は法的規制の強化により大きな転換点を迎えています。とくに欧州のCRA（サイバーレジリエンス法）への対応は、グローバルに展開する日本企業にとって避けては通れない最重要課題です。

製造業にとって、CRA（Cyber Resilience Act：欧州サイバーレジリエンス法）の本格施行は最大のトピックといえるでしょう。これは、EU市場で販売されるデジタル要素を持つ製品に対し、最低限のセキュリティ基準を満たすことを義務付ける法律です。

適合していない製品はEU域内での販売が禁止されるだけでなく、莫大な制裁金が科せられます。PSIRTは、自社製品がCRAの要求事項（セキュリティ要件の遵守、適合性評価の実施など）を満たしているかを証明し、ライフサイクル全体を通じて安全性を担保し続ける責任を負っています。

CRAでは、悪用されている脆弱性や重大なインシデントを検知した場合、欧州ネットワーク・情報セキュリティ機関（ENISA）に対し、24時間以内の初期報告を求めています。

これまでの「じっくり調査してから報告する」というスタイルは通用しません。PSIRTは、世界中からのインシデント報告をリアルタイムでキャッチし、即座に重要度を判断して関係機関へ連絡する体制を24時間365日（またはそれに準ずる迅速さで）稼働させる必要があります。

製品に含まれるソフトウェアの成分表であるSBOM（Software Bill of Materials）の管理も、PSIRTの最重要課題の一つです。

製品にどのOSSのどのバージョンが含まれているかを可視化することで、新たな脆弱性が発表された際に自社製品が影響を受けるかを数分以内に特定できるようになります。CRA対応においてもSBOMの維持管理は事実上の義務となっており、手動管理ではなく、自動化ツールの導入によるプロセス構築が急務となっています。

外部のセキュリティ研究者やホワイトハッカーが発見した脆弱性を、安全かつ円滑に報告してもらうための仕組みが、CVD（Coordinated Vulnerability Disclosure：協調的脆弱性開示）です。

PSIRTは、報告者に対する窓口を公開し、報告された情報をどのように扱い、いつまでに修正するかを定義したポリシーを公表する必要があります。報告者を敵対視するのではなく、協力者として迎え入れる文化を醸成することが、製品の安全性を高めるためのグローバルスタンダードとなっています。

PSIRTの構築は、単に担当者を決めるだけでは不十分です。実効性のある組織にするためには、権限の定義から外部窓口の設置、社内連携の自動化まで、段階的なプロセスを踏む必要があります。ここでは、その4つのステップを解説します。

まずは「誰が・何を・どこまで責任を持つか」を定義した憲章（チャーター）を作成します。PSIRTメンバーは、開発、法務、広報、品質保証など多岐にわたる部署と連携するため、経営層による強力なバックアップが不可欠です。

とくに重大な脆弱性が見つかった際に製品の出荷を止める、あるいは稼働中のサービスを停止するといった決断を下せる権限を明確にしておくことが、有事の際の迷いをなくします。

外部からの報告を受け付ける窓口（VDP）を設置します。一般的には、自社Webサイト内に専用メールアドレスや専用のフォームを用意します。

窓口を作るだけでなく、受け取ったメールに対して受領確認を数日以内に行うなど、報告者とのコミュニケーションプロセスを標準化することが重要です。

脆弱性が見つかった後の社内連携図を作成します。

これらの部署と、どのような連絡手段（Slack、Teams、専用インシデント管理システムなど）で情報をやり取りするか、あらかじめ定義しておきます。

PSIRTの役割は、製品をリリースして終わりではありません。販売終了後も、サポート期間内であれば脆弱性対応を継続する必要があります。

各製品のサポート期限、使用されているコンポーネントのリスト、修正パッチの配布インフラを維持・更新し続けるサイクルを回します。この継続的な活動こそが、PSIRTの運用においてもっとも労力を要し、かつ価値のある部分です。

組織を立ち上げた後は、どのようにその能力を向上させていくかが次の課題となります。外部機関との情報共有、AIツールの戦略的活用、そして専門人材の育成という、成熟度を高めるための3つの鍵を紹介します。

自社だけで世界の脅威情報を追いかけるには限界があります。日本国内では「JPCERT/CC」、世界規模ではPSIRTの国際コミュニティである「FIRST」などの専門機関と連携することが推奨されます。

これらのコミュニティに参加することで、最新の攻撃手法や他社の対応事例といった貴重な知見を得られるほか、脆弱性の調整を中立的な立場からサポートしてもらうことが可能になります。

扱う製品数やコード量が増大するなか、手動での脆弱性管理は不可能です。現在はAIを搭載したSCA（ソフトウェア構成分析）やSAST・DAST（静的・動的解析）ツールが進化しています。

AIは、膨大なOSSライブラリの中から脆弱性を自動で見つけ出し、さらには推奨される修正コード（パッチ）の案まで提示してくれます。こうしたテクノロジーを積極的に取り入れ、PSIRTメンバーを単純作業から高度な意思決定へとシフトさせることが成熟度向上への近道です。

PSIRTには、ITセキュリティの知識だけでなく、組み込みシステムやハードウェア、ネットワークプロトコルといった製品固有の技術に精通した人材が必要です。

そのためにも、社内の優秀なエンジニアをPSIRTメンバーとして育成するための教育プログラムを整備しましょう。また、PSIRTだけでなく、開発者全員がセキュリティ意識を高めるためのプロダクトセキュリティ教育を定期的に実施し、組織全体の底上げを図ることが重要です。

PSIRTは製品の安全という品質を保証し、企業の信頼とブランド価値を守り抜く、現代の製造業・サービス業における中核組織です。

とくに近年は、CRAをはじめとする国際的な法規制への対応は努力義務から生存条件へと変化しています。これからPSIRTを構築する企業も、すでに運用している企業も、SBOMの活用やAIツールの導入、および外部機関との連携を強化し、変化し続ける脅威に適応していく必要があるでしょう。

PSIRT（ピーサート）とは、自社が製造・販売する製品のセキュリティインシデントに対応する専門組織です。IoT機器やソフトウェアに脆弱性が発見された際、その分析や修正パッチの配布、ユーザーへの注意喚起を行い、製品の安全性をライフサイクル全体で支える重要な役割を担います。

詳細は「PSIRTとは」をご覧ください。

PSIRTとCSIRTの最大の違いは、守る対象です。CSIRTは自社の社内ネットワークやPCなどのIT資産（インフラ）をサイバー攻撃から守る組織であるのに対し、PSIRTは顧客に提供する製品やサービスの安全を守ります。前者は社内防衛、後者は製品品質の維持が主目的となります。

詳細は「PSIRTとCSIRTの違い」をご覧ください。

PSIRTの主な役割は、自社製品に関わる脆弱性情報の収集・分析、修正プログラムの開発管理、そしてユーザーへのアドバイザリ公開です。また、開発の初期段階からセキュリティを考慮するセキュリティ・バイ・デザインの推進や、法規制への適合証明も重要な業務に含まれます。

詳細は「PSIRTの主な役割と活動内容」をご覧ください。