vuln-research

脆弱性リサーチ — CVE の詳細調査と適用可能性の評価

CVE が公開されたとき、問うべきなのは「このパッケージを使っているか」ではありません。それには dependency-audit が答えてくれます。確認すべきなのは次の点です。

• 脆弱なコードパスは、実際にこちらの利用方法で呼び出されますか？
• 悪用を容易にする公開済みの概念実証はありますか？
• パッチはありますか？いつ公開されますか？24 時間以内にデプロイできない場合、どのくらいの期間、リスクにさらされますか？
• パッチを適用できない場合、どのような緩和策がありますか？
• CISA は、現在悪用されている脆弱性として追跡していますか？

このスキルでは、そのワークフローを最初から最後まで説明します。最初に CVE を検出する dependency-audit と、対応方針を決定して一連のプロセスを完了する finding-triage を組み合わせて使用します。

認可

ユーザーが所有している、または評価を許可されているコード、依存関係、システムの脆弱性を調査してください。セキュリティアドバイザリー、パッチ、公開済みの解説を読むことに問題はありません。脆弱性の再現は、ユーザーが管理する隔離環境でのみ行い、テストを許可されていない稼働中のシステムに対しては決して行わないでください。公開前の詳細情報は、それを知る権利のある人だけに共有してください（「境界」を参照）。

ワークフロー

ステップ 1 — 信頼できる一次情報を確認する

信頼できる公式の説明から始めてください。以降の情報は要約されていたり、誤っていたりすることがあります。

• NVD レコード — https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN
• ベンダーのアドバイザリー — ベンダーのセキュリティページを検索してください。影響を受けるバージョンと修正内容の説明は、通常これが最も正確です
• GitHub セキュリティアドバイザリー — https://github.com/advisories/GHSA-...（多くの場合、NVD より簡潔で、NVD にない詳細が記載されていることもあります。親プロジェクトのセキュリティタブを確認してください）
• CISA の既知の悪用済み脆弱性カタログ — https://www.cisa.gov/known-exploited-vulnerabilities-catalog。CVE がここに掲載されている場合、現在悪用されているものとして扱い、CISA が定める期限までにパッチを適用してください
• EPSS スコア — https://www.first.org/epss/ — 悪用予測スコアリングシステムです。悪用される確率を 30 日間で予測します。CVSS が高く EPSS が低い脆弱性と、CVSS が中程度で EPSS が高い脆弱性を比較する際の判断材料として役立ちます

ステップ 2 — 影響を受けるバージョンを確認する

ベンダーのアドバイザリーでは、「X より前のバージョンに影響」のように曖昧な記述がされることがあります。正確な範囲を特定してください。

• ベンダーのリリースノートと修正コミットの履歴を確認します
• OSS プロジェクトの場合：パッチのコミット（通常はアドバイザリーに記載されています）を見つけ、git tag --contains <commit> を実行して、どのリリースに修正が含まれているか確認します
• クローズドソースの場合：アドバイザリーが唯一の情報源です。バージョンの比較は慎重に確認してください（セマンティックバージョニングが常に遵守されているとは限りません）
• モノレポや再配布元の場合：依存しているフォークやディストリビューションにも、同じ修正が適用されていることを確認します

ステップ 3 — 自分の環境に照らし合わせる

# Is the package installed at all?
npm ls <package>           # or yarn why <package>, pnpm why <package>
pip show <package>          # or pip list | grep <package>
bundle info <gem>
go list -m all | grep <package>

# What version exactly?
# Inspect lockfiles directly — the resolved version is what runs, not the range
grep -A1 '"<package>"' package-lock.json

# Where is it used?
# Direct dependency, transitive, dev-only?
npm ls <package> --omit=dev  # production-reachable?

推移的な依存関係の場合は、どの直接依存関係がそれを取り込んでいるかがわかるまで、依存関係ツリーをさかのぼってください。オーバーライド、バージョン固定、置き換えを行う箇所はそこです。

ステップ 4 — 到達可能性を分析する（効果の大きいステップ）

