AIセキュリティテストでSAST、DAST、ペネトレーションテストを置き換えられるか？

エージェントをどこまで信頼できるか。それが実用的な問いです。レビュー範囲を広げ、複数のファイルにまたがる手がかりをつなぎ、狙いを定めたテストを作り、読みにくいスキャナーのログを開発者に伝わる修正案へ変えることなら、私はエージェントを信頼します。一方で、ルート名だけから会社の認可ルールを推測したり、すべてのテナント境界が守られていると証明したり、人間がルールを示していないのに奇妙な金融フローを悪用と判断したりすることは任せません。エージェントは多層的なテストプログラムの中で能動的なレビュアーとして扱い、プログラムそのものにはしないでください。

エージェントレビューは新しいテスト種別ではなく、解釈の仕組み

AIエージェントは証拠の集め方と理解の仕方を変えますが、新しい種類の証拠を生み出すわけではありません。アプリケーションを実行せずにソースを読むなら、柔軟な静的レビューを行っています。実行中の対象へリクエストを送るなら、動的テストです。目的を探り、方針を変え、予想外の挙動を追うならペネトレーションテスターに似ています。しかし、似ているからといって、テスターが持つ権限や業務上の文脈まで得られるわけではありません。

ベンダーがエージェントで「スキャナーを置き換えられる」と説明するとき、この違いが重要になります。システムが実際に観測できるものを確認してください。完全なリポジトリ、生成コード、ビルドフラグ、インフラポリシー、依存関係のロックファイルを受け取っていますか。複数のユーザーとして認証し、各リクエスト後にデータベースの状態を確認できますか。インターフェースに存在しないだけでなく、ポリシーで禁止されている操作を理解していますか。入力が足りなければ、洗練された説明でも補えません。

エージェントが本当に得意なのは、弱いシグナルをつなぐことです。従来のルールは、リクエストパラメータがクエリビルダーに届いていると警告するかもしれません。エージェントならラッパーを調べ、ある呼び出し箇所だけテナント条件を省略していることに気づき、テスト用リクエストを作り、その経路では安全なはずのヘルパーが危険な理由を説明できます。値が実際のパラメータ化APIを通っている場合には、候補を却下することもできます。これはトリアージの改善であり、静的解析や動的解析が不要になったという証明ではありません。

レビューと検証の間には明確な境界があります。レビューが問うのは「見えている資料から判断して、この実装は危険そうか」です。検証が問うのは「指定された条件下で、このアクターは禁じられた結果を引き起こせるか」です。AIはどちらにも役立ちますが、セキュリティゲートではどの主張を記録しているかを明確にする必要があります。表現力のあるレビュー上の指摘を検証済みのエクスプロイトへ格上げしたり、1回の失敗したエクスプロイト試行を安全性の証明と見なしたりすると、チームは危険にさらされます。

モデルの挙動については、能力と再現性も分けて考えます。ある実行では微妙な経路を見つけても、モデル、プロンプト、検索インデックス、ツールポリシーが変わると見逃すかもしれません。結果が重要な場合は、プロンプト、ツール権限、取得したファイル、生成リクエスト、モデル識別子を保存します。そのうえで、モデルが自分のアイデアを再発見しなくても合否を判定できるテストへ、確認済みの発見を変換します。

SASTが再現性のあるソース網羅性を担う理由

SASTは、大規模なコードベースのすべての変更へ安定したチェックを適用する最も低コストな方法です。ソースとシンクを列挙し、禁止APIを検出し、データフローを調べ、解析した正確なリビジョンを報告できます。決定論的なルールなら翌日も同じ結果になるため、リリースゲートが通過または失敗する監査可能な理由を必要とするときに有効です。

エージェントは、ルールエンジンに欠けがちな文脈を補います。プロジェクト固有のラッパーを追い、コメントを鵜呑みにせず、隣接するハンドラーと比較し、新しいパターン向けのクエリを提案できます。9つのエンドポイントがauthorizeProject()を呼び出しているのに、10番目だけがレコードを直接読み込んでいる、といった疑わしい抜けも見つけられます。生成コードや不慣れなフレームワークによって標準ルールセットが機能しない場合にも役立ちます。

