> 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/hajimeni/reachability-analysis/introduction-to-reachability-analysis.md).

# 到達可能性分析の紹介

Aikidoの到達可能性分析は、脆弱性が実際にあなたのアプリケーションの文脈で悪用可能かどうかを特定することに重点を置いています。すべての脆弱な依存関係や危険なパターンを同じように重要だとフラグ付けするのではなく、Aikidoはコードベース内のモジュール、関数、データフローのグラフを構築します。そして、次の重要な問いを立てます： ***実際のアプリケーション動作から脆弱なコードへ至る実行経路はあるか？*** そのような経路が存在する場合にのみ、その検出結果は真にセキュリティ上重要であると見なされます。

### 概念概要

高いレベルでは、Aikidoは次のような抽象プログラムグラフを構築します。

* **ノード** 関数、メソッド、モジュール、ファイル、場合によってはより高次のコンポーネントを表します。
* **エッジ** 関数呼び出し、インポート、依存関係の取り込み、変数やパラメータ間のデータフローなどの関係を表します。

脆弱性はこのグラフ内の特定のノードに紐づけられます（たとえば、サードパーティライブラリ内の既知の脆弱な関数、またはSQL実行ポイントのようなシンクなど）。その後Aikidoは、 **エントリポイント** （HTTPハンドラ、CLIコマンド、バックグラウンドジョブなど）からこれらの脆弱なノードへ至る経路が存在するかどうかを計算します。現在のコードと設定のもとでそのような経路が存在しない場合、その脆弱性はそのプロジェクトのリビジョンでは到達不能として扱われます。

このように、到達可能性は、アラートの平坦な一覧を、実際のプログラム動作と証明可能に結びついた問題の構造化されたサブセットへと変換します。

### 到達可能性の種類

Aikidoはいくつかの補完的な到達可能性の概念を使用します。これらは同じ基盤を共有しますが、抽象化のレベルが異なります。

| 種類                | 範囲              | 主な問い                          | 典型的なシグナル                     |
| ----------------- | --------------- | ----------------------------- | ---------------------------- |
| **依存関係レベル**       | SCA / パッケージ依存関係 | 「プロジェクトは脆弱なシンボルを実際に呼び出すか？」    | インポート、シンボル参照、依存関係マニフェスト      |
| **関数レベル**         | SAST / タイント分析   | 「信頼できない入力が危険なシンクへ流れ込むことはあるか？」 | ソース、サニタイザ、シンク、プロシージャ間のフロー    |
| **コンテキスト依存（実行時）** | ビルドおよび実行環境      | 「このコードは実際の実行コンテキストで実行されるか？」   | 本番用と開発用の依存関係、デッドコード、ビルド専用ツール |

これらのカテゴリは相互排他的ではありません。典型的なAikidoの検出結果は、まず依存関係レベルの到達可能性で絞り込まれ、次に関数レベルの到達可能性で精査され、最後にプロジェクトのビルドおよびデプロイ方法の文脈で再解釈されることがあります。

### 到達可能性の仕組み

#### 1. グラフの構築

各プロジェクトについて、Aikidoは軽量で、言語およびフレームワークを認識するグラフを構築します。

* **構造的関係**：インポート、require、モジュール参照、継承、その他の静的関係。
* **呼び出し関係**：関数呼び出し、メソッド呼び出し、イベントハンドラ。
* **データフロー関係**：変数、パラメータ、戻り値を通じた、潜在的に汚染されたデータの伝播。

このグラフは意図的に近似的ですが、「経路があるか？」という問いに効率的に答えるために必要な特性を保つよう設計されています。

#### 2. 脆弱性のアンカリング

その後スキャナは、各生の検出結果を1つ以上の *アンカーポイント* にマッピングします：

* SCAでは、 **SCA**のアンカーは通常、CVEやアドバイザリに関連付けられた脆弱なシンボル（特定の関数、クラス、メソッド、またはモジュール）です。
* SCAでは、 **SASTでは、**のアンカーは関心のあるコード位置であり、多くの場合、 `exec`、SQLクエリ、ファイルシステムアクセス、または逆シリアライズのようなセキュリティシンクです。
* SCAでは、 **インフラストラクチャスキャンでは、**のアンカーポイントは、実行時の実行環境に関与するイメージ、パッケージ、または設定要素に対応する場合があります。

#### 3. 到達可能性クエリ

