2026年に報告されたCVEは、1日あたり前年比131%増加しています。

プロダクトセキュリティ

PSIRT：製品セキュリティインシデント対応チームの役割

ソフトウェアを出荷する企業はすべて、脆弱性も出荷しています。PSIRTは、それらの脆弱性を把握し、影響を受ける製品とバージョンを特定し、修正させ、顧客に取るべき対応を伝えるチームです。このガイドでは、その業務、多くのチームが基盤とするFIRSTのフレームワーク、そしてそれを支えるプロセスとツールを解説します。

更新日

PSIRTとは

製品セキュリティインシデント対応チーム（PSIRT：Product Security Incident Response Team）は、企業が製造・販売する製品のセキュリティ脆弱性に対応する機能です。 FIRSTはこれを、提供物、ソリューション、コンポーネント、サービスを含む「製品内のセキュリティ脆弱性に関連するリスクの特定、評価、処理」に注力する組織と定義しています。

実際には、PSIRTは次のことを行います。

  • 研究者、顧客、パートナーが脆弱性を報告するための窓口を運営する。
  • 製品に含まれるサードパーティやオープンソースのコンポーネントの脆弱性を監視する。
  • 各報告をトリアージする。本物か、どの製品とバージョンに影響するか、深刻度はどの程度か。
  • 担当のエンジニアリングチームに、リスクに見合ったスケジュールで修正させる。
  • アドバイザリを公開し、発見者や下流のベンダーと開示を調整する。
  • 経営陣に指標を報告し、製品を開発する人々をトレーニングする。

作業の大半はリリース後に発生します。FIRSTは、製品の脆弱性の多くは製品が市場に出た後に品質上の見逃しとして報告されると指摘していますが、PSIRTは設計レビューや脅威モデリングなど、より早い段階でも価値を発揮します。

組織におけるPSIRTの位置付け

ほかのセキュリティチームとの違いは、製品に焦点を当てている点です。企業のCSIRTは自社のシステムとネットワークを守り、PSIRTは自社製品を運用する顧客を守ります。両者はスキルを共有し、報告ラインも同じであることが多く、ビルドシステムの侵害など、自社インフラでのインシデントが製品に及んだときに連携します。詳しい比較はPSIRTとCSIRTの違いをご覧ください。

FIRSTは3つの運営モデルを示しています。

  • 分散型：小規模な中核PSIRTがポリシーを定めて調整を行い、各製品チームのセキュリティ担当者がトリアージと修正を行います。大規模で多様な製品群にも対応できますが、実作業を行う人はPSIRTの指揮系統にはいません。
  • 集中型：独自のプログラム管理、トリアージ、修正のスタッフを持つ大規模なPSIRTで、プロダクトセキュリティ担当の上級役員に報告します。小規模な企業や均質な製品群に適していますが、製品群が増えるにつれてコストが高くなります。
  • ハイブリッド型：両者の組み合わせで、企業規模、製品群、開発戦略に応じて選択します。

どのモデルでも、FIRSTは独立性を重視しています。PSIRTは、その権限を承認する役員に報告し、自社製品の脆弱性について客観的な立場を取れるようにすべきです。

FIRST PSIRT Services Framework

FIRSTが無料で公開しているPSIRT Services Framework（現在はバージョン1.1）は、多くのPSIRTがサービスカタログの基盤としているリファレンスです。運営の基盤（権限、ステークホルダー、予算、ポリシー）を定めたうえで、6つのサービス領域を示しています。

サービス領域 対象範囲
1. ステークホルダーエコシステムの管理 社内のステークホルダー、発見者コミュニティ、下流のベンダーと顧客、インシデント時のコミュニケーション、発見者への謝辞、ステークホルダー関連の指標
2. 脆弱性の発見 脆弱性報告の受付、未報告の脆弱性の発見、製品コンポーネントの脆弱性監視、新たな脆弱性の特定、発見に関する指標
3. 脆弱性のトリアージと分析 報告の妥当性確認、実績のある発見者との連携、脆弱性の再現
4. 修正 修正リリースの管理計画、修正、インシデント対応、リリースに関する指標
5. 脆弱性の開示 通知、調整、アドバイザリによる開示、開示に関する指標
6. トレーニングと教育 PSIRT、開発・検証チーム、その他のステークホルダーのトレーニング、フィードバックの仕組み