ただし、エージェントのソース網羅性は通常、証明が難しくなります。コンテキストウィンドウ、検索順位、無視されたファイル、生成された成果物、ツールのタイムアウトによって、読まれないコードが生まれます。「このリポジトリをインジェクションについてレビューして」と頼んでも、すべてのシンクに到達したことにはなりません。SASTレポートなら、少なくともどのファイル、ルール、リビジョンを解析したかを示せます。エージェントが必須ゲートを担うには、それに相当する網羅性の台帳が必要です。

NIST SP 800-218は、ここで妥当な推奨を示しています。早い段階でコード解析を使い、セキュリティ機能と緩和策を手動で検証するというものです。価値は組み合わせにあります。安定したルールは既知の欠陥パターンをすべてのコミットで検出し、エージェントは例外を調べ、絞り込んだ回帰テストを書き、同じパターンが繰り返されたときにルールを調整します。エージェントがいくつかの巧妙なバグを見つけたからといってSASTを外すと、測定可能な広さを印象的な逸話と交換することになります。

SASTは、実行中のテストが決して到達しないコードも見ます。エラーパス、機能フラグ、マイグレーション用ユーティリティ、休眠中の管理者エンドポイント、プラットフォーム固有の分岐などです。実際にデプロイされた環境でその経路が有効かどうかは分かりません。その不確実性はランタイムの証拠を追加する理由であり、静的な網羅性を捨てる理由ではありません。

ブロックするSASTルールに何を入れるかにも限界があります。禁止された暗号プリミティブを正確に検出するパターンなら、すぐにブロックできます。認可チェックが「十分に近いか」を広いヒューリスティックで判断するルールは、精度を測るまで通常はレビュータスクにします。エージェントは、正しい例、反例、そのコードベースでよく使われるラッパー関数を集め、ヒューリスティックをルールへ昇格させる手助けができます。これにより、ゲートを厳格に保ちながら、開発者が警告を無視する状態を防げます。

生成された修正も、検出結果と同じように精査が必要です。モデルは、間違った層に検証を追加してデータフローの警告を消したり、例外を捕捉してフェイルオープンにしたり、危険な呼び出しを置き換える際に挙動を変えたりする可能性があります。元の証明をパッチに対して実行し、通常の機能テストも行い、信頼が確立される場所に追加された制御をレビューします。再スキャンで問題が消えたことが証明されるのは、元のルールに一致しなくなったことだけです。

DASTがリポジトリでは分からない挙動を証明する

DASTは実際に動いているアプリケーションを観測します。プロキシルール、ヘッダー、シリアライズ、認証ミドルウェア、フレームワークのデフォルト、デプロイのミスも含まれます。ソースレビューでは、エンドポイントが保護されているように見えるとしか言えません。動的テストなら、ゲートウェイがパスを書き換えたために本番ルートがミドルウェアを回避していることを示せます。

ここでエージェントを使うと、動的テストを大幅にきめ細かくできます。API仕様、テスト用ID、許可されたスコープ、使い捨て環境を与えれば、汎用的なペイロードをばらまくのではなく、リクエストの連続を組み立てられます。あるレスポンスからリソース識別子を次のリクエストへ渡し、セッションを更新し、2つのロールを比較し、書き込みによって後続の読み取りが変わったか確認できます。従来のDASTは、こうした状態を持つフローに苦戦しがちです。

それでもエージェントには厳格な運用制限が必要です。クローラーは、メール送信、配送作成、有料連携の呼び出しが安全かどうかを知りません。テスト環境が実際のサービスへ接続していることもあります。許可されたホスト、アカウント、リクエスト速度、破壊的操作、停止条件をモデルのプロンプトの外で定義し、ランナーで強制します。「危険な操作を避ける」と書くだけでは制御になりません。

