LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

PSIRTとは何か——自社製品の脆弱性を継続的にハンドリングする専門組織

PSIRT(Product Security Incident Response Team)とは、自社が開発・提供する製品やサービスに関わるセキュリティ脆弱性について、リスクの識別・評価・対応を専門に担う組織を指します^*1。FIRST(Forum of Incident Response and Security Teams)が公開するPSIRT Services Frameworkでは、対象を「組織が製造・販売する製品、提供物、ソリューション、コンポーネント、サービスに内在する脆弱性」と幅広く定義しています^*1。

PSIRT Services Frameworkは、PSIRTが担う活動を6つのサービス領域に整理しています。関係者との連携体制の維持、脆弱性の発見、分析と修正、開示と調整、成熟度・指標の管理、そして体制やリソースの確保です^*1。ここでいう関係者には、社内の開発・広報・法務部門だけでなく、製品を利用する顧客、脆弱性を報告してくる外部の発見者、調整機関までが含まれます^*1。

自社で製品やサービスを継続的に提供する企業であれば、規模の大小を問わずこの機能は必要になります。窓口を持たないまま外部から脆弱性の連絡を受けると、社内のどの部署が対応するか決まっておらず、初動が遅れる事態にもつながりかねません。

PSIRTとCSIRTの違い——守る対象は「自社インフラ」か「自社製品」か

PSIRTとよく混同される組織にCSIRT(Computer Security Incident Response Team)があります。CSIRTは自社の情報システムやネットワークで発生したインシデントの検知・対応を担う組織です。一方でPSIRTは、自社が外部に提供している製品やサービスそのものに内在する脆弱性を対象とします^*1。

同じ企業の中に両方の機能が存在し、連携しながら動くケースも珍しくありません^*1。たとえば自社製品に組み込んだOSSコンポーネントで脆弱性が見つかった場合、社内インフラへの影響有無の確認はCSIRTが、製品自体の修正版リリースやユーザーへの通知はPSIRTが担当する、といった役割分担が考えられます。両者の違いを整理すると次の通りです。

受付から公表まで——脆弱性ハンドリングの5つの工程

PSIRT Services Frameworkは、脆弱性ハンドリングを受付・分析・修正・開示という機能の連なりとして描いています^*1。ここに国内の調整実務で使われるCVSS評価とCVE採番を組み込むと、実務上は次の5工程に整理できます。

受付——公開された窓口で報告を待ち受ける

外部の発見者や顧客が脆弱性を報告できる窓口を用意し、継続的に監視することが起点になります^*1。国内向けには、IPA(情報処理推進機構)が受付機関となる届出制度も並行して存在します^*4。自社窓口とIPA経由の届出、双方からの連絡が同じ脆弱性を指している場合もあるため、突合できる管理台帳を用意しておくと混乱を避けやすくなります。

トリアージ——CVSSで深刻度を評価する

CVSS(Common Vulnerability Scoring System)は、脆弱性の特性を数値化し深刻度を表す指標で、FIRSTが仕様を策定しています^*2。2023年11月に公開されたCVSS v4.0が現行のバージョンです^*2。算出したスコアを低・中・高・緊急といった区分に対応づけ、修正の優先順位づけに使います^*2。自社製品への影響範囲(どのバージョン、どの構成で再現するか)も、この段階で並行して確認します。

修正——開発部門と連携してパッチを作る

トリアージで対応が必要と判断された脆弱性は、開発部門と連携して修正版を作成します^*1。回避策(ワークアラウンド)の提示で当面をしのぎつつ、恒久対応のパッチを別途進める判断が必要になる場合もあります。修正の検証環境や配布経路を持たないPSIRTでは、この工程が滞りやすい点に注意が必要です。

調整——CVE採番とJPCERT/CCとの連携

JPCERT/CCはCNA(CVE Numbering Authority)として、CVE(Common Vulnerabilities and Exposures)識別子を採番できる組織のひとつです^*6。国内の届出制度を経由した脆弱性については、JPCERT/CCが製品開発者との連絡窓口を確認し、対応状況を確認しながら開発者とIPAの間を仲介します^*5。公表時期についても、JPCERT/CCが開発者と調整します^*5。

公表——アドバイザリとJVNへの掲載

JVN(Japan Vulnerability Notes)は、JPCERT/CCとIPAが共同で運営する脆弱性対策情報ポータルです^*7。2004年7月の運用開始以来、脆弱性の詳細や対策情報、製品開発者の見解を公開してきました^*7。自社サイトでのアドバイザリ公開とあわせて、JVNへの情報提供も選択肢になります^*7。

受付窓口の作り方——外部発見者からの報告とバグバウンティの考え方

国内では、脆弱性関連情報を適切に流通させる仕組みとして「情報セキュリティ早期警戒パートナーシップ」が運用されています^*3。この枠組みでは、発見者・IPA・JPCERT/CC・製品開発者それぞれの推奨行動が整理されています^*3。届出はIPAが受け付け、内容を確認したうえでJPCERT/CCに通知し、JPCERT/CCが製品開発者への連絡や公表時期の調整を担うという役割分担です^*4*5。

この制度は届出があって初めて動く受け身の窓口です。自社製品を利用する顧客や研究者が直接連絡できる自社窓口もあわせて用意しておくと、届出制度を経由しない報告も拾いやすくなります。連絡先をセキュリティポリシーのページに明記し、暗号化した通信手段を選べるようにしておくといった配慮も、外部の発見者との関係構築の一部です^*1。