業務の大きな割合を占めるようになったため、特に取り上げる価値があるサービスが1つあります。製品コンポーネントの脆弱性監視です。その最初の機能は製品コンポーネントのインベントリ、つまり各製品に含まれるベンダー、製品、バージョンの一覧であり、FIRSTはこれを「継承された脆弱性の影響を受ける製品を迅速に特定するために不可欠」としています。現代のソフトウェアでは、このインベントリがソフトウェア部品表（SBOM）です。

PSIRTプロセスの概要

このプロセスは2つのISO/IEC規格で説明されています。ISO/IEC 30111:2019は、ベンダーが社内で脆弱性をどう扱うかを定めています。ISO/IEC 29147:2018は、外部からの報告をどう受け付け、修正情報をどう公開するかを定めています。30111は29147と併用することを前提としており、そこで説明されるフェーズが有用な骨組みになります。

  1. 準備。ポリシー、役割、脆弱性の報告方法の公開、スコアリング手法、出荷するもののインベントリ。
  2. 受付。研究者、顧客、パートナー、自社のテストからの報告、そして使用しているコンポーネントのアドバイザリを受け付けます。発見者に受領を伝えます。
  3. 検証。脆弱性を確認・再現し、スコアを付け、影響を受けるすべての製品とバージョンを特定します。影響を受けない製品とその理由も記録します。
  4. 修正の開発。担当チームが修正または緩和策を開発・テストします。PSIRTは合意したスケジュールに沿って進捗を追跡します。
  5. リリース。修正を出荷してアドバイザリを公開します。発見者や、自社製品を組み込んでいる下流のベンダーと調整して行います。
  6. リリース後。修正に問題がないか監視し、顧客の質問に答え、根本原因を開発にフィードバックします。

各段階で何を記録し、誰が担当するかは、脆弱性管理ライフサイクルで解説しています。どの検出結果を優先するかの判断については、脆弱性の優先順位付けをご覧ください。悪用のシグナルにはEPSSとCISA KEVカタログを用います。修正が存在する前に悪用された脆弱性はゼロデイであり、PSIRTはこれをインシデントとして扱います。アドバイザリから修正済みビルドの出荷までは、CVEの修正で解説しています。

開示とアドバイザリ

開示は、PSIRTの業務のうち顧客の目に触れる部分です。一般的な手法は協調的脆弱性開示です。発見者が非公開で報告し、ベンダーが修正し、合意した日に両者が公開し、発見者の貢献が明記されます。その出発点は、報告方法、発見者が期待できること、製品のサポート期間を示す公開の脆弱性開示ポリシーです。協調的脆弱性開示をご覧ください。

優れたアドバイザリは、電話をしなくても次のことを顧客に伝えます。

  • 影響を受ける製品とバージョン、および影響を受けないもの。
  • CVE IDと深刻度スコア。
  • 修正済みのバージョン、またはまだ修正がない場合は緩和策。
  • 発見者。

大口顧客は、自社の資産インベントリと自動的に照合できる機械可読な形式のアドバイザリをますます求めるようになっています。CSAFはアドバイザリのためのOASIS標準形式であり、VEXは製品がそのコンポーネントの脆弱性の影響を受けないことを示す手段で、双方にとって問い合わせの手間を省きます。

PSIRTの指標と成熟度

このフレームワークでは、すべてのサービス領域に指標が設けられています。一般的な指標は次のとおりです。

  • 深刻度別の、報告への受領通知、トリアージ、修正リリースまでの時間。
  • 製品、深刻度、経過期間別の未解決の脆弱性。
  • 公表した修正目標の期間内に提供された修正の割合。
  • 社内で発見された脆弱性と外部から報告された脆弱性の比率。
  • 公開したアドバイザリの数と、アドバイザリの訂正。

