スキャナーは何百もの CVE を検出します。NVD は深刻度を示し、CISA KEV はいつかどこかで悪用されたことを示します。課題は CVE を見つけることではなく、積極的な悪用、資産の露出、コンプライアンス範囲、脅威アクターの関連性など、チームの現在の優先事項にとって重要なシグナルを把握することです。
VulnCheck コミュニティ データは、2 つの一括 ZIP ダウンロードを通じて、より豊富なシグナルセットを提供します。Python での使用方法を順に説明します。
console.vulncheck.com(コミュニティ ティア)に登録します。アカウント作成、API トークンの生成、最初の一括ダウンロードを含む完全なセットアップについては、入門ガイドをご覧ください。コミュニティで利用できる機能の概要については、VulnCheck コミュニティを使用する上位 5 つの理由をご覧ください。
関連する 2 つのフィードは次のとおりです。
vulncheck-kev.zip — VulnCheck の強化された KEV データセット。スキーマとフィールド リファレンス: vulncheck-kev スキーマnist-nvd2.zip — CVSS ベクター、CWE 分類、脆弱性メタデータを含む JSON 形式の NIST NVD2 データ。補足コンテキストとして有用ですが、スキャナーはすでにこのデータを提供していますKEV エントリには、悪用の確認だけでなく、脅威コンテキストも含まれています。どのシグナルが重要かは、チームのその時点での優先事項によって異なります。実際のエントリを例に示します。
{
"cve": ["CVE-2022-22954"],
"knownRansomwareCampaignUse": "Known",
"vulncheck_xdb": [
{
"exploit_type": "initial-access",
"clone_ssh_url": "git@github.com:sherlocksecurity/VMware-CVE-2022-22954.git",
"date_added": "2022-04-11T13:59:13Z"
}
],
"vulncheck_reported_exploitation": [
{
"url": "https://www.vmware.com/security/advisories/VMSA-2022-0011.html",
"date_added": "2022-04-06T00:00:00Z"
},
{
"url": "https://www.cisa.gov/.../known_exploited_vulnerabilities.json",
"date_added": "2022-04-14T00:00:00Z"
},
{
"url": "https://blog.morphisec.com/vmware-identity-manager-attack-backdoor",
"date_added": "2022-04-25T00:00:00Z"
}
],
"reported_exploited_by_vulncheck_canaries": true,
"date_added": "2022-04-06T00:00:00Z",
"cisa_date_added": "2022-04-14T00:00:00Z"
}
VulnCheck KEV への掲載自体がシグナルです。このカタログは CISA が公開しているものを超えた悪用証拠を追跡しており、通常はより早く検出します。
vulncheck_reported_exploitation[] — 悪用を公開報告したすべてのソースのタイムスタンプ付きリスト。ソース数と新しさが、進行中のキャンペーンと過去の記録を区別します。
reported_exploited_by_vulncheck_canaries — VulnCheck カナリアが実際のネットワーク トラフィックでこの CVE を標的とするライブ攻撃トラフィックを観測した場合に true。
knownRansomwareCampaignUse — "Known" はランサムウェア グループがこの CVE を積極的に使用していることを意味します。
date_added vs cisa_date_added — VulnCheck が悪用を最初に追跡した日と CISA が公開した日の差。上記の例では VulnCheck が 4 月 6 日、公開エクスプロイト コードが 4 月 11 日、CISA が 4 月 14 日です。この差が大きいほど、CISA のみのワークフローでの露出リスクが高くなります。
vulncheck_xdb[] — VulnCheck のエクスプロイト データベース: 各アーティファクトは exploit_type で分類され、リポジトリへの clone_ssh_url が含まれます。NVD も CISA もこの分類を提供しません。エントリがある場合、概念実証から完全に動作するものまでエクスプロイト コードが存在することを示します。タイプの定義については、エクスプロイト タイプ分類リファレンスをご覧ください。
スキーマ内の他のシグナルは異なる優先順位の観点に対応しています。SSVC は意思決定フレームワーク チーム向け、EPSS は確率ベースのスコアリング向け、ICS/OT および IoT タグはセクター固有のリスク向けです。ボットネットと脅威アクターのコンテキストは、構造化フィールドではなく vulncheck_reported_exploitation[] の悪用レポート URL を通じて示されます。
CVE ID のリストさえあれば十分です。脆弱性スキャナー、パッチ管理ツール、SIEM アラート、または手動でまとめたリストから取得できます。リストの取得元に関わらず、スコアリングの手順は同じです。
KEV ZIP を CVE ID でインデックス化してメモリに一度読み込み、リスト内の各 CVE を検索してチームにとって重要なシグナルでスコアリングします。
CVE ごとに LLM が読みやすいフィールド名の構造化レコードを出力します。各キーと値のペアは事実の記述として読め、データを直接扱うチームと LLM に渡すチームの両方に適しています。
import json, zipfile
with zipfile.ZipFile("vulncheck-kev.zip") as z:
raw = json.loads(z.read("vulncheck_known_exploited_vulnerabilities.json"))
kev = {cve_id: e for e in raw for cve_id in e.get("cve", [])}
results = []
for cve_id in your_cve_list:
k = kev.get(cve_id)
if not k:
continue
record = {
"cve": cve_id,
"used_in_active_ransomware_campaign": k.get("knownRansomwareCampaignUse") == "Known",
"live_exploitation_observed_in_honeypot": k.get("reported_exploited_by_vulncheck_canaries", False),
"public_exploit_no_auth_required": any(x["exploit_type"] == "initial-access"
for x in k.get("vulncheck_xdb", [])),
}
# only include CVEs with at least one signal active
if any(record[f] for f in record if f != "cve"):
results.append(record)
print(json.dumps(results, indent=2))
出力例:
[
{
"cve": "CVE-2022-22954",
"used_in_active_ransomware_campaign": true,
"live_exploitation_observed_in_honeypot": true,
"public_exploit_no_auth_required": true
},
{
"cve": "CVE-2024-12345",
"used_in_active_ransomware_campaign": false,
"live_exploitation_observed_in_honeypot": false,
"public_exploit_no_auth_required": true
}
]
どのシグナルを使用するか(およびその重み付け)は、サポートしたい意思決定によって異なります。CISO は経営陣への報告のためにランサムウェアとの関連を必要とし、セキュリティ アナリストはトリアージのために積極的な悪用シグナルを必要とし、パッチ チームは修復計画のためにエクスプロイトの有無を必要とします。
セキュリティ アナリストの観点を例にとると、問題は何を最初にパッチするかです。理論的に深刻なものではなく、現在積極的に悪用されているものです。true の値を数えることでソートのための簡単なスコアが得られます。
ranked = sorted(results, key=lambda r: sum(v for k, v in r.items() if k != "cve"), reverse=True)
等重みのカウントを実際の優先事項を反映したスコアリング関数に置き換えてください。シグナルが素材であり、スコアリング関数はご自身で定義します。出力をスプレッドシート、チケット、または LLM に直接渡してください。
上記のステップで作成した ranked JSON を、チームが使用できる LLM に渡します。フィールド名は LLM が読みやすいよう設計されており、各キーと値のペアは事実の記述として読めるため、プロンプトの足場なしにモデルがシグナルを直接推論できます。
プロンプト:
You are a security analyst. The following CVEs were detected by our scanner and enriched with vulnerability intelligence. Based on the signals present, help prioritize them for our team and summarize the risk for each in one sentence.
[paste ranked JSON here]
ここで示したシグナルは出発点です。より完全な優先順位付けの全体像には、SSVC 意思決定ツリー、EPSS 悪用確率、CVSS ベクター、ICS/OT および IoT 露出タグ、CAPEC 攻撃パターン、構造化されたボットネットおよび脅威アクターの帰属などの追加コンテキストが必要です。これらの一部は VulnCheck データセット内で利用可能で、それ以外はコミュニティ ティアを超える必要があります。これらのシグナルの背景にある優先順位付けフレームワークと考え方については、脆弱性の優先順位付けをご覧ください。