報奨金(バグバウンティ)制度は、外部の研究者に積極的な発見・報告を促す仕組みとして位置づけられます。PSIRT Services Frameworkでも、外部の発見者を含めたステークホルダーとの関係管理を主要なサービス領域のひとつに挙げています^*1。ただし報奨金制度の運用には、対象範囲の線引きや支払い基準の整備が伴うため、受付窓口とトリアージの基準を先に固めてから検討する順序が現実的です。

SBOMと依存脆弱性管理——組み込みOSSの脆弱性にどう向き合うか

自社製品の脆弱性は、自社で書いたコードだけでなく、組み込んだOSS(オープンソースソフトウェア)コンポーネントに起因する場合も少なくありません。SBOM(Software Bill of Materials。ソフトウェアの構成部品を一覧化した明細)を整備しておくと、外部で新しいCVEが公表された際に、自社製品への影響有無を確認する初動が速くなります。

SBOMがない状態でOSSの脆弱性情報が流れてくると、まず「自社製品にその部品が含まれているか」の調査から始めることになり、トリアージの着手が遅れがちです。逆にSBOMが整っていれば、該当コンポーネントを使う製品ラインをリストから絞り込み、CVSSによる深刻度評価にすぐ進めます^*2。PSIRT運用とSBOM整備は別々の取り組みに見えますが、トリアージ工程を支える土台という点でつながっています。

体制構築の進め方——小さく始めて段階的に広げる

PSIRTの立ち上げを、はじめから専任チームと全工程の自動化を備えた形で目指す必要はありません。まず受付窓口とトリアージの基準(どのCVSSスコアで誰が判断するか)を決め、修正・調整・公表のフローを既存の開発プロセスや広報・法務の承認フローに接続するところから始める進め方が現実的です。

専任者を置けない組織では、セキュリティ担当者やプロダクトオーナーが兼任で受付とトリアージを担い、案件数が増えてきた段階で体制を拡充する運用も選択肢です。重要なのは、担当者が不在でも受付から公表までの流れが止まらないよう、役割と連絡経路を文書化しておくことです。属人化した状態のままでは、担当者の異動や休暇のたびに対応が滞るおそれがあります。

内製と外注の分かれ目——PSIRT立ち上げで外部の支援を使うポイント

PSIRTの立ち上げには、脆弱性のトリアージスキル、CVE採番やJPCERT/CCとの調整実務、アドバイザリの文面作成など、複数領域の知見が求められます^*5*6。既存の開発・運用担当者が通常業務と並行して立ち上げを担う場合、受付基準の策定や調整機関とのやり取りに割ける時間が限られる場合があります。

外部の支援を検討する際は、依頼する範囲を具体的に切り分けることが選定の分かれ目になります。受付窓口の設計やポリシー文書の整備を支援してほしいのか、トリアージ・修正の実務そのものに伴走してほしいのか、調整機関とのやり取りの経験を持つ人材を求めているのかによって、適した委託先は変わってきます。

。自社製品のラインアップ数やOSS依存の度合いによって、必要な体制の規模は変わってきます。現状の受付・対応フローを棚卸ししたうえで、内製・外注の切り分けを検討することが実務的です。

まとめ：PSIRT・脆弱性対応体制で押さえる3つの判断軸

本稿ではPSIRT・脆弱性対応体制の構築について、FIRSTやIPA・JPCERT/CCの公式情報をもとに整理しました。要点は3つに集約できます。第一に、PSIRTは自社が提供する製品・サービスの脆弱性を対象とする組織で、社内インフラを守るCSIRTとは対象が異なります^*1。第二に、脆弱性ハンドリングは受付・トリアージ・修正・調整・公表の5工程に整理でき、CVSSによる深刻度評価やCVE採番、JPCERT/CCとの調整実務が組み合わさります^*2*5*6。第三に、SBOMによる依存部品の可視化やバグバウンティのような外部連携の仕組みも含めて、どこまでを内製し、どこから外部の支援を仰ぐかが体制構築の判断材料になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：FIRST「Product Security Incident Response Team (PSIRT) Services Framework Version 1.1」（https://www.first.org/standards/frameworks/psirts/psirt_services_framework_v1-1）
2. *2　出典：FIRST「Common Vulnerability Scoring System (CVSS)」（https://www.first.org/cvss/）
3. *3　出典：IPA「情報セキュリティ早期警戒パートナーシップガイドライン」（https://www.ipa.go.jp/security/guide/vuln/partnership_guide.html）
4. *4　出典：IPA「脆弱性関連情報の届出受付」（https://www.ipa.go.jp/security/todokede/vuln/uketsuke.html）
5. *5　出典：IPA「脆弱性関連情報の届出受付業務における取扱いプロセス」（https://www.ipa.go.jp/security/todokede/vuln/process.html）
6. *6　出典：JPCERT/CC「脆弱性対策情報」（https://www.jpcert.or.jp/vh/top.html）
7. *7　出典：JVN（Japan Vulnerability Notes）（https://jvn.jp/）
8. *8　出典：ISO/IEC 29147:2018「Information technology — Security techniques — Vulnerability disclosure」／ISO/IEC 30111:2019「Information technology — Security techniques — Vulnerability handling processes」（ISO公式サイトはアクセス制限のためリンク省略）

Tweet