エントリポイントとアンカーノードの集合が与えられると、Aikidoは次のような到達可能性の問いを投げかけます：

> 「現在のビルドと設定のもとで、任意のエントリポイントからこのアンカーへ至る有効な実行経路は少なくとも1つあるか？」

アルゴリズム的には、これは言語の意味論と設定情報によって制約されたグラフ到達可能性（前向きまたは後ろ向きの走査）に帰着します。データフロー分析では、到達可能性関係は t**aint情報で拡張されます**：経路は、信頼できないデータがサニタイズによって完全に無害化されずに通過できる場合にのみ、セキュリティ上重要と見なされます。

#### 4. トリアージおよび優先順位付けとの統合

到達可能性は *前に* より高次のトリアージに適用されます：

* 次のような検出結果は **到達可能な経路がない** 場合、削除されるか、あるいは大幅に格下げされます。
* 次のような検出結果は **明確で説明可能な経路がある** 場合、保持され、後続の段階（例：リスクスコアリング、ビジネス影響分析）へ引き継がれます。
* 開発者は具体的な経路（コールスタックとデータフロー）を確認して、問題がどのように悪用可能になるのかを理解できます。

このパイプラインにより、多くの「狼が来たぞ」的な検出結果は、重大度の調整の裏に隠すのではなく、構造レベルでふるい落とされます。

### 検出結果とワークフローへの影響

到達可能性分析には、チームがAikidoをどのように体験するかに関して、いくつかの実務上の影響があります。

1. **ノイズの削減**

   従来のツールが生成する多くのアラートは、存在していても一度も呼び出されない依存関係や、実質的にデッドなコードパスに起因します。実行可能な経路が証明できない問題を排除することで、Aikidoは誤検知と重複チケットを大幅に減らします。
2. **より意味のある重大度**

   重大度はもはやCVEやルールの属性だけではありません。CVE *に加えて* 、そのプロジェクトでの利用状況の属性でもあります。ホットパスに深く組み込まれた中程度の重大度のライブラリ問題は、本番では一度も実行されない開発専用ツール内の高重大度問題よりも緊急性が高い場合があります。
3. **開発者に沿った説明**

   具体的な経路（「リクエストハンドラ → サービス → ライブラリ関数 → 脆弱なシンボル」）を示すことで、セキュリティ上の検出結果を認識しやすいプログラム動作として再定義できます。これにより開発者の認知コストが下がり、修正作業をより的確かつ効率的に行えます。
4. **時間の経過に対して安定したシグナル**

   コードや依存関係の変更に応じて到達可能性が再計算されるため、問題のバックログは実際のアーキテクチャの進化を追跡します。デッドな依存関係が削除されたりコードがリファクタリングされたりすると、以前は到達可能だった検出結果が到達不能へ移行することも、その逆もあります。これにより、リスクを動的かつアーキテクチャを考慮して把握できます。

### 制約と設計上の選択

Aikidoの到達可能性エンジンは、「保守的な **過小近似**」として構築されています。つまり、高い確信をもって判断できる場合にのみ、コードを到達不能と判定します。リフレクション、動的インポート、メタプログラミング、複雑なビルド手順などの動的言語機能は、コールグラフの一部を不明瞭または不可視にする可能性があります。このような曖昧なケースでは、Aikidoは慎重側に倒れます。つまり、潜在的に関連性のある問題を抑制するのではなく、そのまま保持するか、重大度を下げます。

このトレードオフは、2つの目標のバランスを取っています。

* 実行時に確実に到達不能な問題を除外して、ノイズを減らすこと。
* 到達可能性を確実に判断できないときに、誤った安心感を与えないこと。

### 要約

Aikidoの到達可能性分析は、アプリケーションの各部分がどのようにつながっているかをマッピングし、ソースコード、依存関係、インフラ全体にわたる関数呼び出し、データフロー、コンポーネント間の相互作用を追跡します。脆弱性は、アプリケーションのエントリポイントから脆弱な挙動へ至る明確で実行可能な経路がある場合にのみ、真のリスクとして扱われます。この推論をすべてのスキャナに組み込み、トリアージと緊密に統合することで、Aikidoは大量でノイズの多い生のアラートの流れを、攻撃者が実際にどのようにシステムを悪用できるかをより正確に反映した、より少数で高信頼な検出結果へと変換します。


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.aikido.dev/docs/docs-ja/hajimeni/reachability-analysis/introduction-to-reachability-analysis.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.