到達可能性分析の紹介

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

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

概念的な概要

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

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

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

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

到達可能性の種類

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

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

到達可能性の仕組み

1. グラフの構築

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

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

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

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

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

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

3. 到達可能性クエリ

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

「現在のビルドと設定の下で、任意のエントリーポイントからこのアンカーまで少なくとも1つ有効な実行パスは存在しますか？」

アルゴリズム的には、これは言語の意味論と構成知識によって制約されたグラフ到達可能性（前方または後方トラバーサル）に還元されます。データフロー解析では、到達可能性関係は taint 情報: パスは、信頼できないデータがサニタイズによって完全に無害化されずにそこを通過できる場合にのみ、セキュリティ上関連があると見なされます。

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

到達可能性は 前に 上位レベルのトリアージに

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

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

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

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

1. ノイズ削減

   従来のツールが生成する多くのアラートは、存在していても実際には呼び出されない依存関係や、実質的に死んでいるコードパスに由来します。実行可能なパスが証明できない問題を取り除くことで、Aikido は誤検知と重複チケットを大幅に削減します。

2. より意味のある深刻度

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

3. 開発者に寄り添った説明

   具体的なパス（request handler → service → library function → vulnerable symbol）を示すことで、セキュリティ上の検出結果が認識しやすいプログラム動作として再定義されます。これにより開発者の認知負荷が下がり、修正作業をより的確かつ効率的に行えるようになります。

4. 時系列で安定したシグナル

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

制限事項と設計上の選択

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

このトレードオフは、2つの目標のバランスを取ります：

• ランタイムで確実に到達不可能な問題を除外してノイズを削減すること。
• 到達可能性を確実に判断できない場合に、誤った安心感を防ぐこと。

要約

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