FIRSTの関連文書であるPSIRT Maturity Documentは、サービスを3つのレベルに整理しています。

  • レベル1（基本）：経営層の支援、ステークホルダー、予算とポリシー、報告を受け付ける手段、トリアージのワークフロー、文書化された修正、CVEとCVSSを使用し発見者を明記するアドバイザリ。
  • レベル2（中級）：憲章と組織モデル、基本的な指標、依存関係のマッピングを備えた製品レジストリ、正式な修正計画、ステークホルダーへの通知システム、チームのトレーニング。
  • レベル3（上級）：発見者コミュニティとの直接的な関与、製品コンポーネントの脆弱性監視、発見とリリースに関する指標、高度なインシデント対応、業界での調整のためのプレイブック。

レベルが上がるにつれて、受け身の対応から先回りの対応へと移行します。

PSIRTの立ち上げ方：小さく始める

  1. 書面による権限を得る。製品チームに修正を求める権限を、役員から書面で付与してもらいます。
  2. 脆弱性の報告方法を公開する。セキュリティ窓口のアドレス、Webフォームまたはsecurity.txtファイル、そして簡潔な開示ポリシーを用意します。
  3. トリアージとスコアリングを定義する。報告が有効かどうかを誰が判断するか、深刻度をどうスコア化するか、深刻度ごとの修正目標を決めます。
  4. 出荷するものを把握する。製品バージョンごとに、含まれるコンポーネントとそのバージョンを把握します。これがないと、人気のあるライブラリに新しいCVEが出るたびに、エンジニアリングチームへの問い合わせに何日も費やすことになります。
  5. 製品ごとに担当者を決める。検出結果を受け取り、修正のスケジュールを組む人です。
  6. アドバイザリのテンプレートを作成し、小さな問題であっても最初の1件を公開します。
  7. いくつかの所要時間を最初から計測し、改善を示せるようにします。

PSIRTチームのページではプロダクトセキュリティ責任者の立場からこの役割を見ています。産業機器のベンダーは、これらのステップをIEC 62443-4-1に対応付けることができます。同規格のセキュア開発ライフサイクル要件には、欠陥管理とパッチ管理が含まれます。

PSIRTを前提とする規制

PSIRTはかつて成熟したベンダーの証でした。現在では、いくつかのフレームワークがその成果物を求めています。NIS2の第21条2項(e)は、必須エンティティおよび重要エンティティが講じるべき措置の1つとして「脆弱性の取り扱いと開示」を挙げています。米国では第524B条が、医療機器メーカーに対し、協調的脆弱性開示を含む市販後の脆弱性の監視・特定・対処の計画を、SBOMとともに提出することを義務付けています。さらにEUのCyber Resilience Actは、実際に悪用されている脆弱性と重大なインシデントを、24時間以内の早期警告から始めて当局に報告することをメーカーに義務付けています。CRAとはをご覧ください。通知はENISAのSingle Reporting Platformを通じて提出します。

PSIRTに必要なツール

必要なもの 理由
報告の受付とケース管理 すべての報告に担当者、ステータス、スケジュールを割り当てるため
出荷するもののインベントリ 推移的依存関係を含む、製品バージョンごとの正確なSBOM
継続的な監視 新しいCVEを、次のバージョンだけでなく、リリース済みのすべてのバージョンのコンポーネントと照合
トリアージと振り分け 検出結果を、対応に必要なコンテキストとともに修正担当チームへ届ける
影響あり・影響なしのステートメント VEXで、脆弱性がどの製品に影響し、ほかの製品がなぜ影響を受けないかを記録
アドバイザリの公開 人が読めるアドバイザリと、大口顧客向けの機械可読なCSAF