セキュリティヘッダー、公開ファイル、反射入力、一般的なインジェクションプローブ、TLS設定など、よく理解されたチェックについては、従来の動的テストによる基準も残してください。こうしたチェックは安価で、リリース間の比較がしやすく、傾向も追いやすいものです。エージェントの予算は、認証が必要な経路や連鎖した挙動に使います。両方のシステムが同じ単純なプローブをカバーするなら、証拠が明確でばらつきが少ない方を残します。

DASTは、到達できた範囲だけを報告するため、網羅性について誤った安心感を与えることもあります。結果とともに、ルートの網羅範囲、使用したID、機能フラグ、シードデータを記録します。承認、招待、請求、データインポートの後にしか危険な分岐が現れないアプリケーションを、ほとんど空のアカウントに対してスキャンしても、証明できることはほとんどありません。

認証のセットアップには、独立した証拠が必要です。各セッションをどう取得したか、テスト環境でどの二要素認証やデバイスチェックを回避したか、本番トークンと同じクレームと有効期間を持つかを記録します。手作りの管理者トークンなら有用な範囲を開けますが、テストすべきセッション遷移や権限遷移を飛ばしてしまいます。こうした近道はレポートに明記してください。

動的な再テストは、新しい自律クロールではなく、保存したリクエストの連続から始めます。修正済みビルドに対して確認済みの証明を再実行し、禁じられた効果が止まったことを確認してから、隣接する入力を変えて狭いフィルターを検出します。その後でエージェントに探索させます。この順番なら、「修正が既知のエクスプロイトをブロックする」という主張と、「欠陥クラスが除去された」という広い主張を分けられます。

認可テストにはIDと禁止される結果が必要

認可は「エンドポイントが一度403を返したか」ではありません。役に立つテストでは、誰が操作し、どのオブジェクトを対象にし、どの操作を試み、どの結果が不可能なままでなければならないかを定義します。組み合わせの生成はエージェントに任せられますが、ポリシーはプロダクト責任者とセキュリティレビュアーが示す必要があります。

OWASP ASVSは、アプリケーションが信頼できるサービス層でアクセス制御を強制し、機能とデータに最小権限を適用するよう求めています。サービス層の要件には同意しますが、チームは狭い範囲で検証しがちです。見えているHTTPハンドラーだけをテストし、バックグラウンドジョブ、エクスポート、検索インデックス、WebSocketサブスクリプション、オブジェクトストレージの直接URLを忘れてしまいます。オブジェクトへ至るすべての経路で、同じポリシーが守られなければなりません。

「IDORをテストする」という曖昧な指示より、小さな実行可能なマトリクスの方が多くを明らかにします。次のシェル断片は、使い捨て環境、2つのベアラートークン、ユーザーAが所有するドキュメントを前提にしています。ステータスと、BのレスポンスにA専用の秘密の目印が含まれていないことを確認します。

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

期待される出力はなく、終了ステータスは0です。CIが失敗した場合は、ステータス、サニタイズ済みのボディ、操作したID、対象の所有者、ルート、ビルドリビジョンを保存します。実際の認証情報や関係のないレスポンスデータは保存しないでください。

次に、1度に1つの要素だけを変えます。読み取りと更新、直接IDと検索、アクティブなメンバーシップと失効したメンバーシップ、通常ルートとエクスポート、ユーザートークンとサービストークンを比較します。エージェントはこうしたケースを効率よく作成して実行できます。人間は、そのマトリクスがポリシーに合っているか、404、403、空の結果、マスキングされたオブジェクトのどれが意図した結果なのかを確認します。そうしなければ、エージェントは業務上は侵害と見なされる挙動を成功として扱うかもしれません。

否定的な証拠には注意が必要です。更新を拒否しても、レスポンス時間、エラーテキスト、バージョンカウンターからオブジェクトの存在が漏れることがあります。読み取りを拒否しても、閲覧数が増えたり、秘密のメタデータを含む監査記録が書き込まれたりすることがあります。許可される副作用を決め、それをアサートしてください。レスポンスだけを調べるセキュリティテストでは、有用な列挙経路や危険な書き込みを見逃す可能性があります。

