ベンダーから届く脆弱性情報を自社のIT資産台帳と突き合わせて、対応が要るものを選ぶ

処理の起点を決める

毎朝決まった時刻に動かします。 n8n の Schedule Trigger では、Seconds / Minutes / Hours / Days / Weeks / Months / Custom (Cron) の7種類から間隔を選べます。Custom (Cron) では「(秒) 分 時 日 月 曜日」の6フィールドで指定でき、先頭の秒は省略できます。

タイムゾーンの設定を最初に確認してください。 n8n のタイムゾーンは、ワークフローに設定があればそれが使われ、なければインスタンスの設定が使われます。セルフホストの既定は America/New York、n8n Cloud では GMT です。既定のままだと、日本時間の朝に動きません。

ベンダーからのメール通知は、専用の受信箱に集めて、同じ実行の中で取り込みます。メールの到着ごとに動かす作りにしません。1日1回にまとめたほうが、重複の処理も一覧の作成も単純になります。

入力データを集める

別名辞書がこの構成の中核です。 「Apache HTTP Server」を台帳では「Web サーバ（本番）」と書いている、というずれを吸収します。辞書は最初から完璧である必要はありません。 該当なしと判定された情報を週次で見返し、実は使っていた製品が見つかるたびに足していきます。

データの取得方法を決める

JVN iPedia： MyJVN API の getVulnOverviewList を使い、公開日の範囲で前日以降を取得します。feed=hnd が必須です。1回50件が上限なので、返ってきた件数が上限に達していれば、日付をずらして繰り返します。

ベンダー通知： 主要なベンダーのセキュリティ通知を専用アドレスで購読します。HTMLメールが多いので、本文をテキストに変換してから処理します。

IT資産台帳： 資産管理ツールのAPIまたはCSVエクスポートで、日次に取り込みます。リアルタイムである必要はありませんが、更新頻度は重要です。 月次更新の台帳では、先月導入したサーバーが載っていません。

AIへ渡す前に整形する

1. 重複の除去 … 同じ脆弱性が、公開データベースとベンダー通知の両方から届きます。脆弱性の識別子で重複を検出します
2. 既知のものの除外 … 過去に判定済みの脆弱性が再度届くことがあります。識別子で過去の判定を引き、変更がなければ処理を飛ばします
3. 製品名の正規化 … 大文字小文字、スペース、バージョン番号の付き方をそろえます
4. バージョン表記の構造化 … 「8.4.1-r2」を、主バージョン・副バージョン・パッチ・リビジョンに分解します。この分解ができないと比較ができません
5. 台帳の突合用インデックス … 台帳を製品名ごとにまとめた表を朝一番に作っておきます。240件それぞれで全件検索すると遅くなります

AIに処理させる

AIと自前の処理で役割を分けます。

自前の処理にさせること： バージョンの範囲比較、緊急度の計算、重複の除去、台帳の検索。バージョン比較をAIにさせないでください。 「8.4.1-r2 は 8.1.3 以上 8.4.2 未満に入るか」は比較演算であって判断ではありません。AIにさせると、まれに誤り、誤ったときに気づけません。

AIにさせること：

4つ目が実務上いちばん役に立ちます。 深刻度の数値が高くても、「管理者権限を持つローカルユーザーによる操作が前提」なら緊急度は下がります。この前提条件は本文を読まないと分かりません。

指示内容を固定する

あなたは情報システム部門の運用担当を支援する立場です。
公開された脆弱性情報を読み、自社での対応判断に必要な項目を抽出してください。

【厳守事項】
- 情報に書かれていないことを補わないでください。
  影響バージョンの記載がなければ affected_versions を空にしてください。
  「おそらく全バージョン」のような推測を入れないでください。
- 自社が影響を受けるかどうかの判断はしないでください。
  台帳との突き合わせは後段の処理が行います。
- バージョンの大小を比較しないでください。
  範囲の表現をそのまま構造化して返すことだけが役割です。