すべての項目をカバーする製品はほとんどありません。どのツールが何を行うかはPSIRTツールの比較をご覧ください。多くのPSIRTが苦労するのはインベントリです。事後にロックファイルを読み取るスキャナーは、出荷されない開発用の依存関係を列挙する一方で、ビルドがパッケージマネージャー以外でダウンロードしたパッケージを見落とします。そのため、「影響を受けるのか？」という問いに、確信を持って答えられなくなります。

CRACIは、そのインベントリをビルドそのものから取得します。GitHub Actionsのビルドを自社のランナーで実行し、推移的依存関係、CIキャッシュから復元されたパッケージ、どのロックファイルにも載らない依存関係を含め、各ジョブが実際に取得したパッケージを記録します。各SBOMには完全性の状態が付き、CycloneDXまたはSPDXでエクスポートできます。監視対象のSBOMは新たな脆弱性が公開されるたびに継続的に再評価され、ビルド履歴から脆弱な依存関係を含んでいた過去のビルドがわかり、インベントリビューでどのソフトウェアバージョンがどの製品にデプロイされているかを確認できます。セキュリティチームは検出結果をトリアージして修正担当チームに送ることができ、CRACIはVEXにも対応しています。脆弱性トラッキングとPSIRTチーム向けのCRACIをご覧ください。

PSIRTに関するよくあるご質問

PSIRTは何の略ですか？

PSIRTはProduct Security Incident Response Team（製品セキュリティインシデント対応チーム）の略です。FIRSTはこれを、組織が製造または販売する製品、提供物、ソリューション、コンポーネント、サービスのセキュリティ脆弱性に関連するリスクの特定、評価、処理に注力する組織内のエンティティと定義しています。

PSIRTとCSIRTの違いは何ですか？

PSIRTは、企業が顧客に出荷する製品の脆弱性に対応します。企業のCSIRTは、自社のシステムとネットワークにおけるセキュリティインシデントに対応します。たとえばビルドインフラの侵害が製品に影響した場合などに、両者は連携します。PSIRTとCSIRTの違いをご覧ください。

FIRST PSIRT Services Frameworkとは何ですか？

FIRST（Forum of Incident Response and Security Teams）が無料で提供するガイドで、PSIRTが提供しうるサービスを列挙しています。バージョン1.1では、ステークホルダーエコシステムの管理、脆弱性の発見、脆弱性のトリアージと分析、修正、脆弱性の開示、トレーニングと教育の6つのサービス領域に分類しています。関連する成熟度文書では、サービスを3つのレベルに整理しています。

PSIRTのプロセスを定めた規格はどれですか？

ISO/IEC 30111:2019は、準備と受付から検証、修正の開発、リリース、リリース後までの、ベンダーが社内で脆弱性報告を扱う方法を定めています。ISO/IEC 29147:2018は、報告の受付と修正情報の公開という外部とのインターフェースを定めています。30111は29147と併用することを前提としています。IEC 62443-4-1は、産業オートメーション製品向けに、欠陥管理とパッチ管理を含むセキュア開発ライフサイクルの要件を定めています。

小規模な企業にもPSIRTは必要ですか？

必要なのは機能であり、必ずしも部署ではありません。FIRSTの成熟度文書は、経営層の支援、明確なステークホルダー、予算、いくつかのポリシー、脆弱性の報告方法の公開、トリアージのワークフロー、文書化された修正、発見者を明記するアドバイザリから始まります。書面による権限を持つ1〜2人で運営できます。

PSIRTにはどのようなツールが必要ですか？

最低限必要なのは、報告を受け付ける手段、ケーストラッカー、脆弱性のスコアリング手法、どのコンポーネントがどの製品バージョンで出荷されているかのインベントリ、それらのコンポーネントの新たな脆弱性の監視、各製品が影響を受けるかどうかを記録する手段（多くの場合VEX）、そしてアドバイザリを公開する手段（ますますCSAF形式が増えています）です。

脆弱なパッケージを出荷している製品を把握

デモを予約して、CRACIがGitHub Actionsの各ビルドで実際に取得されたものを記録する仕組みをご覧ください。PSIRTは、どのリリースが影響を受けるかをエビデンスに基づいて答えられます。

デモを予約