CVE が悪用可能なのは、脆弱なコードパスを実際に呼び出している場合だけです。ここで dependency-audit のノイズを取り除き、実際のリスクに絞り込みます。

パッチを読みます。 修正コミットを見ると、脆弱だった関数、ファイル、API を正確に特定できます。次に、以下を行います。

# Does your code call the vulnerable function directly?
grep -rn "vulnerableFunction\|VulnerableClass" . \
  --include="*.{js,ts,py,rb,go,java}" \
  --exclude-dir=node_modules

# Does the dependency call it internally even if you don't?
# Trickier — you have to read the parent's source. For an indirect call:
cd node_modules/<package>
grep -rn "vulnerableFunction" .

到達可能性の一般的な判定結果：

• 到達可能、直接的： 脆弱なコードを呼び出しています。最優先で、今すぐパッチを適用するか回避策を実施してください
• 到達可能、間接的： 依存関係が通常の使用の一環として脆弱なコードを呼び出しています。引き続き優先度は高いです
• 到達不能： 使用していない機能（別のモジュール、別のエントリーポイント、別のランタイム）に脆弱なコードがあります。優先度は低くなります。SLA の期限には影響しないものの、パッチの適用を推奨します
• 不明： 不明として記録し、慎重な判断に基づいてパッチを適用します

作業内容を示さずに「到達不能」と記載しないでください。利用方法が変わったとき、将来の自分が再確認することになります。

ステップ 5 — 公開 PoC と実際の悪用を確認する

• GitHub： コードとリポジトリで CVE-YYYY-NNNNN を検索します。脆弱性の公表から数日以内に PoC が投稿されます
• CISA KEV： 掲載されている場合、実環境で現在悪用されています
• Exploit-DB： https://www.exploit-db.com/ — 確認済みのエクスプロイト
• ベンダーのセキュリティメーリングリスト： 最新情報が得られる場合があります
• GreyNoise： https://www.greynoise.io/ — インターネット全体のスキャンに関するテレメトリーです。攻撃者がこれを大規模にスキャンしている場合、あなたのシステムが危険にさらされる期間はすでに始まっています
• Twitter / Mastodon のセキュリティコミュニティ — 速報を得るのに役立ちますが、対応する前に信頼できる情報源で確認してください

EPSS の解釈：

EPSS スコア	意味
> 0.7	今後 30 日以内に悪用される可能性が高いため、緊急対応として扱います
0.1 – 0.7	悪用される可能性が十分にあるため、通常のスケジュールでパッチを適用します
< 0.1	予測される悪用の可能性は低いため、都合のよいときにパッチを適用します

EPSS は実証データに基づいて調整されており、実際の悪用との相関は CVSS よりも高くなっています。

ステップ 6 — パッチを適用する／緩和する／リスクを受容する

パッチを適用する（推奨）：

• パッチ適用済みのバージョンがあり、すぐにデプロイできる場合は、パッケージをアップグレードしてテストを実行し、デプロイします
• 直接パッチがない推移的依存関係には、overrides（npm）／resolutions（yarn）／pin を使用して、パッチ適用済みのバージョンを強制します

緩和する（パッチを適用できない場合）：

• コードで必要としていない場合は、影響を受ける機能を無効にします
• 既知の悪意ある入力パターンをブロックするリクエストレベルのフィルター（WAF ルール、プロキシフィルター）を追加します。HTTP 経由で悪用される脆弱性の場合、数時間でデプロイできることもよくあります
• 信頼できないネットワークからアクセスできないよう、脆弱なサービスをネットワークセグメント化します
• 緩和策が失敗した場合でも悪用の試みを確認できるよう、検知機能を追加します（siem-detection を参照してください）

リスクを受容する（正当な理由がある場合に限る）：

• 利用環境では、脆弱なコードパスに実際に到達できません
• 脆弱なコンポーネントが、信頼できない入力を受け取らない内部専用サービスにあります
• 代替コントロールによって悪用の可能性や影響が十分に低減され、受容が正当化されます
• owasp-audit のレポート形式にある「受容したリスク」の判定を参照してください。必須項目は 3 つ（理由、代替コントロール、再評価の契機）です。例外はありません