セッション中のポリシー変更もテストします。ユーザーをプロジェクトから外し、所有権を移し、アカウントを無効にし、サービスロールを狭めたうえで、古いトークンや開いた接続を再利用します。想定される失効時間はプロダクトポリシーから決めます。「いずれ」はテストできません。即時失効が不要な場合もありますが、チームは上限を定め、APIリクエスト、キュー処理、ダウンロード、ライブサブスクリプションで確認しなければなりません。

テナント分離は分かりやすいリクエスト経路以外でも破られる

テナント分離には、ストレージ、キャッシュ、キュー、検索、ファイル、分析、管理の境界でテストが必要です。よくある失敗は、メインの一覧エンドポイントにtenant_idがないことではありません。データをコピー、インデックス化、キャッシュ、エクスポートする二次経路がテナントコンテキストを渡していないことです。

意図的に似たレコードと、テナントごとに明確な目印を1つずつ持つ2つのテナントから始めます。別々のユーザー、別々のセッション、可能なら別々のサービス認証情報を使います。作成、読み取り、更新、削除、一覧、検索、エクスポート、インポート、添付ファイルへのアクセス、通知配信、バックグラウンド処理を実行します。各操作の後で、ユーザーに見えるレスポンスと永続状態を調べます。拒否されたリクエストがテナントをまたぐジョブをキューに入れたままなら、それは失敗です。

エージェントが役立つのは、層をまたいで識別子を追跡し、人間が面倒に感じる組み合わせを生成できるからです。キャッシュキーがdocument_idだけを使い、データベースクエリはtenant_idとdocument_idの両方を使っていることにも気づけます。エクスポートワーカーと対話型ハンドラーを比較し、なぜ片方だけが行レベルのコンテキストを設定するのかを問うこともできます。これは価値の高いレビューです。

一方で、エージェントも危険な思い込みをします。名前が境界を示すと思い込むことです。getTenantDocumentという関数が、リクエストから任意のテナント引数を受け取るかもしれません。データベースポリシーがマイグレーションにはあっても、新しいテーブルには適用されていないかもしれません。検索フィルターが結果のカウント後に適用され、別テナントの活動を漏らすこともあります。検証では強制される条件を調べ、テナントをまたぐ読み取りと書き込みを試みます。

エージェントに、テスト対象と同じコードを読んで独自の判定基準を作らせないでください。期待されるアクセスは、プロダクト要件とともに管理する独立したポリシー表から導きます。実装とテストが同じルールを誤解すれば、データを公開しながら完全に一致してしまいます。

非同期経路には遅延アサーションが必要です。テナントAとしてエクスポート、通知、サムネイル、インデックス作成のジョブを起動し、ワーカーが動く前に所有権やメンバーシップを変更して、結果がどこに置かれるかを調べます。ワーカーがリクエスト時点の権限を使うのか、実行時点で現在の権限を再確認するのかを決めます。特定の操作ではどちらも正しい選択になり得ますが、意図しない混在は漏えいと壊れた監査証跡を生みます。

管理ツールには、別のIDとログ記録のアサーションを用意します。サポートアクセスは設計上テナント境界を越えることがあるため、「別テナントには必ず失敗する」という単純なルールは誤りです。オペレーターが必要なロールとケースコンテキストを持つこと、顧客向けポリシーに従うこと、アクセスが期限切れになること、監査イベントが顧客になりすますのではなくオペレーターを識別することをテストします。

ビジネスロジックには悪用のストーリーが必要

ビジネスロジックのテストは、禁止されるストーリーから始まります。ユーザーが正当な操作を不正な順序や組み合わせで行うことで、本来受け取れない価値、権限、状態を得るというストーリーです。一般的な脆弱性ラベルだけでは不十分です。招待、承認、クォータ、返金、クレジット、所有権移転、キャンセルがどう連動すべきかを、テスターが理解する必要があります。

OWASP Web Security Testing Guideは、ワークフロー手順のスキップ、同じ機能の繰り返し、偽造リクエスト、タイミングの変更、正当な機能の悪用を試すよう求めています。古いビジネスロジックの導入部分では、スキャナーの自動化だけではアプリケーション固有の知識や創造性を補えないと率直に述べています。最新のエージェントは自動化を改善しますが、知識の不足をなくすわけではありません。クーポンが再利用できる可能性を提案することはできますが、それがキャンペーンなのか不正なのかは、誰かがルールを示すまで判断できません。

