AIが生成したコードの時代におけるセキュリティテスト：QAエージェントが機能以上を確認すべき理由
Rui Li
AIコーディングツールは、興味深い新たなリスクをもたらしています。正しく動作するが、デフォルトで安全でないコードです。フォームハンドラーを生成するLLMはSQLインジェクションを考慮しません。認証フローを補完するAIオートコンプリートは、権限昇格のパスを考慮しません。コードは機能テストに合格します。しかし、3週間後にセキュリティレビューで不合格となります。
これは仮定の話ではありません。AIが生成したコードが出荷物の大きな割合を占めるようになるにつれ、「動く」と「安全」のギャップは広がっていきます。セキュリティテストは機能テストと同様に左シフトする必要があり、AIテストエージェントはそれを実現するための適切なメカニズムです。
機能テストがセキュリティ上の問題を検出できない理由
機能テストは、アプリケーションが想定通りに動作することを検証します。ユーザーがフォームを送信する。データが保存される。確認画面が表示される。合格。
セキュリティテストは、アプリケーションがすべきでないことを行っていないことを検証します。未認証ユーザーが保護されたリソースをリクエストする。アプリケーションはそのリソースではなく403を返す。スクリプトタグを含む入力は保存前にサニタイズされる。セッショントークンはログアウト後に無効化される。
これらは異なる検証の問いであり、後者のカテゴリーはほとんどのコードベースで体系的にテストが不足しています。エンジニアがセキュリティを軽視しているからではなく、セキュリティテストケースの作成には時間がかかり、専門的な知識が必要であり、スプリントのベロシティが求められる状況では優先度が下がりがちだからです。
AIが生成したコードはより速く出荷されるため、この問題を加速させます。より広い表面積のコードが、より短時間で出荷され、セキュリティレビューがボトルネックとなっています。
セキュリティを考慮したAIテストエージェントが確認する内容
TestSpriteのようなテストエージェントは、機能カバレッジと並行してセキュリティに特化したテストフローを実行するように構成できます。これらはペネトレーションテストではなく、機能テストが動作の不変条件を検証するのと同じ方法で、セキュリティの不変条件を検証するアプリケーション層のチェックです。
認証と認可の境界が最も重要です。すべての保護されたルートに対して、未認証リクエスト、期限切れトークンによるリクエスト、権限が不十分なユーザーからのリクエストに対して正しいレスポンスを返すことを確認する自動テストが必要です。これらのテストは自然言語で簡潔に記述でき、すべてのデプロイ時に実行されるべきです。「管理者権限を持たないユーザーが管理者ダッシュボードにアクセスしようとした場合、403が返されること。」
入力バリデーションが第二の優先事項です。AIが生成したフォームハンドラーは、入力を過度に信頼しがちです。テストエージェントは、スクリプトタグ、SQLフラグメント、過大なペイロードといった既知の悪意ある入力パターンを送信し、アプリケーションが適切に処理することを検証できます。これは包括的なセキュリティ監査ではありませんが、最も一般的な入力処理の失敗パターンが本番環境に到達する前に検出できます。
セッション管理は独自のテストカバレッジに値します。ログアウトはセッションを無効化すべきであり、トークンのリフレッシュは並行リクエスト下で正しく動作すべきであり、セッション状態は認証境界をまたいで予期しない形で持続すべきではありません。
CIへのセキュリティチェックの組み込み
セキュリティを考慮したテストを実行する適切なタイミングは、機能テストを実行する適切なタイミングと同じです。つまり、すべてのプルリクエスト時、コードのマージ前です。
セキュリティを早期に取り込む（シフトレフト）とは、認可チェックと入力バリデーションのテストを、リグレッションテストを実行するのと同じCIジョブに追加することを意味します。TestSpriteはこのワークフローをネイティブにサポートしており、セキュリティ不変条件テストは機能テストと同じ方法で定義され、平易な英語で記述され、同じ環境に対して実行されます。
このアプローチが定期的なセキュリティ監査やペネトレーションテストより優れている点は、より網羅的であることではありません——そうではありません。優れている点はサイクルです。コードが変更されるたびに実行されるセキュリティチェックは、コンテキストが新鮮で修正コストが低い段階で、リグレッションを即座に検出します。四半期ごとのセキュリティレビューは、同じ問題を導入から数カ月後に発見しますが、その時点での修正には過去の調査が必要になります。
AIが生成したコード特有の問題
開発者がCursor、Copilot、またはその他のAIコーディングアシスタントを使用する場合、自分が完全に書いたわけではなく、完全に理解していない可能性があるコードを受け入れています。それは批判ではありません——それが価値提案です。しかし、検証のギャップが生まれます。
コードを生成したのと同じAIが書いた機能テストは、AIが最適化したハッピーパスをテストする傾向があります。セキュリティのエッジケースはハッピーパスには含まれていません。「ログインフローが機能する」ことを確認するテストスイートは、「ログインフローがセッショントークンをURLパラメータに露出しない」ことや「パスワードリセットエンドポイントが有効なメールアドレスの列挙に使用できない」ことを確認するわけではありません。
TestSpriteのエージェント型アプローチがここで役立つのは、テストが実装から生成されるのではなく、人間が不変条件——決して真であってはならないこと——という形で定義するからです。エージェントは、コードがたまたま示す動作だけでなく、契約を検証します。
小さく始めて拡張する
初日から包括的なセキュリティテストスイートは必要ありません。アプリケーション内で最も重要な3つの認証境界から始め、それぞれにシンプルな不変条件テストを記述しましょう。
未認証ユーザーが保護されたデータにアクセスできないことを確認する。ユーザーがリクエスト内のIDを変更することで他のユーザーのデータにアクセスできないことを確認する。管理者専用の操作が非管理者ユーザーに対して適切に失敗することを確認する。
これら6つのテストをすべてのPRで実行することで、AIが生成したコードがもたらすセキュリティリグレッションのかなりの割合を検出できます。そこからさらに構築していきましょう。