ステップ 7 — 記録して対応を完了する

対応方針を決定した後：

• 脆弱性追跡システム（Jira、Linear、Vanta など）に決定を記録します
• リスクを受容する場合は、再評価日を設定し、カレンダーにリマインダーを登録します
• パッチを適用する場合は、npm ls／ロックファイルで、パッチ適用済みのバージョンが実際にデプロイされていることを確認します（段階的なロールアウトは、対応の決定と同じではありません）
• 緩和策を講じる場合は、次の担当者が緩和策の存在とその理由を把握できるよう、ランブックに記載します

よくある調査の落とし穴

• アドバイザリには「vX で修正済み」とあるのに、パッケージから vX がリリースされていない — 放棄されたプロジェクトで起こることがあります。既知の安全なフォークに overrides で切り替えるか、依存関係を置き換えます
• ベンダーがひそかにパッチを適用していた — CVE が公表される前に修正が取り込まれ、ひそかな修正より前のバージョンを対象にアドバイザリが公開されています。修正コミットが使用中のバージョンに含まれていることを確認してください
• CVE の対象が、同時に使用している関連パッケージにも当てはまる — 同じコードでも、名前が異なる場合があります（フォーク、モノレポ内の関連パッケージなど）。名前が挙がっているパッケージだけでなく、使用中のすべてのパッケージで脆弱な関数を検索してください
• CVSS は高いが EPSS は低い — 実環境で悪用するには複雑な前提条件があることを示す場合がほとんどです。パッチを適用しますが、慌てる必要はありません
• CVSS は中程度だが EPSS は高い — 大規模なスキャンですでに悪用されていることを示す場合がほとんどです。緊急対応として扱ってください
• PoC には取得が難しい認証が必要 — しかし、アプリケーションではその認証を簡単に取得できます（サインアップが公開されているなど）。攻撃者の「複雑さ」評価には、あなたの脅威モデルは考慮されていません

出力形式

# Vulnerability Assessment: CVE-YYYY-NNNNN
## Date: [date]
## Assessor: [name]

### Summary
- **Title:** [from advisory]
- **CVSS / EPSS:** [scores]
- **CISA KEV:** [yes / no, and due date if listed]
- **Affected versions:** [exact range]
- **Our version:** [version + how installed]

### Reachability
- **Direct call:** [yes / no — with evidence]
- **Indirect via dependency:** [yes / no — with evidence]
- **Verdict:** Reachable / Not reachable / Unknown

### Exploitation availability
- **Public PoC:** [yes / no — link]
- **Active exploitation:** [yes / no — source]

### Decision
- [ ] Patch (target deploy: [date])
- [ ] Mitigate (controls: [list]; re-evaluate: [date])
- [ ] Accept risk (why / compensating controls / re-eval trigger)

### Action items
| Item | Owner | Deadline |
|------|-------|----------|

### References
[Links to advisory, patch commit, PoC, EPSS, CISA, etc.]

範囲

• ユーザーが調査を許可されているコード、依存関係、またはシステムに影響する脆弱性を調査します
• エクスプロイトの開発、武器化、配布は行わないでください。既存の PoC は適用可能性の評価のみを目的として確認してください
• 内部限定の脆弱性や公開前の情報は、許可なく再配布しないでください
• 他者のコードに関する未報告の脆弱性が調査で見つかった場合は、責任ある開示に従ってください。公開も悪用もしないでください
• CVE の調査結果をシステムへの攻撃に利用する依頼は拒否してください

参考資料

• NVD（National Vulnerability Database）
• CISA Known Exploited Vulnerabilities Catalog
• GitHub Security Advisories Database
• EPSS（Exploit Prediction Scoring System）— FIRST.org
• MITRE CVE — cve.mitre.org（現在は cve.org にリダイレクトされます）
• Exploit-DB
• GreyNoise — インターネットスキャンのテレメトリー
• 開示時期の参考となる「Patch Tuesday」／ベンダー固有の公開スケジュール
• 責任ある開示のタイムラインに関する参考資料である Project Zero disclosure policy