Ahmad Abdur Rahman Khan氏は、AI駆動型ペネトレーションテストプラットフォームHex Securityの共同創業者である。
あるフィンテック企業の最高技術責任者（CTO）が最近、夜も眠れないほど悩んでいることを私に打ち明けた。「以前は四半期ごとに大規模リリースを行っていました。今では1日に複数回デプロイしています。しかし、セキュリティテストは2015年当時のやり方のままなのです」
彼だけではない。AIコーディングアシスタントは、開発のタイムラインを数カ月から数日に短縮した。しかし、開発速度が爆発的に向上する一方で、セキュリティテストは旧来のパラダイムに留まっていることが多い。この非対称性、私が「速度ギャップ」と呼ぶものは、足元で地盤が変化していることにまだ気づいていない企業にとって、困難な状況を生み出す可能性がある。
現状に至った経緯
従来のセキュリティモデルは、設計された当時は完璧に理にかなっていた。企業は年に1回、ペネトレーションテスト会社を雇う。セキュリティ研究者が1〜2週間かけてアプリケーションを調査し、脆弱性を文書化し、包括的なレポートを提出する。企業はその指摘事項を修正し、翌年の評価まで安全だと考える。
これが機能したのは、コードベースが比較的安定していたからだ。リリースサイクルは四半期単位で測定されていた。年次セキュリティチェックで十分だったのは、1月にテストされたアプリケーションが11月に稼働しているアプリケーションと似ていたからである。
その世界はもはや存在しない。
現代の開発チームは絶え間なくデプロイする。典型的なSaaS（Software as a Service）企業は、年次セキュリティ評価の間に数十回のアップデートを実施する可能性がある。各デプロイメントは、新しいコード、新しい依存関係、新しいAPI（Application Programming Interface）エンドポイント、そして新たな潜在的脆弱性をもたらす。2月に修正されたセキュリティ問題が、4月の依存関係アップデートによって再導入され、翌年1月のペネトレーションテストまで検出されないまま放置される可能性がある。
毎日デプロイし、年に1回テストしている場合、脆弱性を検出する機会1回に対して、脆弱性を導入する機会が約365回ある。脆弱性の導入から検出までの遅延は、数日から数カ月に拡大した。
状況を困難にする経済的要因
価格は変動するが、私の経験では、従来のペネトレーションテストは典型的なアプリケーションで1万5000ドルから5万ドルの費用がかかる可能性がある。エンタープライズレベルのテストは6桁を超えることもある。これらは不当な価格ではない。熟練したセキュリティ研究者を雇ってアプリケーションを手動でテストする実際のコストを反映している。
しかし、この経済性はテスト頻度に上限を設ける。資金が潤沢な企業でさえ、毎週3万ドルのペネトレーションテストを実施する余裕はない。私の経験では、多くの組織がデプロイ頻度に関係なく、年に1〜2回テストを実施している。
一方、IBMの2025年データ侵害コストレポートによると、平均的なデータ侵害は現在、企業に400万ドル以上のコストをもたらしている。リスク計算は根本的に変化したが、テストインフラはそれに追いついていない。
継続的自動テストの理解
継続的デプロイメントの時代において、組織はセキュリティテストのあり方を再考する必要があると私は考える。
一部の組織が使用するアプローチの1つは、自動セキュリティテストである。（完全開示：私自身の会社を含む多くの企業が、このタイプのツールを提供している。）これは、自律的エージェントが定期的にアプリケーションをテストすることを指す。仕組みは次の通りだ。AIセキュリティエージェントは、人間のテスターと同じ方法でアプリケーションをナビゲートする。ページ構造を観察し、入力フィールドとAPIエンドポイントを特定し、潜在的な脆弱性に関する仮説を立て、体系的にテストする。
脆弱性の発見の大部分は、体系的で再現可能なパターンに従う。例えば、認証バイパスの試み、インジェクション攻撃ベクトル、権限昇格経路などである。これらは、体系化、自動化、スケール化が可能な方法論的プロセスである。長年のセキュリティ研究を通じて、私は脆弱性の大部分が認識可能なパターンに従うことを学んだ。忘れられた管理者エンドポイント、不十分な入力検証、破損した認証フロー、または誤設定されたアクセス制御などである。
制限事項と一般的な障害
現在の自動化システムは、SQLインジェクション、クロスサイトスクリプティング、認証問題、認可バイパスなどの一般的な脆弱性クラスの特定には優れているが、深い文脈理解を必要とする複雑なビジネスロジックの欠陥には苦戦する可能性があることに注意が必要だ。複雑な権限階層に依存する高度なアクセス制御の脆弱性は、依然として人間の専門知識を必要とする可能性がある。
自動テストを検討している組織にとって、私が推奨するアプローチは、自動化と人間の専門知識のどちらかを選ぶことではない。代わりに、それらをインテリジェントに組み合わせることを提案する。例えば、認識可能なパターンに従う脆弱性の80%には自動テストを使用し、真に人間の推論を必要とする複雑な20%には人間の専門家の時間を確保する。このハイブリッドモデルは、一般的な脆弱性の平均検出時間を短縮しながら、真の価値を付加する部分に人間の専門知識を温存できる。
しかし、ハイブリッドアプローチでも、リーダーはいくつかの潜在的な課題を予測すべきである。私が見る最大のハードルは、アラート疲労である。チームが継続的テストを初めて有効にすると、発見事項の膨大な量に圧倒される可能性があり、その多くは低重要度または誤検知であることが判明する。セキュリティチームは、実際の問題を修正する代わりにノイズのトリアージで疲弊する。
解決策は、狭い範囲から始めることだ。最も重要なアプリケーションを最初にテストし、検出しきい値を調整し、カバレッジを拡大する前にトリアージワークフローを確立する。私たちのフィンテッククライアントは、初日にインフラ全体をスキャンしようとして、アプローチ全体を放棄しかけた。決済APIのみに焦点を絞り直したところ、より意味のある結果が得られた。
2つ目の課題は、組織的抵抗である。セキュリティチームは、自動化を自分たちの仕事への脅威と見なすことがある。ペネトレーションテスターは、自分たちが置き換えられることを心配する。これは、リーダーが自動テストが何を処理し、熟練した研究者が複雑なビジネスロジックの欠陥や人間の創造性が最も重要な敵対的シナリオに集中できるようにする方法を説明することが重要であることを意味する。継続的テストを置き換えではなく拡張として位置づけ、セキュリティチームをツールの設定と調整に関与させる企業は、より高い採用率とより良い結果を得る可能性が高い。
あなたの組織にとっての意味
セキュリティに関する意思決定を行い、継続的自動テストの実装を検討している場合は、最も重要なアプリケーションとAPIサーフェスから始めることを忘れないでほしい。セキュリティテストを開発ワークフローに統合し、コードが本番環境に到達する前に自動検証が行われるようにすることを検討してほしい。ビジネスクリティカルなシステムについては定期的な人間の専門家によるレビューを継続するが、その専門知識を最大の価値を提供する複雑なエッジケースに再配置してほしい。
速度ギャップは拡大し続ける可能性があると私は考える。AIコーディングアシスタントは改善されている。開発チームは加速し続けるだろう。ギャップを埋めるために、組織はセキュリティテストインフラが適応することを確実にしなければならない。そうでなければ、遅れをとるリスクがある。
