> 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つありますか？」

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

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

到達可能性は適用されます *前に* 上位レベルのトリアージに：

* 〜を伴う検出結果は **到達可能なパスがない** ものは除外されるか、大幅に格下げされます。
* 〜を持つ検出結果は **明確で説明可能なパス** は保持され、後続の段階（例: リスクスコアリング、業務影響分析）に渡されます。
* 開発者は具体的なパス（コールスタックとデータフロー）を確認して、問題がどのように悪用可能になるのかを理解できます。

このパイプラインにより、ほとんどの「狼少年」的な検出結果は、深刻度の調整で単に隠されるのではなく、構造レベルで除外されます。

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

到達可能性分析は、チームがAikidoをどのように体験するかにいくつかの実用的な影響をもたらします：

1. **ノイズ削減**

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

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

   具体的なパス（「request handler → service → library function → vulnerable symbol」）を示すことで、セキュリティ上の検出結果を、認識しやすいプログラム動作として捉え直せます。これにより開発者の認知負荷が下がり、修正作業がより的確かつ効率的になります。
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.