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

#### 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.