ClaudeとRapid7 InsightVMを連携し脆弱性をSQLで優先付けする
Rapid7 Bulk ExportコネクタはInsightVMの脆弱性・資産データをDuckDBに取り込み、SQLで分析します。エクスポートの仕組み、使えるフィールド、優先度付けのSQLの型をまとめます。
Rapid7 Bulk Exportコネクタは何をするものか
Rapid7 Bulk Exportコネクタは、Rapid7が提供するConnectorです。Rapid7のBulk Export APIから脆弱性と資産のデータを取得し、ローカルのDuckDBデータベースに読み込んで、SQLのクエリツールとしてClaudeに渡します。ディレクトリ上では「Anthropic verified」の表示が付き、2026年8月に追加されました。
InsightVMのコンソールで絞り込むのではなく、データ一式をエクスポートして手元でSQLを書く。これがこのコネクタの入口です。「重大度がCriticalで、悪用される確率が高く、重要な資産に載っているものはどれか」のような、画面のフィルタでは組みにくい条件を、Claudeに頼んでSQLにしてもらえます。
ディレクトリの説明には、できることが3点書かれています。
- エクスポートの再利用
- EPSS(悪用される確率を示す指標)に基づく優先度付け
- クラウドをまたいだ脆弱性の追跡
脆弱性の深刻度そのものの考え方は、Claude Securityの脆弱性タイプと深刻度の判定基準が扱っています。こちらはClaudeが自分のコードをスキャンする機能の話です。Rapid7のスキャン結果を分析するこのコネクタとは対象が違います。
エクスポートとコンソールは何が違うか
Bulk Export APIはGraphQLのAPIで、データはParquet形式で返ります。Rapid7のドキュメントによると、ポリシー・資産・脆弱性・修復(remediation)のデータを出せます。画面のカードやクエリビルダーで見るのとは別の経路です。
違いを表にします。
| 観点 | コンソールでの確認 | Bulk Export + SQL |
|---|---|---|
| 形式 | コンソールでの確認画面上のカード・一覧 | Bulk Export + SQLParquetファイル |
| 条件の組み方 | コンソールでの確認画面のフィルタ | Bulk Export + SQL任意のSQL |
| データの鮮度 | コンソールでの確認画面の表示 | Bulk Export + SQLシステムが1日1回更新したデータ |
| 結合・集計 | コンソールでの確認画面の機能の範囲 | Bulk Export + SQL資産と脆弱性を自由に結合 |
鮮度には注意が必要です。ドキュメントには、データはシステムにより1日に1回更新されると書かれています。エクスポートは何度でも要求できますが、使いすぎるとスロットリングされることがあります。スキャン直後の結果を即座に見たい用途には向きません。
接続前に必要な権限と前提
Bulk Export APIを使うには、組織(Organization)のAPIキー、またはPlatform Administrator権限を持つユーザーのAPIキーが必要です。キーは X-Api-Key ヘッダーで渡します。リージョンごとにエンドポイントが分かれていて、米国は3つ、ほかに欧州・カナダ・オーストラリア・日本があります。
コネクタを使う側でこの前提が効く場面は2つあります。
- 権限の強いAPIキーを使うことになるため、キーの保管と発行者の確認が要る
- APIキーが属するリージョンのURIを選ぶ必要がある(ドキュメントの指定)
コネクタ自体の追加はClaudeのコネクタ一覧からできます。ただしコネクタのページ上で、APIキーをどこに入力するかは説明されていません。設定の詳細はページのSupportリンク先で確かめてください。ディレクトリには、信頼できる開発元のコネクタだけを使うようにという注意書きもあります。
コネクタが持つ8つのツール
コネクタのページには、次の8つのツールが載っています。
| ツール | 名前から読める役割 |
|---|---|
start_rapid7_export | 名前から読める役割エクスポートの開始 |
check_rapid7_export_status | 名前から読める役割エクスポートの状態確認 |
download_rapid7_export | 名前から読める役割エクスポートのダウンロード |
load_rapid7_parquet | 名前から読める役割ParquetをDuckDBに読み込む |
query_rapid7 | 名前から読める役割SQLの実行 |
get_rapid7_schema | 名前から読める役割スキーマの取得 |
get_rapid7_stats | 名前から読める役割統計の取得 |
list_rapid7_exports | 名前から読める役割過去のエクスポートの一覧 |
右の列は、ツール名から読んだ役割です。ページに個別の説明はありません。
並びは、Rapid7のドキュメントが示す手順と対応しています。APIの手順は「エクスポートを要求する」「状態を確認する」「Parquetをダウンロードする」の順です。コネクタはこれにDuckDBへの読み込みとSQL実行を足した形です。
Bulk Export APIのドキュメントでは、状態が SUCCEEDED になるとダウンロードURLが並びます。URLは生成から15分間有効で、その間は何度でもダウンロードできます。URLは最初の要求から30日以内なら再生成でき、ファイル自体も30日で消えます。list_rapid7_exports と「エクスポートの再利用」は、この保持期間があるから意味を持つ機能です。同じデータを何度もエクスポートし直さずに済みます。
SQLで分析できるフィールド
優先度付けの材料は、脆弱性のエクスポートに入っています。Rapid7のドキュメントに載っているフィールドから、分析によく使うものを選びます。
| 分類 | フィールド | 内容 |
|---|---|---|
| 重大度 | フィールドseverity / severityScore | 内容Rapid7の重大度(Criticalなど) |
| CVSS | フィールドcvssV3Score / cvssV3Severity | 内容CVSS v3のスコアと重大度 |
| 悪用の可能性 | フィールドepssscore / epsspercentile | 内容EPSSのスコアとパーセンタイル |
| 悪用の実績 | フィールドhasExploits / threatFeedExists | 内容悪用コードやスレットフィードの有無 |
| リスク | フィールドriskScoreV2_0 | 内容アクティブリスクスコア |
| 資産 | フィールドhostName / ip / tags / riskScore | 内容ホスト名・IP・タグ・資産のリスクスコア |
| 修復 | フィールドbestSolutionSummary | 内容推奨される修復作業の要約 |
EPSSは、ある脆弱性が今後30日以内に実環境で悪用される確率を0から1で示す指標です。epsspercentile は、そのCVEよりスコアが同じか低いCVEが全体のどれだけを占めるかを示します。
資産側には tags があり、{name: tag1, tagType: Owner} のように所有者や場所のタグを持てます。「重要な資産」の判定にこのタグを使えるかどうかは、各社のタグ運用次第です。
対応優先度を付けるSQLの型
重大度だけで並べると、Criticalの件数が多い環境では優先順位がつかなくなります。次の3段階で絞るのが、フィールドの構成に沿った考え方です。
優先度付けの流れ
- 1
スキーマを確かめる
get_rapid7_schemaでテーブルと列名を確認します。DuckDB上のテーブル名は、ドキュメントのエクスポート名と一致するとは限りません。 - 2
悪用の可能性で絞る
重大度の高い脆弱性のうち、EPSSの高いもの、悪用コードがあるものを残します。
- 3
資産の重要度と掛け合わせる
残った脆弱性を、資産のタグやリスクスコアと結合して、重要な資産から並べます。
次のSQLは、Claudeに作らせるクエリの例です。テーブル名は仮置きで、実際は get_rapid7_schema の結果に合わせて直します。フィールド名はRapid7のドキュメントに載っているものです。
-- 例: 重大度・EPSS・悪用コードの有無で絞り、資産ごとに集計する
SELECT
a.hostName,
a.ip,
COUNT(*) AS vuln_count,
MAX(v.epssscore) AS max_epss,
MAX(v.riskScoreV2_0) AS max_risk
FROM asset_vulnerability v
JOIN asset a USING (assetId)
WHERE v.severity = 'Critical'
AND (v.epssscore >= 0.1 OR v.hasExploits)
GROUP BY a.hostName, a.ip
ORDER BY max_epss DESC, vuln_count DESC
LIMIT 50;しきい値の 0.1 は説明のための値で、公式の推奨ではありません。EPSSの分布は環境によって違うため、最初に get_rapid7_stats や分布の集計を見て、自社のデータに合う値を決めるほうが確実です。
Claudeへの頼み方は、結果の見方まで含めて指定すると安定します。
- 「CriticalかつEPSS上位のものを資産ごとに集計して」
- 「集計に使ったSQLも一緒に出して」
- 「タグが付いていない資産は別枠で件数だけ出して」
SQLを一緒に出させるのは、結果を後から再現できるようにするためです。同じクエリを別の日のエクスポートに当てれば、件数の変化を比べられます。
「重要な資産」をどう決めるか
エクスポートの asset には riskScore と tags が入っています。ただし、どの資産が事業上重要かはRapid7が知っているわけではありません。タグに所有者や場所を付けている環境なら、そのタグで絞れます。付けていない環境では、先にタグの整備が要ります。
目安として、次の順で考えると進めやすくなります。
- 外部公開しているホストやドメインコントローラーなど、重要な資産の一覧を人が決める
- その一覧をタグまたは資産IDのリストとしてClaudeに渡す
- 重大度・EPSS・悪用コードの条件と掛け合わせる
3番目の条件で見つかった脆弱性には、bestSolutionSummary が修復の手がかりになります。ドキュメントの例では「Upgrade gnupg」のような短い作業名が入ります。詳細な手順は bestSolutionFix に入り、HTMLを含むことがあります。
修復の進み具合は、別のエクスポートで追えます。脆弱性修復(remediation)のエクスポートは、2025年8月以降の期間を指定し、開始日と終了日は同じ日にできず、31日を超えて離せません。
使う前に押さえたい制約
- 権限: Platform Administrator権限のAPIキーが前提になる
- 鮮度: データは1日1回の更新で、リアルタイムの状態ではない
- 保持: エクスポートファイルとダウンロードURLの有効期間に上限がある(ファイルは30日、URLは生成から15分)
- 取り込み: データ量が多い環境では、1つのprefixに複数のURLが付くことがある
- 修復エクスポート: 期間指定が必須で、31日を超えられない
- プライバシー:
proofやdescriptionには環境固有の情報(パス、パッチ番号など)が入る
最後の項目は、会話に何が流れるかに関わります。proof にはドキュメントの例でも、Windowsのレジストリのパスや未適用のパッチ番号が入っています。SQLで SELECT * を使うと、これらがClaudeの会話に出ます。分析に不要な列は、最初から選ばない書き方にしておくのが安全です。
ほかのデータ分析コネクタとの使い分け
脆弱性管理のデータをSQLで切る用途に、このコネクタは絞られています。BIツールで可視化したいならClaudeとTableauを連携する方法、データ基盤上のデータを自然言語で引くならClaudeとDatabricksを連携する方法が別の入口です。
Claude CodeからDuckDBを直接扱う選択肢もあります。ClickHouse・DuckDB・BigQueryのMCP比較で、各データベースを接続したときの違いを整理しています。ただし、Rapid7のエクスポート取得からParquetの読み込みまでを一続きで済ませたいなら、このコネクタがその流れをツールとして持っています。
よくある質問
コンソールで見えている件数とSQLの件数が合わないのはなぜか
エクスポートはシステムが1日1回更新したデータです。直近のスキャン結果は反映されていないことがあります。また、vulnerability_exception(脆弱性の例外)は別のファイルで出るため、例外扱いの脆弱性を含めて数えるか除くかでも件数が変わります。
EPSSだけで優先度を決めてよいか
EPSSは、30日以内に悪用される確率を示す指標です。資産の重要度や、すでに悪用コードがあるかどうかは含みません。ドキュメントのフィールドにも hasExploits や資産の riskScore が別にあるため、組み合わせて見る前提の指標です。