トリアージ結果を監査証跡にする
（判断根拠の残し方と実務テンプレ）
CVE対応が現場で止まりやすい理由は、技術的な判断が難しいことだけではありません。
もっと大きいのは、判断した内容が「監査で見せられる証跡」になっていないことです。
- 口頭で「影響なし」と合意した
- チャットで「要確認」と流した
- メールで「調査中」と返した
このレベルでは、社内運用は回っているように見えても、外部監査やOEMからの照会対応では全く説明がつきません。
CISA は脆弱性開示の handling procedures として、報告を解決まで追跡し、影響評価と優先順位付けを行い、内部調整と関係者コミュニケーションを行い、受領・初期評価・解決までの target timelines を設定して追跡することを求めています。cisa.gov
FIRST の PSIRT Services Framework でも、PSIRT は security defect tracking system を持ち、いつどこで脆弱性が対処されたか、履歴・進捗・コメントを確認できること が重要だとされています。
先に結論：監査に耐えるトリアージ結果は「7点セット」
トリアージ結果を監査証跡にするなら、最低限次の 7点 を残してください。
この7点があれば、「誰が、何を見て、どんな結論を、どの時点で出したか」を後から再現しやすくなります。
FIRST は、PSIRT が追跡システムを持ち、脆弱性情報を安全に保管し、影響製品や派生まで把握できることを推奨しています。
すべての証跡を紐付けるユニークなキー
どの構成（バージョン）に対する判断か
対応必須 / 要確認 / 対応不要（VEXなら affected / under_investigation / not_affected）
なぜその結論に至ったか（1〜3行程度）
設定状態、到達性、機能ON/OFFなどの前提
SBOM、構成表、設定書、試験結果などへの参照
未完了案件の放置を防ぐ期限、または完了の定義
なぜ“トリアージ結果”が証跡にならないのか
現場でよくある失敗は、技術的な判断そのものよりも 「残し方（プロセス）」 にあります。
1. 案件IDが無い
メールの件名やチャットスレッドだけで仕事を進めると、後から追えません。FIRST も system(s) of record（記録システム）の必要性を明示しています。
2. 対象版数が曖昧
「この製品には影響なし」では弱く、どの版に対する判断か が明記されていないと監査やOEM照会で差し戻されます。FIRST は reproduction/analysis の中で、どの製品とその variants（派生）が影響を受けるかを特定すること を重視しています。
3. 理由が短すぎる、または無い
「閉域だから」「非該当だから」だけでは説明になりません。必要なのは、何を見て、どういう前提でそう判断したか というロジックです。
4. 証跡が散らばっている
ファイルやログはあるものの、それが「どの案件のどの判断に紐づくか」が分からない状態です。FIRST は vulnerability reports や PoC などの sensitive information を安全に保管し、必要な人だけがアクセスできるべきだとしています。
手順：トリアージ結果を監査証跡へ変える（6ステップ）
1まず案件IDを振る
どんなに小さく、すぐに「影響なし」と判断できる案件でも、まず案件ID（チケット番号等）を付けます。これがないと、判断結果も証跡も履歴も、すべてがバラバラになります。
2対象版数を先に切る
判断より先に、「対象製品名・対象版数・対象機能/ECU」を明記します。ここが曖昧だと、いくら素晴らしい技術的結論を出しても、監査のベースが崩れます。
3結論は3分類で固定する
最初は次の3分類だけで十分です。
- 対応必須（affected）
- 要確認（under_investigation）
- 対応不要（not_affected）
重要なのは、担当者ごとのニュアンスのブレをなくし、結論の語彙を固定することです。
4理由は“1〜3行”で残す
長文のレポートを書く必要はありません。ただし、最低でも次のどれかの要素は入れてください。
5証跡は“添付”より“参照可能”を優先する
監査に強いのは、すべての巨大なファイルをメールに添付することではなく、どの判断がどの証跡を見たのかを辿れること です。「SBOM-123」「CFG-045」「TEST-009」のように、参照IDや社内リンクで残せると管理が強くなります。
6更新日とクローズ条件を決める
「要確認」なら次回更新日、「対応不要」や「対応必須で完了」ならクローズ条件を書きます。
CISA の guidance でも、track to resolution と target timelines の設定が求められているため、ここが抜けると監査員には“放置されている”ように見えます。
そのまま使える：トリアージ監査証跡メモ
社内チケットや台帳に、以下のフォーマットで記録を残しておけば、監査での防御力はかなり高くなります。
監査で強い“残し方”のコツ
「影響なし」「非該当」「問題なし」など言葉が混在すると、後で集計や検索がしにくくなります。
特にOEMへ外部回答として出す案件では、誰が作り誰が承認したかを分ける（四眼原則）と有効です。
SharePoint、Jiraチケット、専用フォルダなど、場所が常に1つに決まっているだけで運用が強固になります。
「調査中」から「影響なし」へ結論が変わった場合などに効きます。FIRSTも履歴・進捗・コメントを追跡できる状態を推奨しています。
OEM調査依頼や監査対応において、自社の運用に足りない要素（証跡・プロセス）を整理したい方はご相談ください。
【無料】オンライン相談を予約するよくあるNG例（監査で再燃するパターン）
-
NG1：結論だけ残す
「影響なし」という結果だけでは、監査やOEM照会で必ず「なぜ？」という追加質問が来ます。 -
NG2：チャットだけで終わる
フローとしては早くても、後から履歴や根拠を検索して追うことができず、案件台帳にも残りません。 -
NG3：証跡ファイル名がバラバラ
ファイルはあるものの、どの案件（CVE）に紐づく設計書なのか分からず、再利用性が著しく低くなります。 -
NG4：調査中に更新日が無い
期日がない調査は、外部から見ると“進行中”ではなく“放置（コントロール不可）”に見えます。
FAQ：監査証跡と記録の残し方
A. 最低限、「案件ID」「対象版数」「結論」「理由」「証跡参照先」「次回更新日」が揃っていれば、監査に対する防御力はかなり高くなります。
A. いいえ。容量も圧迫するため添付にこだわる必要はありません。後から確実に辿れる「参照先ID」や「共有フォルダの固定リンク」がある方が、運用しやすく確実です。
A. いいえ、弱くありません。「次回更新日」と「現在未確定な要素（何を調べているか）」が残っていれば、プロセスが適切にコントロールされていることの証明になり、十分に監査で説明可能です。
属人的な判断を、監査に強いデータへ自動変換。
Excelやメールのやり取りでは散逸してしまう「対象版数」「判断理由」「次回更新日」などの情報を、案件IDに紐付けて一元管理。Auto PSIRT Cloudなら、日々のトリアージ業務を行うだけで、そのままOEMへの回答書や監査証跡（VEX）として出力できる運用フローが手に入ります。