SASTの自動トリアージ
SAST AutoTriage は、 Aikido Agent 静的解析のノイズを減らして、実際のセキュリティ脅威である問題に集中できるようにする仕組みです。まず悪用可能性を排除しようとし、次に（必要な場合のみ）残った指摘を (1) 悪用可能性、(2) 悪用された場合の深刻度 に基づいて順位付けします。主に SAST の指摘に対して動作し、ローカル IDE、PR チェック、定期的な再スキャンなど、使い慣れたワークフローに組み込まれます。
AutoTriage とは何か（そして何ではないか）
AutoTriage 自体はスキャナーではありません。スキャンの後段にあり、 悪用可能性 および severity をコードとその文脈に基づいて判断します。
SAST の大半の問題について、Aikido は Aikido 定義のルールに基づいてトリアージを行います。より複雑なケースでは、Aikido は推論モデルを使って、より微妙な制御フローとデータフローを解釈します。これには、呼び出しツリーを計算し、脆弱性のシンクに渡された変数を参照する呼び出し先関数を取り込むことで、関連するコードスニペットを構築することが含まれます。
Aikido の内部評価では、このアプローチは、推論を使わない手法と比べて、そうした複雑なケースにおける誤検知をおよそ2倍多く検出します。
AutoTriage の仕組み
トリアージ前の誤検知フィルタリング
AutoTriage が LLM を使ってコードを確認する前に、Aikido の 到達可能性 エンジンは、脆弱なコードパスがアプリケーション内で実際に到達可能かどうかを確認することで、誤検知を除外します。これには次のようなものが含まれます:
影響を受ける関数を実際に呼び出しているかを確認する
脆弱な依存関係がツール内でのみ使われているのか、本番環境でも使われているのかを追跡する
ソースとシンクの間にサニタイズがあるかを確認する
古い、または未使用のコードパスを削除する
これらの手順だけで、従来の多くのスキャナーと比べて大幅にアラートを抑制できます。
信頼できない入力から危険なシンクへの経路がない、あるいはその使用が本番フローの外にあると到達可能性解析で判断されたため、多くの潜在的な問題が自動的に無視済みとしてマークされることに、おそらく気づくでしょう。
悪用可能性を排除できない場合、AutoTriage は優先順位付けに進みます。
優先度スコアリング
問題が依然として悪用可能である可能性がある場合、AutoTriage は発生可能性と影響を評価して優先度を設定します。Aikido の深刻度スコア（0〜100）を起点に、前段の手順で収集したコードの文脈を使って上下に調整します。
例:
SQL インジェクションのレポートは、安全に ダウングレード されることがあります。これは、入力変数が、すでに上流で検証済みのデータベースのような信頼できるソースに由来する場合です
NoSQL インジェクションのリスクがあるログインエンドポイントは アップグレード され、「非常に高い修正優先度」となることがあります。攻撃が容易で、下の図のように認証に直接影響するためです
もし真の陽性であれば、AutoFix は
トリアージされた真の陽性について、Aikido は AutoFix を通じて推奨パッチを生成し、レビュー用のプルリクエストを開くことができます。AutoFix は報告された脆弱性のみに焦点を当て、GitHub、GitLab、Bitbucket、Azure DevOps の PR チェックに加え、ローカル IDE でも利用できます。
AutoTriage が考慮するシグナル
AutoTriage は 文脈を強く必要とします ように設計されています。実際には、次のようなものを考慮します:
ユーザー入力が機密シンクに到達可能かどうか、およびサニタイズ／検証の有無と有効性
入力が信頼できるストアに由来するかどうか、また脆弱なコードが本番環境ではなくビルド時やテスト時に使われているかどうか
データの機密性などのビジネス影響シグナル
複雑なルールでは、推論モデルが、たとえば OS 固有の区切り文字やパス解決の意味論といったエッジケースを評価します
Aikidoに質問
クリック Aikidoに質問 を 推奨 パネルでチャットする Aikido Agent 脆弱性について、たとえばなぜフラグが立ったのか、脆弱なコードにどう到達するのか、あるいは知りたいことなら何でも。
最終更新
役に立ちましたか？