許可された遷移と不変条件を含む状態モデルをエージェントに与えます。承認フローの不変条件なら、「所有権が移転した後も含め、申請者は自分の支払いを承認できない」といったものです。そして、ロール変更、重複リクエスト、キャンセル、再試行、同時実行、古いセッションを含むシーケンスを生成させます。エージェントなら、人間が手動で実行するよりはるかに多くのシーケンスを探索できます。

難しいケースでは、HTTPレスポンスの外側に結果が現れます。同時に送られた2つの引き換えリクエストが両方とも成功を返しても、後の照合で片方が取り消されるかもしれません。キャンセルによって画面上のジョブは止まっても、署名付きダウンロードの権限が取り消されないかもしれません。招待者がアクセスを失った後に招待を受け入れると、孤立したメンバーシップが作られるかもしれません。テストではステータスコードだけでなく、台帳、キュー、オブジェクト権限、後続の状態を観測します。

人間のテスターが必要なのは、示されたモデルそのものに疑問を投げかけるからです。サポート担当者が無害に見える機能を組み合わせられないか、オペレーターが自分の監査証跡に影響を与えられないか、「期限切れ」のオブジェクトが別の経路ではまだ使えないかを問いかけます。エージェントは与えられた目標とツールの範囲内で動きます。人間なら、目標から危険な業務部分が抜けていることに気づけます。

依存関係のリスクは脆弱なバージョンだけではない

依存関係のテストには4つの問いがあります。どのパッケージが存在するか、既知の脆弱性が報告されたバージョンか、ビルドが意図した成果物を取得したか、アプリケーションが実際に脆弱な挙動を公開しているかです。ソフトウェアコンポジション解析（SCA）とプロヴェナンス管理は、会話型レビューだけの場合よりも、最初の3つに確実に答えます。

インベントリができた後なら、エージェントが役立ちます。依存関係の呼び出し方を調べ、影響を受ける関数に到達できるかを判断し、補完的な対策を見つけ、回帰テスト付きのアップグレードパッチを作成できます。脆弱性識別子がない危険なパッケージ挙動も指摘できます。たとえば、インストールスクリプトがネットワークアクセスを得ることや、新しいライブラリが環境変数から秘密情報を受け取ることです。

現在の脆弱性情報をモデルに思い出させようとしないでください。タイムスタンプ付きのアドバイザリソース、解決済みロックファイル、ビルドされた成果物のインベントリを渡します。モデルの記憶は脆弱性データベースではなく、パッケージマニフェストは実際に出荷されたものの証明ではありません。SLSAのプロヴェナンスも同様の違いを示しています。プロヴェナンスは成果物がどこで、いつ、どのように作られたかを説明しますが、その成果物が安全だとは宣言しません。

到達可能性によってトリアージの優先度を下げることはできますが、担当をなくしてはいけません。機能フラグは変わり、死んだコードが戻り、間接的な依存関係が予想外の方法で呼び出されることがあります。なぜ検出結果を保留したのか、どのバージョンと呼び出し経路を評価したのか、何が起きれば再調査するのかを記録します。エージェントはその判断理由を管理でき、決定論的なインベントリは再調査のきっかけを監視できます。

パッケージ名も識別の落とし穴になります。期待した名前の依存関係が別のレジストリから来ているかもしれません。ロックファイルが変更可能な場所を指しているかもしれません。ビルド手順がマニフェストにないコードをダウンロードすることもあります。解決されたソース、ハッシュ、エコシステムが対応していれば署名、ビルドのネットワークアクセスを確認します。エージェントは不一致を説明できますが、受け入れるソースを強制するのはビルドシステムです。

アップグレードは自動的に安全な変更になるわけではありません。セキュリティリリースによって、解析、認可のデフォルト、シリアライズが変わり、アプリケーションが壊れることがあります。アドバイザリの最小再現ケースを作り、隔離したブランチでアップグレードを適用し、セキュリティの証明と機能テストの両方を実行します。得られた証拠は判断を支えますが、モデルが「互換性があるはず」と言うだけでは不十分です。

