> For the complete documentation index, see [llms.txt](https://help.aikido.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aikido.dev/docs/docs-ja/aikido-agent/cve-exploitability-analysis.md).
# CVEの悪用可能性分析
CVE 悪用可能性分析では、 [Aikido Agent](/docs/docs-ja/aikido-agent/aikido-agent.md) を使用して、リポジトリおよびコンテナ内のオープンソース依存関係の CVE を評価します。すべての CVE を同じ緊急度で扱うのではなく、Agent は脆弱なパッケージがコードまたはコンテナイメージ内でどのように使用されているかを読み取り、その検出事項が環境内で実際に悪用可能かどうかを判断し、許可されたトリアージアクションを実行します。
これは **クレジット制の** 自動化です（リポジトリ／コンテナごとに設定可能）。で一度設定すると、 [トリアージ設定](https://app.aikido.dev/settings/advanced)、Aikido は毎晩、一致する未解決の CVE 検出事項に対して分析を実行します。また、 [必要に応じて実行を開始する](#run-analysis-on-demand) と [履歴内のすべての実行を確認する](#review-analysis-history).
## ユースケース
* ✨ **依存関係のノイズを削減**：コードまたはコンテナ内で悪用不可能な CVE を自動的に無視または重要度を下げます
* 🎯 **実際のリスクを優先**：Agent が、CVE は基本スコアが示すよりも悪用しやすいと判断した場合に重要度を上げます
* ⚙️ **自動化を制御**：自動的に実行するアクションと、承認が必要なアクションを選択します
* 🔍 **環境固有の根拠を取得**：パッケージの使用方法に基づく分析により、一般的な CVE の説明を超えた情報を得られます
## 仕組み
CVE 悪用可能性分析は、リポジトリおよび [リンクされたコンテナ](/docs/docs-ja/kontenaimjisukyan/configuration/link-repository-to-container.md)にある、既存の未解決の依存関係検出事項をトリアージします。Aikido Agent は各 CVE を評価し、重要度の変更、スヌーズ、検出事項の無視など、許可されたアクションを適用します。
* **リポジトリ**：Agent は、脆弱なパッケージがコード内でどのように使用されているかを読み取ります。
* **コンテナ**：Agent は、Dockerfile、ベースイメージ、ディストリビューションなどのイメージコンテキストに加え、コンテナの実行方法を使用します。
検出事項が無視されると、その理由が表示されます **CVE は悪用不可能と判断されました** （issue の重要度内訳内）。
{% hint style="info" %}
これは次を補完します： [到達可能性分析](/docs/docs-ja/hajimeni/reachability-analysis/introduction-to-reachability-analysis.md)。これは、脆弱なコードへの実行経路がない検出事項を除外します。CVE 悪用可能性分析は、その上にコードおよびコンテナのコンテキストに基づく Agent の推論を追加します。
{% endhint %}
## クレジットと利用可能性
* **CVE トリアージ 1 件につき Aikido クレジット 1**：Agent が分析する各 CVE は、次のクレジットを 1 つ消費します： [Aikidoウォレット](/docs/docs-ja/miscellaneous-info/wallet-and-credits.md)。検出事項がリポジトリ内かコンテナ内かは問いません。
* **管理者アクセスが必要**：CVE 悪用可能性分析の設定を表示および変更できるのは、ワークスペース管理者のみです。
## CVE 悪用可能性分析を設定する
{% stepper %}
{% step %}
### 設定を開きます
次へ移動します： **設定** → **トリアージ**、次を見つけます： **CVEの悪用可能性分析** セクションを開き、次をクリックします： **管理**.
{% endstep %}
{% step %}
### CVE 悪用可能性分析を有効にする
オンにする **CVE 悪用可能性分析を有効にする** して、以下のフィールドを編集します。有効にすると、Aikido は設定した重要度、リポジトリ、コンテナのスコープに一致するすべての未解決の検出事項に対して分析を実行します。
{% endstep %}
{% step %}
### スコープを設定する
* **最小重要度**：トリアージする検出事項を選択します： **Critical のみ**, **High 以上**, **Medium 以上**、または **すべての重要度**.
* **リポジトリ**：分析を実行するリポジトリを選択します。一度に多くのクレジットを消費せずに機能を試すには、より小さいスコープから開始してください。
* **コンテナ**：分析を実行するコンテナを選択します。次のコンテナのみが [リポジトリにリンクされている](/docs/docs-ja/kontenaimjisukyan/configuration/link-repository-to-container.md) 対象となります。
スコープには少なくとも 1 つのリポジトリまたはコンテナが必要です。
{% endstep %}
{% step %}
### 許可するアクションを選択する
次の項目の下で **許可されたアクション**、各結果を次のいずれかに設定します： **完全自動化** または **人による承認**:
* **重要度を下げる**：環境内で CVE のリスクが低い場合に重要度を下げます
* **重要度を上げる**：悪用可能性が基本スコアの示す値より高い場合に重要度を上げます
* **スヌーズ**：指定日まで検出事項を一時的に非表示にします
* **無視**：CVE が環境内で悪用不可能な場合に、検出事項をフィードから削除します
次の場合、 **完全自動化**では、Agent は分析直後にアクションを適用します。次の場合、 **人による承認**では、Agent はアクションを提案し、次の場所からの承認を待ちます： [分析履歴](#approve-proposed-actions).
{% endstep %}
{% step %}
### 利用上限を設定する
次を設定 **1 日あたりの利用上限** を設定して、分析が 24 時間以内に使用できるクレジット数を制限します（デフォルトは 100）。この上限はリポジトリとコンテナの CVE で共有されます。 **Inbox Zero までのコスト** の見積もりには、選択したリポジトリとコンテナに一致する CVE の数、完全な実行で使用するクレジット数、および利用可能なクレジットが表示されます。
{% endstep %}
{% endstepper %}
## Agent が変更できる内容
| アクション | 使用される場合 | 表示内容 |
| ----------- | ------------------------------------- | ---------------------------------------- |
| **重要度を下げる** | CVE は実在しますが、基本の重要度が示すよりも環境内で悪用されにくい場合 | Agent が提供する理由とともに重要度スコアが下がります |
| **重要度を上げる** | CVE が基本の重要度が示すよりも環境内で悪用されやすい場合 | Agent が提供する理由とともに重要度スコアが上がります |
| **スヌーズ** | この検出事項は今ではなく後で対応が必要な場合 | Agent が設定した日付まで、理由とともに検出事項がスヌーズされます |
| **無視** | CVE は環境内で悪用不可能な場合 | 理由とともに検出事項が無視されます **CVE は悪用不可能と判断されました** |
重要度の変更は、検出事項の現在の重要度が Agent が分析した時点の重要度と引き続き一致する場合にのみ適用されます。分析とアクションの間に重要度が変更された場合（たとえば別のルールによる変更）、更新の競合を避けるため変更はスキップされます。
## 必要に応じて分析を実行する
分析は毎晩自動的に実行されますが、夜間ジョブを待つ必要はありません。 **CVEの悪用可能性分析** セクション（設定／トリアージから）で、次をクリックします： **分析を開始** すると、スコープに一致する CVE の実行が直ちにキューに追加されます。
各実行では、1 日あたりの利用上限と利用可能なクレジットが考慮されます。同時に実行できるのは 1 件のみです。実行中は、 **分析を開始** は無効になり、次のように表示されます： *すでに分析が進行中です*。実行する内容がない場合、Aikido はその理由を通知します（たとえば、クレジット不足、1 日あたりの利用上限への到達、一致する issue が見つからなかった場合など）。
## 分析履歴を確認する
各実行は記録されるため、Agent が何を分析し、何を実行したかを確認できます。次をクリックします： **履歴を表示** CVE 悪用可能性分析セクションで、次を開きます： **CVE 悪用可能性履歴** ページ上で使用します。
履歴テーブルには、各実行の日付、パッケージまたはコンテナ、リポジトリ、分析した CVE の数に加え、実行されたトリアージアクション（無視、スヌーズ、重要度上げ、重要度下げ）が表示されます。紫色の **保留中** バッジは、Agent が提案したものの適用していないアクションを示します。検索フィルターとリポジトリフィルターを使用してリストを絞り込めます。
任意の実行をクリックすると、その詳細が開き、次の項目が表示されます：
* Agent によって作成された **要約** （実行の）
* 次の **分析された issue**。各 CVE に対して実行されたアクションと Agent の根拠が含まれます
* ある **タイムライン** （実行の）
### 提案されたアクションを承認する
アクションが次に設定されている場合、 **人による承認**、Agent は推奨内容を記録しますが、適用はしません。実行詳細では、保留中のアクションは次のように表示されます： **無視を承認**, **スヌーズを承認**, **重要度下げを承認**、または **重要度上げを承認**。バッジをクリックすると、Agent の根拠が事前入力された該当のトリアージフローが開きます。確認後、履歴内のアクションは実行済みとしてマークされます。
## 重要な注意事項
* 分析は **毎晩** 機能が有効になっているワークスペースで実行され、また、 [必要に応じて開始する](#run-analysis-on-demand)こともできます。設定に一致する新しい検出事項は、以降の実行で取得されます。
* ある **1 日あたりの利用上限** は、分析が 1 日に使用できるクレジット数を制限します（デフォルトは 100）。この上限はリポジトリとコンテナの CVE で共有されます。上限に達すると実行は停止し、翌日に再開されます。
* コンテナ分析は、次の条件を満たすコンテナでのみ実行されます： [コードリポジトリにリンクされている](/docs/docs-ja/kontenaimjisukyan/configuration/link-repository-to-container.md).
* エージェントには **読み取りアクセス** （パッケージがどのように使用されているかを分析するための、接続済みリポジトリへの）。
* Only **リポジトリおよびパッケージごとに 1 つの分析タスク**、またはコンテナごとに、同時に実行されます。タスクが保留中の間は重複実行が防止されます。
* アクションを次から変更しても、 **完全自動化** を **人による承認** Agent がすでに実行したアクションは元に戻りません。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://help.aikido.dev/docs/docs-ja/aikido-agent/cve-exploitability-analysis.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
.png?alt=media)