- 製品名は、情報に書かれた正式名を product_name_official に入れ、
  自社台帳の候補は candidates に列挙してください。1つに決めないでください。
- 攻撃の前提条件（認証の要否、到達経路、ユーザー操作の要否）は、
  本文に記載がある場合のみ書いてください。記載がなければ null にしてください。
- 回避策は、本文に書かれた内容をそのまま workaround に入れてください。
  一般的な対策（ファイアウォールで遮断するなど）を補わないでください。

【脆弱性情報の本文】
{advisory_text}

【自社台帳にある製品名の一覧（同じベンダーのもの）】
{asset_products}

「バージョンの大小を比較しないでください」を明示するのは重要です。 指示しないと、AIは親切に「該当します」と答えます。その答えが正しいかどうかを、人は確かめようがありません。 比較は数値の処理として自前で行い、結果を追跡できる形にします。

出力形式を固定する

{
  "advisory_id": "",
  "product_name_official": "",
  "vendor": "",
  "candidates": [
    { "asset_product_name": "", "match_reason": "" }
  ],
  "affected_versions": [
    { "operator": "lt | le | gt | ge | eq | range", "from": "", "to": "" }
  ],
  "severity_score": null,
  "attack_prerequisites": {
    "authentication_required": null,
    "network_reachable": null,
    "user_interaction_required": null
  },
  "workaround": "",
  "plain_summary": "",
  "extraction_confidence": "high | medium | low"
}

突き合わせの結果は、自前の処理が作ります。

{
  "advisory_id": "",
  "matched_assets": [
    {
      "asset_id": "",
      "installed_version": "",
      "in_range": true,
      "externally_exposed": true,
      "importance": "high | medium | low"
    }
  ],
  "urgency": "immediate | this_week | this_month | monitor",
  "match_status": "matched | no_match | not_determinable"
}

match_status に not_determinable を必ず用意します。「台帳に製品名がなかった」と「台帳にあったが該当しなかった」を区別しないと、見落としが起きます。

システムへ連携する

IT資産台帳への書き込みはしません。 脆弱性の対応状況は別の台帳に持ちます。資産台帳を汚すと、資産管理そのものが破綻します。

修正版の適用（パッチ適用）を自動化しません。 これは別の話です。適用のタイミングは、業務への影響と検証の結果で決まります。この構成が扱うのは、適用すべきものを選ぶところまでです。

人が確認する

確認は2種類あります。

1つ目は、該当ありと判定されたものです。 月に10〜15件なので、1件ずつ丁寧に見られます。対応の期限と担当を決めるのは人です。

2つ目は、該当なしと判定されたものの振り返りです。 週に1回、no_match と not_determinable の一覧を見ます。とくに not_determinable（台帳に製品名がなかったもの）は必ず見てください。 別名辞書の不足か、台帳の不備のどちらかです。

確認を速くするための設計が重要です。

• 緊急度順に並べ、immediate を最上位に出す
• 該当した資産名と設置場所を一覧の中に展開する
• 攻撃の前提条件を、深刻度の数値より目立たせる
• 回避策がある場合、その旨を一覧に出す
• not_determinable を no_match と分けて表示する

深刻度の数値だけで並べないでください。 数値が高くても外部から到達できない資産と、数値が中程度でも公開サーバーにある資産では、後者を先に対応します。

例外に対処する

記録を残す

• 取得した脆弱性情報の原文と、取得日時
• AIが抽出した項目と extraction_confidence
• 突き合わせの結果（matched / no_match / not_determinable）と、使った台帳のスナップショット日付
• 人が判定を覆したかどうか
• 対応の期限、担当、完了日
• 別名辞書に追加した内容と、そのきっかけ

3つ目の「使った台帳の日付」が重要です。「なぜこの脆弱性を対応不要と判断したのか」を後から問われたときに、当時の台帳を再現できる必要があります。 ISMSの審査ではここが見られます。

保存期間は、自社の情報セキュリティ規程に合わせます。脆弱性対応の記録は、監査の証跡として最低でも3年は残すのが一般的です。