疑わしい脆弱性のテストには、リクエストを送ってレスポンスを確認する以上のことが必要です。アプリケーションの準備が整っている必要があり、リクエストは調査対象のコードに到達しなければなりません。
あるユーザーが別のユーザーのドキュメントを取得できてしまうように見えるエンドポイントを考えてみてください。これをテストするには、認証済みの 2 人のユーザー、そのどちらかが所有するドキュメント、そして稼働中のアプリケーションが必要です。エンドポイントに到達する前にリクエストが失敗した場合、アプリケーションがそのドキュメントへのアクセスを適切に制限しているかどうかについては、ほとんど何もわかりません。
私たちは、開発者が Deep Scan の検出結果をテストし、何が起きたのかを精査できるように、CodeRabbit Secure にランタイム検証を構築しました。
私たちが作ろうとしたもの
私たちは、開発者が提案されたテストを実行する前に、その内容を理解できるようにしたいと考えました。開発者が知る必要があったのは次の点です。
- どのようなセットアップが必要か
- どの手順に従うか
- どのような観察結果が検出結果を裏付け、あるいは覆すか
私たちは、これらの詳細をひとつにまとめる再現ガイド（Reproducer Guide）を中心にワークフローを構築しました。
開発者は自分のテスト環境でガイドに従うこともできますし、Runtime Analysis を使って、準備された CodeRabbit のコーディング環境で実行することもできます。Runtime Analysis の結果には、裏付けとなる証拠に加えて、アプリケーションの準備が整っていたか、意図したコードパスが通過されたかを示すインジケーターが含まれます。
検出結果を再現ガイドに変える
Deep Scan の検出結果は、疑わしい問題とその場所についてのコンテキストを提供します。検出結果が報告された後にコードが変わっている可能性があるため、CodeRabbit はガイドを生成する前に、その問題がまだ存在するかどうかを再確認します。問題がもはや存在しない場合、または再確認が不確定な場合、ガイドの生成は停止します。
依然として存在する検出結果については、ガイドが疑わしい挙動を、前提条件、手順、期待される観察結果と結びつけます。Runtime Analysis でガイドを実行すると、公開されたガイドに固定されたリビジョンが使われます。Run をクリックしても、検出結果が再確認されたり、最新のソースが自動的にテストされたりすることはありません。
ドキュメントのエンドポイントの例では、ガイドは、どのユーザーがドキュメントを所有しているか、そしてもう一方のユーザーがどのようにそれを取得しようとするかを明確にする必要があります。期待される結果は、別のユーザーのドキュメントへのアクセスと、エンドポイントに到達する前に失敗するリクエストとを区別できるものでなければなりません。
ガイドは、開発者が自分の環境と照らし合わせて確認できるように、その前提を明示する必要があります。必要な値やセットアップの詳細を確定できない場合は、何が不足しているか、そしてテストの前に開発者が何を用意しなければならないかを示すべきです。
チームが自動検証を有効にしていない限り、ガイドを生成してもテストは開始されません。開発者はまずガイドを確認し、その後、どこでどのように実行するかを決められます。
実験を動かす
Runtime Analysis でガイドを実行するには、アプリケーションの実行に必要な依存関係、設定、起動手順を備えた、準備済みの CodeRabbit コーディング環境がリポジトリに必要です。
チームは自動検証を有効にすることもできます。これは、各 Deep Scan の後に、選択した重大度で新たに検出された検出結果に対してガイドを生成し、リポジトリの準備済みデフォルト環境でそれらを実行します。
アプリケーションのプロセスが起動したからといって、テストの準備が整ったとは言えません。必要な依存関係が利用できないままサービスが待ち受けていることもあれば、認証の問題によってリクエストが意図したエンドポイントに到達できないこともあります。Runtime Analysis は、結果を評価する際にこうした条件を考慮に入れる必要があります。
結果には、評価と裏付けとなる証拠に加えて、Application ready（アプリケーション準備完了）と Target exercised（ターゲット通過）のインジケーターが含まれます。これらは、アプリケーションの準備が整っていたこと、そして該当するコードパスが通過されたことを CodeRabbit が確認できたかどうかを示します。
専用のテスト環境を使い、本番の認証情報は避けてください。エージェントは、選択した環境に設定された変数を読み取ることができ、これにはシークレットも含まれます。出力は証拠として保持される場合があるため、テストスクリプトやコマンドでそれらの値を出力しないようにしてください。
結果を読み解く
Runtime Analysis は、3 つの検証状態のいずれかを報告します。
- 再現（Reproduced）: テストされた条件のもとで、検出結果を裏付ける証拠が実行によって得られた。
- 未再現（Not reproduced）: その条件のもとでは実行で検出結果を再現できなかった。他の入力や設定では異なる挙動になる可能性がある。
- 不確定（Inconclusive）: 実行では裏付けのある結論を出せなかった。結果にはその理由と制限事項が説明される。
各結果は、テストされたコードのリビジョンと環境に対して適用されます。再現に成功したとしても、デプロイ済みのすべてのバージョンがどう振る舞うかが確定するわけではありません。
ドキュメントへのアクセスの例では、403 が意味を持つのは、リクエストが所有権の確認まで到達した場合だけです。セッションがないことによる拒否では、その保護機能をテストしたことにはなりません。
同様に、「未再現」は「安全」よりも狭い意味です。セットアップの問題によって意味のあるテストができなかった場合、結果は脆弱性が存在しないことを示唆するのではなく、不確定のままであるべきです。
ワークフローの背後にある判断
このワークフローは、開発者が結果に至った過程を精査できるように、テスト計画、実行、評価を分離しています。
開発者が自分でガイドを生成する場合、ガイドを別に公開することで、実行前に提案されたテストを精査する機会を得られます。その前提を確認し、自分の環境で実行することができます。また、期待される結果と観察された挙動の区別も明確になります。
ランタイムの証拠が変えるもの
ランタイムテストが役に立つのは、チームがそれが実際に何をテストしたのかを確定できる場合だけです。だからこそ、ガイド、実行の詳細、裏付けとなる証拠は、結論とともに参照できるようになっています。
ランタイム検証をセットアップして、自分の環境で、または Runtime Analysis を使って、Deep Scan の検出結果をテストしてみてください。
