到達可能性分析の紹介

Aikido がどの脆弱性を悪用可能か特定するのにどう役立つかを学びます。

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

概念的な概要

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

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

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

このように、到達可能性は、単なる警告の一覧を、実際のプログラム動作に確実に結び付いている問題の構造化されたサブセットへと変換します。

到達可能性の種類

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

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

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

到達可能性の仕組み

1. グラフの構築

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

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

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

2. 脆弱性のアンカー付け

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

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

3. 到達可能性クエリ

エントリポイントとアンカーノードのセットが与えられると、Aikido は次の形式の到達可能性の問いを投げかけます。

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

アルゴリズム的には、これは言語の意味論と設定情報によって制約されたグラフ到達可能性（順方向または逆方向の走査）に還元されます。データフロー解析では、到達可能性関係は t によって拡張されます。タイント情報：信頼できないデータがサニタイズによって完全に無害化されることなく経路を通過できる場合にのみ、その経路はセキュリティ上意味があるものと見なされます。

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

到達可能性は 前に 高レベルのトリアージに適用されます。

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

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

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

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

1. ノイズ削減

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

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

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

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

制約と設計上の選択

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

このトレードオフは、2 つの目標のバランスを取るものです。

• 実行時に明らかに到達不能な問題を除外することでノイズを減らすこと。
• 到達可能性を確実に判定できないときに、誤った安心感を防ぐこと。

要約

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