Auto PSIRT Cloud導入後も人が持つべき判断とは
自動化できる作業と残る責任
PSIRT運用の自動化を検討するとき、いちばん多い誤解は「ツールを入れれば判断まで置き換えられる」という期待です。FIRSTの Consolidated SBOM and CSAF/VEX Operational Framework は、機械可読なセキュリティアドバイザリによってリスク管理の自動化を進められること、標準化されたアドバイザリ配布が、脆弱性開示から顧客側の対応までの時間短縮に効くことを示しています。
一方で PSIRT Services Framework は、PSIRTを secure engineering の一部と位置づけ、トリアージ、分析、是正、通知の方針と責務を担う存在だと整理しています。つまり、自動化の価値は「判断をなくすこと」ではなく、反復作業を減らし、人が持つべき判断に時間を戻すことです。
Auto PSIRT Cloudの導入を考えるときも、見るべき論点は同じです。受付、台帳、期限管理、証跡束ねのような繰り返し処理は自動化と相性が良い。反対に、製品影響の最終判断、顧客に何をどう説明するか、どの是正を優先するか、どこまでを正式回答として出すかは、最後まで人の責任として残ります。
結論：自動化してよい仕事と、人が持つべき責任は違う
FIRSTの考え方に沿って実務を整理すると、線引きは次のようになります。
| 領域 | 自動化しやすさ | 最後に人が持つべき判断 |
|---|---|---|
| 受付・起票・担当割り当て | 高い | 受理するか、緊急扱いにするか |
| 台帳・製品一覧・SBOM紐付け | 高い | どの製品版を正式対象にするか |
| 期限管理・催促・SLA監視 | 高い | 例外を認めるか、優先順位を変えるか |
| 証跡束ね・履歴管理 | 高い | どの文書を正式根拠として採用するか |
| 顧客向け回答ドラフト | 中程度 | 何を約束し、どこまで書くか |
| 影響評価・VEX判断 | 低い | Affected / Not affected / Under investigation の判断 |
| 是正計画・公開タイミング | 低い | いつ修正を出すか、暫定対策で足りるか |
要するに、作業は自動化できても、責任は自動化できません。Auto PSIRT Cloud導入後に減らしたいのは、手入力、転記、催促、証跡探しであって、製品責任や顧客説明責任そのものではありません。
自動化しやすいのは「反復」「定型」「追跡」がある仕事
自動化が強いのは、毎回同じ型で回る工程です。FIRSTの運用枠組みでも、SBOMは自動生成、VEXはステータス更新に応じた自動生成が推奨され、機械可読フォーマットと予測可能な実装が重要だとされています。さらに、顧客側はAPI連携や標準フォーマットの取り込みによって、アドバイザリを見つけ、取得し、評価し、次のアクションにつなげられる前提で整理されています。
つまり、入力の標準化、記録の一元化、期限の機械管理は、最も自動化の効果が出やすい領域です。実務で言えば、次のような作業はAuto PSIRT Cloudのような基盤と相性が良いです。
- 受付メールや報告窓口からの起票
- 製品、部品、SBOM、案件の紐付け
- SLAタイマー、期限超過アラート、催促
- 証跡ファイル、回答履歴、改訂履歴の集約
- 定型の進捗通知やレビュー用一覧の作成
このあたりは、担当者の経験差よりも、運用ルールが定義されているかで品質が決まるため、標準化と自動化の投資対効果が高いです。
人が持つべき判断1：本当に影響があるのか
いちばん人に残るのは、製品影響の判断です。FIRSTの文書でも、脆弱性は特定条件でしか悪用できない場合があり、スキャナが true positive のように見せても、実際には該当しないことがあると説明されています。さらに、backport や rebase、アプリケーション側の緩和策によって、部品に脆弱性があっても製品としては not affected になる場合があります。
依存関係についても、単に含まれているだけでは足りず、実際にその機能を使っているかの評価が必要です。ここは台帳やスキャナだけでは決まりません。製品構成、実装、使用条件を理解した人の判断が必要です。
Auto PSIRT Cloudがどれだけ案件を整理できても、この判断は人が持つべきコア責任です。
人が持つべき判断2：顧客に何をどう約束するのか
もう一つ残るのが、顧客説明です。FIRSTの運用枠組みは、影響評価後の応答は customer appropriate であるべきだとし、修正がまだない場合でも、回避策や緩和策を提示して顧客が行動できる状態を作ることを前提にしています。つまり、重要なのは「情報を出すこと」だけではなく、相手にとって意味のある説明にすることです。
ここでは次の判断が残ります。
- いま確定していることと、未確定のことをどう分けて書くか
- Under investigation のまま、どこまで説明するか
- 暫定対策で先に返すか、修正版の見通しまで待つか
- OEMごとの粒度差にどう合わせるか
回答ドラフトの下書きや履歴管理は自動化しやすいですが、何を約束として外に出すかは、品質保証、設計、責任者が最終的に持つべき判断です。
人が持つべき判断3：何を優先して直すのか
PSIRT Services Frameworkでも、PSIRT運用は新規報告の収集点になり、製品オーナーやセキュリティエンジニアへ通知し、是正計画の策定を支援し、修正や緩和策のコミュニケーションをドラフト・公開する役割を持つとされています。逆に言うと、ツールは進行を整えることはできても、優先順位そのものを決める主体にはなりません。
たとえば実務では、次のような判断が必要です。
- 今月の他案件を押してでも先に直すべきか
- 修正を待つより回避策を先出しすべきか
- 次回リリースに載せるか、緊急修正版を切るか
- どの顧客に先に伝えるべきか
これはSLAや重大度だけでは決まらず、出荷計画、品質保証、顧客契約、営業影響まで含むため、人が持つしかありません。
導入後の現実的な役割分担
Auto PSIRT Cloud導入後に一番うまく回りやすいのは、役割を次の3つに分ける形です。
1. 運用主担当
受付、起票、期限管理、証跡束ね、会議準備を持つ。ツールの効果を最も受ける役割です。
2. 技術判断担当
製品影響、対象版、回避策、not affected の根拠を持つ。ここは自動化より、判断記録を残しやすくすることが重要です。
3. 承認者
顧客へ何を返すか、いつ出すか、どの案件を優先するかを決める。責任の所在を曖昧にしないための役割です。
この分担は、FIRSTが示す「中央の収集点」「製品側との連携」「是正計画支援」「通知と公開」の考え方とも整合します。
デモ前に確認すべき5つの論点
デモを見る前に、次の5つを整理しておくと評価しやすくなります。
- 受付から起票までを、どこまで定型化できるか
- 製品一覧、SBOM、案件を一つの流れで追えるか
- 期限管理とエスカレーションが自動で回るか
- 証跡と改訂履歴を一か所で残せるか
- 影響判断の根拠と承認フローを記録できるか
ポイントは、自動化の量ではなく、人の判断が必要な場所を明確に残せるかです。そこが曖昧だと、ツールを入れても「整理は楽になったが責任線が見えない」という状態になります。
まとめ
Auto PSIRT Cloud導入後も、人が持つべき判断はなくなりません。なくなるべきなのは、手入力、探し物、催促、転記、証跡集めのような消耗作業です。
残るべきなのは、次の4つです。
- 製品影響の最終判断
- 顧客説明の妥当性判断
- 是正優先度と公開タイミングの判断
- 例外や暫定対応を承認する判断
この線引きができると、PSIRT運用自動化は「人を減らす話」ではなく、人が本来やるべき判断に戻す話になります。Auto PSIRT Cloudのデモを見る際は、画面の見やすさより先に、どの作業が消え、どの判断が残るのかを確認するのが正解です。
自社のどこまで自動化できるかを整理したい場合へ
受付、期限管理、証跡束ねのような定型業務をどこまで減らせるかと、影響判断や承認フローをどこに残すべきかを、現行運用に合わせて確認できます。デモでは、運用負荷が消える部分と人が責任を持つべき部分を分けて見ていただけます。