> 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はコードベース内のモジュール、関数、データフローのグラフを構築します。そして、次の重要な問いを投げかけます: ***実際のアプリケーションの動作から脆弱なコードへ至る実行パスはあるか？*** そのようなパスが存在する場合にのみ、その検出結果は本当にセキュリティ上重要であると見なされます。

### 概念の概要

高いレベルでは、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.