増え続ける問い合わせに、人員の増強で対応し続けることはできません。トリアージをいつまでも速め続けることもできません。PSIRTがスケールするのは、「影響を受けますか？」という問いの大半に各バージョンのビルド時に記録したデータから答え、顧客に尋ねられる前に答えを公開することによってです。現在最もコストがかかっているのは、製品に何が含まれているかをエンジニアリングに尋ねるステップです。このステップをビルド時に移せば、ほとんどの問い合わせはサポートが完結できる照会になります。
この記事は、すでにPSIRTを運用していることを前提としています。これから立ち上げる場合は、まずPSIRTとは何か、どう立ち上げるかをご覧ください。以下では、問い合わせ量が変わった理由、一般的なパイプラインで時間がどこに消えているか、そして何をどの順番で変えるべきかを解説します。
問い合わせ量が変わった理由
この増加は構造的なもので、たまたま悪い四半期だったわけではありません。4つの要因が同時に同じキューを押し上げています。
CVEの増加。 CVE Programが公開したCVEレコードは、2024年に39,718件、2025年に47,801件でした。2026年は、年末を待たずに2025年の年間総数を上回りました。この件数は当社のCVE公開件数のライブ推移で日々追跡しています。FIRSTの2026年脆弱性予測の更新（2026年6月15日）は、同年の予測を約66,000件のCVEに引き上げ、その原因をはっきりと述べています。AIは人間のアナリストよりもはるかに多くの欠陥を見つけられるようになり、「制約はもはや発見ではなく、検証し、調整し、パッチを適用する人間の能力である」というのです。PSIRTこそがその人間の能力です。
顧客が製品をスキャンする。 顧客は貴社のイメージ、ファームウェア、アプライアンスにスキャナーをかけ、検出結果をすべてチケットとして転送してきます。その大半は、出荷していないコンポーネントや影響を受けないバージョンに関するスキャナーのノイズであり、そのノイズがそのまま受付の負荷になります。スキャナー側の対策は脆弱性ノイズの削減で解説しています。
規制が期限を加える。 2026年9月11日から、EUのCyber Resilience Actの報告義務が適用されています。EUで販売される製品で積極的に悪用されている脆弱性については、メーカーがそれを認識してから24時間以内に早期警告が必要です。
NVDの支援が減る。 NISTは2026年4月15日、National Vulnerability Databaseをリスクベースのエンリッチメントに移行しました。CISAのKEVカタログに掲載されたCVE、連邦政府が使用するソフトウェア、EO 14028の重要ソフトウェアが優先され、それ以外は「Lowest Priority - not scheduled for immediate enrichment」（最低優先度、即時のエンリッチメントは予定されていない）とされます。CPEデータ付きで届くCVEが減るため、件数が増えるのと同時に、製品名による照合の精度が落ちます。
| 要因 | PSIRTのキューへの影響 |
|---|---|
| CVEの件数、AIを活用した発見 | 製品ごとに評価すべきサードパーティのCVEが毎月増える |
| 顧客によるスキャン | CVEごとの問い合わせが増え、その多くは出荷していないコンポーネントに関するもの |
| CRAの報告義務 | 積極的に悪用されている脆弱性に24時間の期限 |
| NVDのエンリッチメントの減少 | CVEを影響を受ける製品に対応付ける手作業が増える |
時間はどこに消えているか：一般的な問い合わせパイプライン
製品セキュリティチームからは、同じパイプラインの話を何度も聞きます。あるハードウェアベンダーの2人体制のPSIRTは、次のように説明してくれました。顧客がサポートデスクに問い合わせ、サポートがCRMを通じてPSIRTに質問を回し、ケースがPSIRTのトラッカーに入り、PSIRTが顧客からの問い合わせが最も多い製品を調査し、その後エンジニアリングに質問を渡して回答を待つ、というものです。
説明のための問い合わせを1件取り上げます。顧客が、ファームウェアのバージョンXに対して40件のCVEを列挙したスキャナーのレポートを転送してきます。サポートはケースを作成してレポートを添付しますが、顧客が実行している正確なビルドは添付しません。PSIRTは40件のうちどれを評価済みかを確認し、未評価のものを十数件見つけ、担当のエンジニアリングチームに、そのコンポーネントがバージョンXに含まれているかを尋ねます。エンジニアリングはバージョンXのソースを探し、どのバージョンの依存関係が含まれたのかを突き止めて回答しなければなりません。数字は架空ですが、構図は現実のものです。
時間がかかるのは、分析そのものであることはまれです。隠れたコストは2つあります。
- 同じCVEが、問い合わせてきた顧客ごとに調査し直される。 答えがメールのスレッドの中にあると、次の顧客のときには調査が一からやり直しになります。
- 「問い合わせの多い製品から」では、ロングテールが回答されないまま残る。 現場でまだ使われている古い製品は一度も確認されず、多くの場合そこにこそリスクがあります。コンポーネントは古く、更新は少なく、どうビルドされたかを覚えている人も少ないからです。
受付：質問と報告を分ける
研究者からの脆弱性報告と、顧客からの「影響を受けますか？」は別の仕事であり、別の経路が必要です。FIRST PSIRT Services Frameworkは、雑多な入力をすでに想定しています。PSIRTは「さまざまなチャネルを通じて、さまざまな品質の脆弱性を受け取ることを想定すべき」とされています（サブ機能2.1.1.1）。トリアージのサービス領域はさらに踏み込んでいます。「大量の脆弱性報告を受け取る組織は、ケースを作成する前に報告を検証するための初期トリアージの実施を検討してもよい」。これを、問い合わせのたびにPSIRTのケースを作成しなくてよいという許可と受け取ってください。
サポートデスクで問い合わせを3つの経路に振り分けます。
| 顧客が問い合わせている内容 | 経路 | 回答者 |
|---|---|---|
| 評価済みのサードパーティ製コンポーネントにある公開済みのCVE | 公開済みのVEXステートメントまたはアドバイザリから回答し、PSIRTのケースは作成しない | サポート |
| まだ評価していない公開済みのCVE | 顧客ごとではなくCVEごとにPSIRTのケースを1件作成し、すべての問い合わせをそれに紐付ける | PSIRT、その後サポートが紐付いた全員に返信 |
| 自社のコードにある新しい脆弱性 | 脆弱性報告として、協調的脆弱性開示の完全なプロセスで扱う | PSIRT |
サポートが1つ目の経路を処理するには、2つのものが必要です。製品とバージョンごとに評価済みのCVEを検索できる一覧と、返信テンプレートです。サプライチェーン攻撃後に顧客へどう回答するかに、応用できるテンプレートがあります。
受付の時点で、製品と、顧客が実行している正確なバージョンを確認してください。バージョンがなければ、どの答えも「場合によります」になり、ケースは差し戻されてきます。
人気だけでなく露出で優先順位を付ける
「問い合わせの多い製品から」は妥当な経験則ですが、もう1つの軸が必要です。人気（導入数、売上、サポートからの問い合わせ頻度）はそのままに、露出を加えます。その製品はまだサポート中か、一般的な導入形態でインターネットに面しているか、CVEはCISAのKEVカタログに掲載されているか、EPSSが高いか、です。シグナルの詳細は脆弱性の優先順位付けのガイドで解説しています。
| 露出が低い | 露出が高い | |
|---|---|---|
| 導入数が多い | インベントリから回答し、影響を受けないバージョンについてVEXを公開する | 最初に調査し、最短の期限でアドバイザリと修正を出す |
| 導入数が少ない | 求められたときにインベントリから回答し、能動的な作業はしない | 省略しない。インベントリから回答し、その後、修正するか緩和策の通知を出すかを決める |
このマトリクスの要点は、左の列と下の行にあります。ロングテールには、誰も時間を割けない調査ではなく、データから答えが返ります。
CRAのもとでは、製品ごとに宣言したサポート期間によって、どの古い製品についてまだ回答とセキュリティアップデートの義務があるかが決まります（CRAが求めること）。
ボトルネックはエンジニアリングへの引き継ぎ
このセクションは、PSIRTからのエスカレーションを受けるエンジニアリングリードに向けたものです。
PSIRTの期限は外部に見えています。顧客、規制当局、あるいは開示日が待っています。エンジニアリングの期限は通常そうではないため、その差をPSIRTが吸収することになります。重大な問題を月曜日に引き継ぎ、火曜日になっても返事がなければ、公開の回答期限まで残りは2日です。
PSIRTはエンジニアリングに2種類の質問を送りますが、エンジニアリングが必要なのはそのうち1つだけのはずです。
- 「そのコンポーネントは製品に含まれていますか？」 はデータの質問です。人がビルドファイルを読んで答えるのではなく、記録から答えられるべきものです。
- 「X日までに修正できますか？」 は作業の質問です。こちらはエンジニアリングの仕事です。
FIRSTのフレームワークは、1つ目の質問をエンジニアリングの手から外す方法を示しています。機能2.3.5はPSIRTに対し、「特定されたサードパーティの脆弱性通知を、影響を受ける製品の開発チームに直接配信する自動化されたチャネルを確立する」ことを求めています。サードパーティのアドバイザリが開発プロセスの中で処理され、PSIRTが手作業で扱う件数が減るようにするためです。
エンジニアリングとは3つのことを合意してください。
- 製品ごとの担当者。 大規模なベンダーでは、修正は複数の製品チームに分散しています。フレームワークに分散型モデルがあるのは、製品を担当するエンジニアを通じてPSIRTの使命をスケールさせられるからです。
- 深刻度ごとの対応目標。 文書化し、調査ではなく修正に対して設定します。
- 目標を達成できなかった場合の扱い。 機能4.2.4は、「社内SLAの期限内に修正されなかった脆弱性について、正式にリスクを受容するプロセス」を求めています。権限を持つ誰かがリスクに署名し、未解決のまま放置されないようにします。
修正のペースはさまざまです。一晩でパッチを出すチームもあれば、6か月かかるプラットフォームのアップグレードが必要なチームもあります。顧客が計画を立てられるよう、アドバイザリにはどちらなのかを記載しなければなりません。
「影響を受けますか？」を照会に変える：出荷したバージョンごとのSBOM
これが、最も多くの作業をなくす変更です。FIRSTの機能2.3.1、製品コンポーネントのインベントリについて、フレームワークは「継承された脆弱性について、影響を受ける製品を迅速に特定するために不可欠」としています。PSIRTの成熟度レベルでは、依存関係のマッピングを備えた製品レジストリが中級レベルに、製品コンポーネントの脆弱性の監視が上級レベルに位置付けられています。
インベントリが作業をなくすのは、大量の問い合わせにも耐えられる場合だけです。以下の要件には、それぞれ理由があります。
- 出荷したバージョンごとに1つのSBOM。 リポジトリごとでも、デフォルトブランチのものでもありません。顧客が実行しているのはブランチではなくバージョンです。
- そのリリースを生成したビルドから取得する。 後からの再ビルドや、現在のリポジトリのスキャンは、別のソフトウェアを記述することになります（ビルド時のSBOM）。
- 推移的依存関係と隠れた依存関係を含める。 脆弱なパッケージが自分で追加したものであることはまれです（推移的依存関係）。また、インストールスクリプト、ベースイメージ、復元されたキャッシュは、どのロックファイルにも載らないコンポーネントを持ち込みます。
- 完全性のシグナル。 不完全な記録を完全なものとして扱うと、自信を持って誤った「影響なし」の回答を出すことになります。
- そのバージョンがサポートされている間は保持する。 3年前のバージョンの記録こそ、どうビルドされたかを誰も覚えていないときに必要になります。
- 購入したコンポーネントにはベンダーのSBOMを。 サードパーティのソフトウェアも自社のソフトウェアと同じインベントリに入れます。
- 継続的に再照合する。 誰かに尋ねられてから再スキャンするのではなく、新しいCVEが公開されるたびに照合します。
具体例を挙げます。広く使われている圧縮ライブラリに新しいCVEが公開されたとします。インベントリがなければ、PSIRTはすべての製品チームに問い合わせ、回答は数日かけて少しずつ集まり、最も古い製品は一度も確認されません。インベントリがあれば、1回の問い合わせで影響を受ける製品とバージョンが返り、脆弱なバージョンを含んでいた最初と最後のビルドもわかります。それが、顧客が次に尋ねる影響期間です。個別のケースで影響期間を特定する方法は、影響はあるか？新しいCVEを評価する方法で解説しています。
最も苦労するのは、組み込み製品やYoctoの製品群です。完成したファームウェアイメージを読み取るスキャナーは、何がコンパイルされて組み込まれたのかを推測するしかありません。当社が話を聞いたチームの中には、Yoctoベースの製品でスキャナーの概念実証が失敗したところもあります。ビルドの実行中に記録すれば、推測は不要になります（CRACIでのYoctoビルド）。
その後、顧客が特定の形式でSBOMそのものを求めてきた場合は、顧客からのSBOM要求への対応をご覧ください。
出力側：尋ねられる前に答えるアドバイザリとVEX
最も安い問い合わせは、来ない問い合わせです。
- 「影響なし」をVEXとして公開する。 顧客のスキャナーがそのCVEを検出しなくなります。「影響あり」と「修正済み」は、正確なバージョンを記載したアドバイザリとして公開します。
- 機械可読にする。 FIRSTのサブ機能5.3.2.3は、PSIRTが「Common Security Advisory Framework（CSAF）などの機械可読な形式でアドバイザリを公開することを検討する」よう提案しています。顧客が自社のツールで取り込めるようにするためです。WebページやRSSフィードからCSAFへの移行方法は、CSAFガイドで解説しています。
- 公開前にサポートに説明しておく。 機能5.3.4：「今後のアドバイザリについて、事前の機密通知とFAQを提供しておくことで、公開時に問い合わせを受ける可能性のある人々が準備できる」。これでサポートは公開当日に回答できます。
- 掲載するだけでなく、届ける。 サブ機能5.4.1.3は、アドバイザリのページビューが少ないことが「能動的な通知へと向かう戦略の動機になり得る」と指摘しています。フィードや通知は、アドバイザリのページを訪れない顧客にも届きます。
CRAは、この一部を義務にしています。第14条第8項は、メーカーが積極的に悪用されている脆弱性または重大なインシデントを認識した後、影響を受けるユーザー、「および適切な場合にはすべてのユーザー」に通知すること、そしてそれを「適切な場合には、容易に自動処理できる構造化された機械可読な形式で」行うことを求めています。規則は形式を指定していません。
自動化する順番
各ステップは、ある種類の作業をなくします。それができたかどうかは指標でわかります。
| ステップ | なくなる作業 | うまくいったことを示す指標 |
|---|---|---|
| 1. ビルドから取得したバージョンごとのインベントリ | エンジニアリングへの「何が含まれていますか？」という質問 | エンジニアリングへの月間調査依頼件数が減る |
| 2. 新しいCVEとサポート中の全バージョンとの継続的な照合 | 依頼を受けての再スキャン | CVEの公開から影響あり・影響なしの判断までの時間 |
| 3. CVEごとに1件のケースと、紐付けられた問い合わせ | 重複した調査 | ケースあたりの問い合わせ件数が増え、CVEあたりのケースは1件のまま |
| 4. 影響ありの検出結果を担当チームへ自動で振り分け（FIRST 2.3.5） | 手作業での引き継ぎ | 判断から担当者が受領するまでの時間 |
| 5. 公開済みのVEXステートメントとアドバイザリの検索可能なライブラリ | 繰り返される質問へのPSIRTの関与 | サポートが完結した問い合わせの割合 |
| 6. 機械可読な形式での公開（CSAF） | 顧客のツールが取得できたはずの情報についての問い合わせ | 公開したアドバイザリあたりの問い合わせ件数が減る |
| 7. アドバイザリと返信の作成へのAI支援 | 文章を書く時間 | 判断からアドバイザリの公開までの時間 |
AIを最後にしているのには理由があります。AIは記録されたデータの上でなら文章をうまく作成できますが、「影響あり」の判断の根拠になってはなりません。
自動化すべきでないものもあります。「影響なし」の判断と深刻度の判定は、証拠を添えて人が行います。自動化が決めるのは、その人がどれだけ早く証拠を手にできるかです。
PSIRTがスケールしていることを示す指標
- PSIRTのケースを作成せずに回答できた問い合わせの割合。
- 製品ごとの、CVEの公開から影響あり・影響なしの判断までの時間。
- エンジニアリングへの月間調査依頼件数。減っていくはずです。
- 深刻度ごとの期限内修正率。フレームワークのサブ機能4.4.2.4は、これを報告から修正までの合意された期間を製品チームがどれだけ守れているか、と定義しています。
- まだサポートしているバージョンに対する、VEXとアドバイザリのカバー率。
これらについて業界のベンチマークは示しません。当社が信頼する一次情報源で、それを公開しているものはありません。
CRACIの役割
CRACIは、GitHub Actionsでビルドされるソフトウェアについて、ステップ1と2、そしてステップ4と5の一部をカバーします。ビルドはCRACIのランナーで実行され、CRACIは各ジョブが実行中に実際に取り込んだもの、つまり直接および推移的な依存関係、スクリプトがインストールしたパッケージ、CIキャッシュから復元されたパッケージを記録します。各ジョブのSBOMには完全性の状態が付くため、不完全な記録が完全なものと取り違えられることはありません。
CRACIはビルド履歴を保持するため、新しいCVEが公開されると、どのビルドがいつから脆弱な依存関係を含んでいたかを、保持期間の範囲でさかのぼって確認できます。監視対象のSBOMは継続的に再評価され、検出結果はビルドとリポジトリをまたいで集約されます。ベンダーのSBOMを追加すれば、購入したコンポーネントも自社のビルドと並べて監視できます。CRACIは、新しい脆弱性とその深刻度を関係者に通知します。インベントリビューではどのソフトウェアバージョンがどの製品にデプロイされているかがわかり、セキュリティチームはCRACIで各検出結果をトリアージして、修正を担当するチームに割り当てます。CRACIはVEXに対応しています。PSIRT向けのCRACIと脆弱性トラッキングをご覧ください。
CRACIが適さない場合
- ボトルネックが受付とケース管理、つまりCRMからトラッカーまでの部分にある場合。 CRACIはケース管理やアドバイザリ公開のツールではありません。その部分にはケース管理ツールが必要です（PSIRTツールの比較）。
- 製品がLinuxランナー上のGitHub Actionsでビルドされていない場合。 現在サポートしているCIはGitHub Actionsです。GitLab CIとJenkinsはロードマップにありますが、時期は未定です。
- 自社でビルドしていない製品のバイナリやファームウェアの解析が必要な場合。 それは出力を解析するツールの役割です（組み込みセキュリティツールの比較）。
- 「影響なし」を主張するために到達可能性分析が必要な場合。 CRACIはこれを提供していません。
よくある質問
人員を増やさずにPSIRTをスケールさせるには？
同じ質問を何度も調査するのをやめることです。出荷するすべてのバージョンに何が含まれているかをビルド時に記録し、新しいCVEをそれと継続的に照合し、CVEごとに一度だけ判断し、その判断をサポートが案内できるVEXまたはアドバイザリとして公開します。そうすればPSIRTは本当に未解決のケースに取り組め、エンジニアリングには調査ではなく修正だけを依頼できます。
PSIRTは顧客からの「影響を受けますか？」という問い合わせにどう対応すべきですか？
脆弱性報告とは別の受付の流れとして扱います。評価済みのCVEに関する質問には、サポートが公開済みの資料から回答します。まだ評価していないCVEにはPSIRTのケースを1件作成し、顧客からのすべての問い合わせをそれに紐付けます。完全な開示プロセスを経るのは、自社のコードにある新しい脆弱性だけです。
FIRST PSIRT Services Frameworkは、量と自動化について何と言っていますか？
報告は「さまざまなチャネルを通じて、さまざまな品質」で届くことを想定し、量が多い場合はケース作成前のトリアージを認め、製品コンポーネントのインベントリを「影響を受ける製品を迅速に特定するために不可欠」とし、サードパーティの脆弱性通知を影響を受ける製品の開発チームに直接送る自動化されたチャネルを求めています（機能2.3.5）。
PSIRTはまず何を自動化すべきですか？
ビルドから取得したバージョンごとのインベントリ、次に新しいCVEとサポート中の全バージョンとの継続的な照合です。この2つが、繰り返される作業の大半、つまりエンジニアリングへの「何が含まれていますか？」という質問と、依頼を受けての再スキャンをなくします。ケースの重複排除、振り分け、検索可能なVEXとアドバイザリのライブラリ、CSAFでの公開はその後です。
エンジニアリングにPSIRTの質問へ期限内に答えてもらうには？
エンジニアリングへの質問を減らすことです。「そのコンポーネントは製品に含まれていますか？」にはビルドの記録から答え、エンジニアリングには「この日までに修正できますか？」だけを送ります。製品ごとの担当者、修正に対する深刻度ごとの対応目標、目標を達成できなかった場合の正式なリスク受容について合意してください。
PSIRTにとって、リリースごとのSBOMはなぜ重要なのですか？
顧客が実行しているのは特定のバージョンであり、古いものであることも少なくありません。デフォルトブランチのSBOMは、2年前のバージョンXについて何も教えてくれません。出荷したバージョンごとに、それを生成したビルドから記録し、サポート期間中保持したSBOMがあってこそ、PSIRTは影響期間も含め、現場で使われているすべてのバージョンについて回答できます。
顧客が求めているのはVEXですか、アドバイザリですか？
両方です。ステータスによって使い分けます。VEXは、どのCVEが製品に影響しないかを顧客のスキャナーに伝え、検出を止めます。アドバイザリは、何が影響を受け、何が修正済みで、何をすべきかを人に伝えます。可能な限り機械可読な形式で両方を公開すれば、ほとんどの質問に尋ねられる前に答えられます。