誤検知は証拠設計の問題

検出結果が開発者の時間を使う価値を持つのは、主張、証拠、影響、再現可能な経路を含む場合だけです。AIが生成したレポートは完全に見えても、そのどれかが欠けていることがあります。流暢な修正案が弱い証拠を見えにくくします。

エージェントの各検出結果に、解析したリビジョンと環境、影響を受けるコンポーネント、攻撃者の前提条件、越えられたセキュリティ境界、観測または推測された結果、再現手順、不確実性を記録させます。推測に基づくソース上の指摘と、実行されたエクスプロイトは別のものとして示します。アプリケーションを実行できなかったなら、スキャン全体の注記に隠さず、検出結果に明記させます。

そのうえで、「確認済み」「可能性が高い」「文脈が必要」「再現不能」「受容したリスク」「修正済み」という単純な処理区分を使います。「誤検知」はセキュリティ上の主張が間違っている場合に限るべきです。深刻度が気に入らない、または作業を保留すると決めた、という意味で使ってはいけません。判断を混ぜるとフィードバックが壊れます。望ましくないチケットにすべて同じラベルを付ければ、どのルールが失敗したのかエージェントは学べません。

AIは、重複するトレースをまとめ、サニタイザーを確認し、修正後に再テストすることでノイズを減らせます。同時に、弱い疑いを説得力のある10種類の亜種に増やして、ノイズを拡大することもあります。URLではなく、根本原因と境界で重複を除きます。8つのエンドポイントで使われる所有権チェックの欠落は、8つの露出点を持つ1つのエンジニアリング上の欠陥です。

カテゴリとテストソースごとに精度を追跡します。エージェントが生成したクロスサイトスクリプティングの報告は通常正しいのに、競合状態の主張はほとんど再現しないなら、別の経路へ振り分けます。関係のない欠陥種別を1つのスコアで評価しないでください。ゲートはモデルの自信を表す形容詞ではなく、証拠とポリシーに基づいて失敗させます。

担当を決めることで、ループが閉じます。受け入れた各検出結果には、修正を担当する人またはチーム、想定する再テスト方法、別のテスターが実行できる保存済みの証明が必要です。レポートがエージェントとの会話の中だけに存在すると、会話、モデル、ベンダーが変わったときに消えてしまいます。証拠がそれを作ったツールを離れても残るとき、セキュリティ作業は継続可能になります。

トリアージではプライバシーも重要です。ソース、リクエストボディ、ログ、データベースのサンプルには認証情報や顧客データが含まれることがあります。エージェントに渡す情報を最小限にし、保存するトランスクリプトをマスキングし、本番データとテストデータを分離し、モデルプロバイダーとツールに組織の承認済みデータ取り扱いルールを適用します。検出能力が高くても、管理されていないプロンプトへ本番インシデント全体をコピーしてよい理由にはなりません。

人間によるペネトレーションテストはテストの前提を検証する

熟練したペネトレーションテスターは、アプリケーションが依頼内容と矛盾したときに計画を変えます。そこはエージェントがまだ置き換えていない部分です。担当者への聞き取り、曖昧なルールの確認、運用上の近道への気づき、別のIDの要求、長く実験を続ける価値がある奇妙な挙動の判断を行います。

人間は、不完全な証拠のもとで判断する責任も負います。技術的に可能な操作と、現実的な攻撃経路を区別し、複合的な失敗を経営層とエンジニアに説明し、データを損なう可能性がある場合に安全な証明方法を交渉できます。自律エージェントは、運用者が設定した境界で停止しなければなりません。その境界を黙って広げるなら、エージェント自体が別のセキュリティリスクになります。

これは、すべてのリリースに1週間の外部テストが必要という意味ではありません。変更と影響が重なる場所で人間によるテストを使います。新しい認可モデル、テナントアーキテクチャ、決済やクレジットのフロー、管理プレーン、機密性の高い連携、大規模なマイグレーション、公開開始などです。広範な定期テストはリスクに応じて計画し、重大な修正は再テストします。通常のリリースにも自動化された網羅性は必要です。

エージェントの出力、SASTのトレース、DASTの網羅範囲、アーキテクチャのメモ、テストアカウント、未解決の前提をテスターに渡します。エージェントには偵察と繰り返しの変形を任せ、テスターは予想外の挙動を追います。これは人間の時間を有効にしますが、人間が不要になるわけではありません。

「自律ペネトレーションテスト」という主張を、検出件数だけで評価しないでください。よくあるインジェクションを10件見つけても、ロール割り当て、古い認可、エクスポートされたストレージをまたぐ1つの実証済み経路には及びません。テストした境界、証拠の品質、重要な前提への挑戦によって評価します。

エンゲージメント開始前に、後片付けの担当を決めます。テストアカウント、アップロードファイル、キューに入ったメッセージ、一時ロール、変更した機能フラグは、スキャン後も残る可能性があります。人間のリードが破壊的な証明を承認し、運用担当者と連絡を取り、復元を確認します。エージェントはクリーンアップスクリプトを実行できますが、説明のない本番状態を安全に削除できるかどうかは判断できません。

優れたテスターは、テストできなかったことも報告します。モバイルビルドの不足、利用できないロール、レート制限、サードパーティのコールバック、不安定な環境は、保証の範囲を狭めます。エージェントは障害を回避しながら作業を続け、完了した経路だけを提示しがちです。クリーンな結果が完全な網羅性と誤解されないよう、最終レポートでは除外項目を目立つ形で示します。

複数の証拠から1つのゲートを作る

適切なプログラムでは、各手法に役割を割り当て、その出力を同じセキュリティ要件に結び付けます。SASTは決定論的なソースパターンと広い変更範囲に使います。SCAとプロヴェナンスは依存関係とビルドの事実に使います。DASTはデプロイ後の挙動と基本的なランタイムチェックに使います。エージェントは証拠の連結、認証フローの探索、テストの作成、トリアージの改善に使います。人間はポリシーの定義、ビジネス上の前提への挑戦、影響の大きい変更の調査を担います。

すると、リリースポリシーを具体化できます。承認されていない経路に決定論的な高深刻度ルールが一致した場合、必須の認可不変条件が失敗した場合、テナントをまたぐ目印が現れた場合、確認済みのエクスプロイトが未解決の場合にビルドをブロックします。不確かなエージェントの検出結果は、影響度に応じた期限付きでレビューへ送ります。モデルが自己申告する自信の度合いで本番リリースを決めないでください。

証拠は持ち運べる形で保存します。検出結果、生成テスト、リクエストのトランスクリプト、ツールのバージョン、リビジョン、ID、網羅範囲、処理区分を、エージェントなしでもチームが確認できる形式でエクスポートします。これは監査、インシデントレビュー、ベンダー変更、そしてモデル更新で挙動が変わる普通の日にも重要です。

チャットで作成するアプリケーションでも、同じ分離が必要です。Koder.aiはWeb、サーバー、モバイルアプリケーションを生成し、ソースをエクスポートできます。しかし生成されたソフトウェアにも、明示的なセキュリティ要件と、デプロイされた結果に対する独立したテストが必要です。アーキテクチャとコードが素早く変わるからこそ、明確なゲートが役立ちます。

エージェントは継続的に実行しますが、最も価値のある発見は決定論的な回帰テストへ変換します。確認済みの認可バイパスはすべて、ポリシーケースにします。テナント漏えいが起きるたびに、失敗した境界へ不変条件を追加します。ノイズの多いルールには、記録された処理区分を持たせます。時間が経つにつれて、エージェントがテストシステムの精度を高める状態を目指します。

どの単一ツールが勝つかを問う必要はありません。重要な各主張に独立した証拠があるかを確認します。コード経路がレビューされ、デプロイ後の挙動が実行され、業務ルールが責任者から示され、失敗時の影響が大きい前提を人間が検証しているか、ということです。どれか1つでも空欄なら、AIが生成した「問題なし」という表示では埋められません。